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/
SPONSORED LINKS
YAHOO! GROUPS LINKS
