++1! I couldn’t agree with you
more.
Dave
Dave,
I really like your last point about the advantages of using ESB and WSM
together. My objection to your previous post was that you made is sound like
the ESB could do it all. The point I wanted to make is that you should use an
ESB for what it does best, but it doesn't provide a complete SOA solution, and
that other products, such as platforms, WSM, XML gateways, registries, and
other stuff are also required to provide a complete SOA solution.
Anne
On 1/11/06, David A.
Chappell <[EMAIL PROTECTED]>
wrote:
1)
That's a lengthy answer, which I will get to when
I have more time. The short answer is that the ESB provides mediation in
many forms, as we have discussed, and in Sonic's case also can provide hardware
independent fault tolerance and failover for ESB services and the service
requests themselves in the form of what we call Continuous Availability
Architecture.
#2, #3, and #4 I suspect
are phrased in such a way to pointing out that are where a WS-Management
platform may have a more distinct advantage. I don't disagree with that
and in fact we have customers using these technologies (ESB and WS-M) together.
Dave
A few nits here...
1. I take issue with this statement: "Additional pieces of your
infrastructure, such as appservers and databases, can be brought into
the SOA fabric through the bus by using the appropriate standards
interfaces and protocols that they support." Given that most app servers
and DBMSes provide native support for web services, why would I need
"the bus" to bring them into the SOA fabric?
2. Although you have plans to deliver support for WS-Security and
WS-Policy in the next release, the current version of Sonic ESB does
not support these specifications. Therefore I'd appreciate it if you could
explain how your "very sophisticated federated security model" can
integrate with other SOA infrastructure components--say a .NET WSE
service using WS-Security. (And let me qualify that request by saying
that symmetric deployment of Sonic ESB on both sides of the
interchange is not an acceptable solution.)
3. From my perspective a system that supports "cross-cutting technical
concerns" should provide those services across heterogeneous platforms.
Could you explain to me how you can support security, governance, and
manageability of .NET, C++, Java, and Perl services?
4. Can you also explain to me how Sonic ESB can help me manage the
lifecycle of a .NET service?
It's not that I don't see value in an ESB (it plays an important role in a SOA
infrastructure -- especially in terms of protocol mediation and legacy
integration).
I just have a problem with the way you've described its capabilities, because
you make it sound as if it can do everything.
Anne
On
1/10/06, David A. Chappell
<[EMAIL PROTECTED]>
wrote:
The Sonic SOA suite does
offer support in those 4 areas that you
mention. 1) The Sonic ESB offers multi-protocol support,
and is
building in support for WS-* in the next release (including
WS-Policy).
2) Sonic also offers add-on services for accessing and retrieving
data,
whether via a relational database access service, or via native
XML
persistence. It also offers a collaboration service
that is intended
for doing B2B collaborations. 3) It has a very
sophisticated federated
security model (and is building in support for WS-Security), and
a very
sophisticated distributed management layer. It
contains its own
configuration repository, and also works well with the Systinet
registry
for helping with governance. 4) It has deployment management
tools that
let you move service instances and their associated process
models as
"scenarios" from design, test, to deployment.
I'm not suggesting that base definition of ESB be expanded (just
yet) to
cover all these things. However, an ESB product from a
vendor should be
capable of offering these capabilities. Additional
pieces of your
infrastructure, such as appservers and databases, can be brought
into
the SOA fabric through the bus by using the appropriate standards
interfaces and protocols that they support. The ESB,
supporting
tooling, and value-added services (SOA Suite) offer the design
center
where the SOA architect spends his/her time modeling the
interaction
between applications, services, databases, etc using modeling
tools,
uses the deployment tools to easily manage a distributed
deployment, and
the management infrastructure to monitor the health and stats of
the
overall system. That is where I'm coming from.
Dave
-----Original Message-----
From: [email protected]
[mailto:[email protected]
] On Behalf Of
jeffrschneider
Sent: Tuesday, January 10, 2006 10:13 AM
To: [email protected]
Subject: [service-orientated-architecture] Re: Basics
> >I tend to look at SOA infrastructure in four categories:
> >1. Protocol and policy focused offerings (ESB, Service
Fabric,
AON)
> >2. WSDL based technical services (data services,
collaboration
> >services, etc.)
> >3. The cross-cutting technical concerns (security,
governance,
> >managability)
> >4. Lifecycle tooling (architecture, design, code, test,
etc.)
>
> There's no reason an ESB shouldn't offer all of these
things. In
fact,
> I would say that any ESB offering that doesn't, is lacking.
Then, I must conclude that you believe that ESB = ALL Service
Oriented Infrastructure. Hence, I must also conclude that you
believe that the Sonic Suite is "lacking".
I'm quite confident that I am misunderstanding your point. Can
you
please clarify?
Jeff
Yahoo! Groups Links
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
YAHOO!
GROUPS LINKS
YAHOO! GROUPS LINKS
|
