ESB Roundup Part Two: Use Cases

 In part one of this series, we began with the basic definition of an Enterprise Service Bus (ESB) on the Wikipedia.

One of the points of general agreement seemed to be that an ESB was distinct from orchestration and Business Process Management belonged in a separate class of product. In addition, there was a healthy debate on whether an ESB was a product or pattern.

In part two of this series, InfoQ examines the purpose of an ESB--what are the use cases and requirements for an ESB?

Stuart Charleton (Enterprise Architect for BEA Systems' Strategic Consulting Services, in Toronto, Canada) in the discussion of the previous article offered the following examples of uses:

• A consumer talks HTTP/S based authentication, a producer uses WS-Security
• A consumer talks HTTP/RSS, a producer uses WebSphere MQ or JMS
• A consumer talks HTTP/REST and URIs, a producer talks SOAP/WSDL
• A consumer has one set of credentials, a producer has another set (keychain mapping).
• An FTP site is the "service interface" for one end, but the files are broken up into JMS messages on the other end
• A message may need enrichment before routing to a destination, so I can perform callouts to gather extra information
• Protocol independent load-balancing and/or failover is required for a producer
• Messages need to stored and forwarded, retrofitting reliability onto an unreliable service

And augmenting these themes, Paul Fremantle  (Co-founder and vice president of technology at WSO2) added:

So an ESB is a communications infrastructure that enables mediation. What topology should an ESB have? I think the topology should be flexible: you can build an ESB as a single big broker in the middle, or as lots of smart endpoints. Of course the topology affects the manageability, but as long as their is a central registry/repository to configure the ESB then it works fine. The key to this is that an ESB should be driven by policy not by writing code. 

"...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."

Which emphasizes the use of an ESB as a bridge for legacy applications. A recent study by Network Computing had survey respondents grade a set of statements about ESB technology using a scale that went from "Strongly agree to Strongly disagree". The top four statements which respondents most strongly agreed to were:

1. ESBs must provide adapters to enterprise data sources (SAP, Peoplesoft, Oracle, SQL Server)
2. ESBs must support at least rudimentary business process management
3. Open standards (JMS, Web services) support is/was a requirement for our ESB implementation
4. An ESB must integrate smoothly with existing enterprise application integration (EAI) and message-oriented products. 

This suggests that legacy data sources such as ERP and EAI systems are important interfaces for the ESB, and that they should expose those layers as standards based messages. The interesting finding was that end users seemed to agree that "at least rudimentary" business process management was something that an ESB "must support".

On a final note, Steve Jones from CapGemini suggested that in fact, the ESB problem was actually three seperate and unrelated problems, Integration, Build and Business:

.. One challenge is leveraging the current estate and getting functionality out (Integration), the second is building new applications (Build) and the final is managing the interactions between these new applications (Business). I blogged on it a while back.

Integration products have very different requirements and drivers from ones that aim to enable interaction in a more standards oriented space, and I'm not sure why it makes sense to confuse the two domains. Equally building new applications (in process or OO languages) requires different skill sets and approaches.

An Integration Bus will be measured on its power, a Business Service Bus on its simplicity and an Application Development solution by its flexibility. And any reasonably sized business will not have one solution that fits all their needs.

Part two of the ESB roundup hopes to help define the use cases that customers call for when they require an ESB. The general agreement that business process tooling was distinct from ESB coupled with the contradictory interest in this capability from end users suggests that there may be several product categories conflated into one.

For this discussion, please focus on the use cases appropriate for ESB.