The Role of the Enterprise Service Bus

This was a presentation given by Mark Richards and describes the role of an ESB and particularly what it provides. It is an old presentation (23 oct 2006) but still very true, in the fact that there are still a lot of different definitions of an ESB within the world.
This is a short recap of this presentation.

He emphasizes that we need to understand the capabilities of an ESB. The capabilities are defined from an architectural context and he first explains why an ESB is used (loose coupling, agility, location transparency, services reuse, separate business services from service providers).

The following core capabilitities are described.
Note that not all capabilities need to be present within the ESB, but only use the one the customer needs. Next the capabilities are described in short.

The ability to channel a request to a particular provider based on routing criteria (types are: deterministic, content-based, policy-based, complex rules-based).

Message Transformation
The ability to convert the structure and the format of incoming request to provider needs.

Message Enhancement
The ability to add or modify the information contained in the message as required by the provider.

Protocol Transformation
The ability to accept one type of protocol and communicate to the provider through a different protocol (i.e. SOAP/JMS -> IIOP, XML/HTTP -> RMI).

Service Mapping
The ability to translate a business service into the corresponding service implementation and provide binding and location information.

Message Processing
The ability to manage state and perform request management by accepting an input request and ensuring delivery back to the client via message synchronization.

Transaction Management
The ability to provide a single unit of work for a business service request by providing a framework for the coordination of multiple resources across multiple disparate services (WS-Coordination, JSR-95). It is difficult to propagate transaction through for example MQ and HTTP. The solution would be to use an aggregate service.

The ability to protect enterprise services from unauthorized access (authentication, authorisation, auditing) through security manager.

The two where you probably have the most discussion about are Process Choreography and Orchestration. Choreography is the ability to manage complex business processes that require the coordination of multiple business services to fulfill a single business request. Whereas orchestration manages multiple implementation services (aggregation of services).

When looking at architecture components of the ESB with its responsibilities/capabilities he defines 4 components.
Mediator: routing, communication, message transformation, message enhancement, protocol transformation, message processing, error handling, service orchestration, transaction management, security.
Service Registry: service mapping.
Rules Engine: rules-based routing, message transformation, message enhancement.
Choreographer: Process choreography and only in case of entry point for the ESB: transaction management, security and message processing.

He then describes the relation between the mediator and choreographer and advises to use the mediator as the entry point and the choreographer underneath it. He advices to use a JMS resource as the entry point for an ESB because of its reliable delivery, monitoring and performance.
The advantages to set it up this way are: performance, scalability, only services that need choreography go through the choreographer.

JSR-208 JBI Specification
This specification of the Java community reached its final version in August 2005. It is an architecture and set of interfaces for providers of integration products to integrate with each other within a JBI container. It is highly flexible in which you can configure just the components you need within your ESB solution (by using Service Components). The way communication is handled with the bus is done with Binding Components.

The advantage is a vendor-indepedant ESB, flexible, light weight solution.

Open Source
There are two open source ESBs
  • Mule
    Light weight messaging framework that uses POJOs for implementing the routing, message enhancements etc, so you have to implement a lot.
  • ServiceMix
    Open source JBI compliant ESB with some out-of-the-box service- and binding components (like WSIF, HTTP, XSLT, Drools)

I would like to give my opinion on the presentation:
  • In my opinion choreography is not part of the ESB capabilities, but is done within BPM. Orchestration can be done within ESB and is often seen as choreography. Or should the choreography be part of the ESB? Because you could also say that a choreography is a business service itself and it should be transparent for a service client where and how the business service is implemented.
  • The capabilities list can nicely be used to investigate which product is suitable for a customer. It is a nice checklist.


  1. This presentation of Mark Richards is a classic, putting some workable definitions around the topic at a time when no other spokesperson could formulate the answer so clearly. He mentioned the earliest ESBs available, Mule and Service Mix, and also that Service Mix followed the JBI standard. Other JBI ESBs have followed since 2006 including OpenESB and my company's product, ChainBuilder ESB. ChainBuilder ESB wraps Eclipse-based user interfaces (plug-ins) around the process of creating and managing a JBI components simplifying it to drag and drop mapping, and wizard-based component flow design. It is the fast and easy way to implement an integration solution, and all based on the JBI open standard. Apologies for the marketing buzz, but my sincere hope is to find your consulting profile above will include open source ChainBuilder ESB 2.0 as one of your preferred consulting products in the near future! The community site with downloads is available at www.chainforge.net. Best Regards, Kristen

  2. JBI is dead, long live OSGI based ESBs. WSO2 ESB delivers a clean, multi-tenant architecture based on an OSGI kernal.


    1. @cobiacomm: I agree. You do not hear much about JBI anymore. In fact we are doing a project with WSO2 at the moment at www.ciber.com. However is it really a multi-tenant architecture ?

  3. Hi Roger,

    Yes. All the WSO2 products can run on-premise as standalone servers as well as the same product is there as a cloud offering.
    Both the on-premise and the standalone versions support the MULTI-TENANCY aspect. You can learn more about WSO2's multi tenancy from this presentation done by Dr. Srinath Perera (Director Research of WSO2) in one of the WSO2 Conferences.

  4. To add to the comment above, I agree with cobiacomm.
    WSO2 ESB is a 100% open source mediation, transformation and routing engine. With the numerous functional features, ESB has the default support for scalability, security and other QoS aspects, governance etc.
    With all the above, WSO2 ESB has proved that it is the fastest among the other enterprise service buses. The latest test results has proven the same and the results can be found in this article

  5. @Manisha: Thanks for the replies ! I will look into it, because we're are also interested in the Cloud tooling of WSO2