First, let's establish your meaning of the term "ESB". I assume that you are talking about a product. Examples include BEA AquaLogic SB, Cape Clear ESB, Fiorano ESB, IBM WebSphere ESB, IBM WebSphere Process Server, IBM WebSphere Message Broker, IONA Artix, Oracle ESB, Software AG crossvision, Sonic ESB, Tibco BusinessWorks, and webMethodsFabric. Also, open source projects: ServiceMix, Mule, Celtix, etc.You are not referring to what IBM first termed "an architectural pattern". And you are not referring to a multi-product services infrastructure organizations build to support SOA initiatives.

I do not believe that an ESB is an essential component of SOA. When it comes right down to it, you don't need any new products to do SOA. After all, SOA is about design, not technology. Nonetheless, products can be very useful, and I recommend buying at least a few basic components to get started.

The vendor hype surrounding ESBs has been very effective -- you'd be amazed how many requests I get from my clients for help selecting an ESB. But then, organizations frequently want a quick-fix solution. The vendors (and many analysts) are telling them that an ESB is all you need to get "instant SOA", or at the very least, that its an essential component.

But an ESB is not on my list if the few "basic components" that I recommend for getting started with SOA. In fact, I discourage people from starting with an ESB. An ESB does not encourage good SOA behavior. ESBs are essentially integration systems, not SOA systems. SOA is about tearing down application silos, but integration systems reinforce those silos.

In my book, the basic components include:

• one or more service platforms (e.g., .NET, a Java EE app server, etc.)
• a SOA management solution (e.g., AmberPoint, Actional, SOA Software)
• a registry ( e.g., Systinet, Infravio)
• an XML gateway if services will be exposed outside the firewall (e.g., IBM DataPower, Reactivity, Forum, Layer 7)
  

As you say, an ESB is especially good for bridging to legacy applications, and therefore it is a useful component in a services infrastructure. Many ESBs also support reliable messaging, asynchronous messaging, and pub/sub exchange patterns. These capabilities can also be pretty useful--but probably not in the initial stages of a SOA project. (Every organization has lots of projects to choose from that don't require these capabilities.) At a later stage in a SOA project, you might also want an orchestration engine, and most ESBs supply one--but that definitely isn't where an organization should start a SOA initiative. All of these capabilities are things that you don't need when first getting started. Therefore an ESB should be a later-stage purchase.

I also definitely don't recommend using an ESB as a central hub for all SOA traffic. You and I had a private discussion a couple of days ago wherein I suggested that all important message traffic should be mediated -- but it should not be mediated by an ESB. It should be mediated by XML gateways and/or SOA management agents. A mediation system should do ALL of the following

• virtualization of endpoints (enabling dynamic location, binding, routing, versioning, etc)
  
• transformations
  
• security mediation and enforcement of security policies
• monitoring, management, and control
  

An ESB can only handle the first two. XML gateways and SOA management agents can do all four. My preference for a mediation system is an XML gateway because it offers the added value of hardware acceleration. Although I recommend XML gateways as a basic component only when exposing services outside the firewall, that's only when discussing the initial configuration. When first getting started, I think SOA management is a more important infrastructure component, because you need the monitoring and visibility features that only a SOA management system offers. But as the SOA initiative progresses, I recommend using an XML gateway for mediation between services inside the firewall. (You'll still need SOA management to implement endpoint-based policy enforcement points, but XML gateways make better mediators.)

Regarding this point:


The same can be said about all SOA infrastructure products. Lock-in is a fact of life. As soon as you implement anything, you're locking yourself into a product. I think it's better to lock yourself into a single product for configuration and management than to deal with dozens of different tools and procedures for configuration and management. That's the primary reason that I recommend using a SOA management system to implement endpoint policy enforcement points rather than using the inherent capabilities of a service platform. Centralized management and control is a good thing. The one caveat is that many ESBs are built on a proprietary MOM protocol, and you definitely need to be cautious about using proprietary protocols. Not only do they lock in the product for that specific service, they also force symmetric deployment of the proprietary protocol. Try to avoid using them.

Anne