Re: [service-orientated-architecture] SOA and ESBs

Thu, 29 Jun 2006 05:40:38 -0700

I apologize to the list for give BEA this opportunity to soap-box.

Regarding this comment:

I don't look at it this way -- i would suggest perhaps
that most don't see or even agree with the distinction
of features that you listed in a prior email, or that
an XML gateway offers more functionality than an ESB.
This is frankly the first time I've heard a suggestion
than an XML gateway, as a product category, offers
more and better functionality!

XML gateways offer richer functionality than most ESBs when it comes to the general mediation capabilities. I classify general mediation as the ability to do:
- service virtualization (enabling routing and versioning)
- transformations using XSLT
- security policy enforcement
- security mediation
- montoring

In particular, XML gateways offer the richest security policy enforcement and security mediation capabilities of all mediation systems. Another advantage XML gateways have is that they use hardware acceleration for extremely expensive functions such as schema validation, XSLT, XML encryption, and XML signature. ESBs offer other capabilities that XML gateways don't offer (orchestration, service hosting, legacy integration, pub/sub, complex message transformation involving more than just XSLT).

The key point to take away, here, is that no mediation system does it all. A combination of solutions (ESB, XML gateway, and SOA management) is best. But most oganizations aren't willing to invest in all three types of products right from the start.

Going back to the beginning of this discussion, we were talking about what you need to get started with SOA. As you may recall, I said that I thought an ESB was a useful product as a component of a comprehensive services infrastructure, but I also said that it isn't an "essential" component, nor is it an appropriate component to use when first getting started -- except possibly as a means to integrate with legacy apps. The mediation system that I recommend when first getting started is a SOA management system, which is the most versatile mediation system available -- it does general mediation, monitoring/management, and it supports endpoint monitoring and policy enforcement. (It does not do legacy integration, orchestration, pub/sub, etc, but typically you don't need that functionality in the early stages of SOA adoption.) If you are doing XML messaging outside the firewall, then you should also get an XML gateway, because it provides firewall functionality.

As you progress and your volume of messages goes up, I recommend using an XML gateway for general mediation functionality within the firewall because of the performance advantages it supplies. But you still want to use a SOA management solution for endpoint monitoring and policy enforcement. And at some point, you'll probably want an ESB when you're ready to start using orchestration, pub/sub, and other capabilities that are unique to ESBs. But I still recommend using the XML gateway for general-purpose mediation.

I hope my recommendations are more clear now.

Anne

On 6/28/06, Stuart Charlton <[EMAIL PROTECTED] > wrote:

Anne,

Firstly, to be clear, even though I speak for myself
and not BEA in this discussion, I am interested in
promoting our view of the ESB space. I'm a
consultant, not in product management, so I can't
speak to our future plans. On the other hand, I can
speak to how I see customers adopting the products.

Secondly, comments inline.



--- Anne Thomas Manes <[EMAIL PROTECTED]> wrote:

> I should have said that most ESBs don't encourage
> good SOA behavior. Not all
> ESBs are created equal. But for the most part, this
> product category focuses
> on servicing tactical integration needs rather than
> enabling good design of
> reusable services.

Fair enough, I agree with this, and am disappointed by
it, as it will only detract from offerings that do
enable good practices.


> It would seem pretty obvious that ESBs are more
> popular than XML gateways
> (just compare the number of vendors in each
> category), but don't take that
> as proof that ESBs are a better solution.

I don't look at it this way -- i would suggest perhaps
that most don't see or even agree with the distinction
of features that you listed in a prior email, or that
an XML gateway offers more functionality than an ESB.
This is frankly the first time I've heard a suggestion
than an XML gateway, as a product category, offers
more and better functionality!

For example, one of my larger clients refers to their
hardware-based XML gateway as their "enterprise
broker". The major reason they opted for this
approach was price/performance compared to the
available software of the era (2004 timeframe) running
on their chosen infrastructure provider.

In terms of flexibility and quick-reaction to evolving
new interfaces, the gateway isn't great, and they're
now looking to complement their XML gateway with ALSB
as a neighbourhood proxy to get more flexibility and
quick-reaction times for their delivery teams. So
here is a case where an XML gateway is deemed more
performant but less flexible than an ESB.

My overall point is that it is futile to compare
product categories in this way, given the market's
immaturity and lack of consistent terminology, but I
suppose we will have to leave it at that.


> I'm not aware of any ESB that performs security
> mediation. (vendors --
> correct me if I'm wrong.) BEA's AquaLogic Enterprise
> Security product does
> -- but not ALSB.

This really isn't the case. ALSB most certainly does
do many cases of security mediation (though not as
many as in conjunction with ALES).

It can have TLS inbound and WS-Security outbound, or
vice-versa, I can also actively translate a
WS-Security authentication request (username/password,
x509, or SAML token) into a new SAML assertion
downstream. It can even take in a SAML-based input
and then use a pre-defined service account for a
downstream service.

In the 2.5 release due in a couple of weeks, there are
even more fine grained capabilities here for identity
mapping to downstream services that don't support SAML
(and not requiring ALES).


> rudimentary monitoring and
> management of services managed by ALSB. But that
> isn't sufficient in a
> heterogeneous environment.

I have clients with very heterogenous environments
(CICS, WebSphere MQ, Tuxedo, FTP batches, HTTP-REST
and HTTP-SOAP etc.) that are starting to use ALSB to
manage, monitor, send alerts, and route/transform
between their services.... I don't see how it's not
sufficient.


> (Otherwise, why would BEA establish partnerships
> with AmberPoint and SOA Software.)

Obviously a product can't be all things to all
people.... but in my opinion the main reason for these
partnerships is that ALSB isn't a agent-based WSM
solution, which might be more appropriate in some
contexts.


> The management and security capabilities supplied by
> XML gateways and SOA
> management products are far superior to those
> supplied by an ESB.

I disagree on this, it doesn't fit with my experience
in the field when working with our products and
talking to our customers and prospects. There
certainly are many that are interested in WSM
solutions, but it's usually as a complement, not a
superior replacement.


> all these capabilities. And this infrastructure
> should not be hosted on a
> single instance of an app server (my primary
> objection to ALSB).

Granted, federated management is an issue with the ESB
model, though we're working on that.


> I stand by my recommendations.

I just wanted to clarify whether I understood your
position correctly, and to note that not all ESBs are
created equal.

Cheers
Stu


__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com


__._,_.___


SPONSORED LINKS
Computer software Computer aided design software Computer job
Soa Service-oriented architecture

YAHOO! GROUPS LINKS



__,_._,___

Reply via email to