SOA programming model for implementing Web services, Part 4: An introduction to the IBM Enterprise Service Bus

The Enterprise Service Bus (ESB) architectural pattern supports virtualization and management of service interactions in a service-oriented architecture (SOA). It enables interactions among service providers and requesters and can be implemented using a variety of middleware technologies and programming models. It extends the SOA programming model concepts introduced in previous articles of this series.


Dr. Beth Hutchison (, Senior Technical Staff Member, IBM 

Author photoDr. Beth Hutchison is a Senior Technical Staff Member and a Web Services Architect working on IBM's Enterprise Service Bus technologies. She has consistently worked on leading-edge technologies, initially as the lead developer for the first release of WebSphere MQ on the distributed platforms. Subsequently, she took on the role of performance architect for IBM's Java Virtual Machines. She has now rejoined the MQ family and is working on systems management across the ESB.

Marc-Thomas Schmidt (, ESB Chief Architect, IBM 

Author photoMarc-Thomas Schmidt is a Distinguished Engineer and has been working on IBM’s Business Integrations technologies for more than a decade, from workflow management systems to advanced message-oriented middleware to business process management technology. In his current role, he leads the work on technical architecture for IBM’s ESB technologies.

Dan Wolfson (, CTO, Business Integration, IBM 

Author photoDan Wolfson, IBM Distinguished Engineer, is the Chief Technical Officer for Business Integration Software at IBM Software Group. He is responsible for architecture and technical strategy leadership for IBM's integration software (run time and tools), working with the architecture and development teams across SWG -- IBM Websphere Business Integration and Information Integration products in particular. Dan has over 20 years of experience in research and commercial distributed computing ranging over transaction and object-oriented systems, programming languages, messaging, and database systems.

Marcia Stockton, Senior Technical Staff Member, IBM 

Author photoMarcia L. Stockton is a Senior Technical Staff Member and Master Inventor with the IBM Software Group in Research Triangle Park, North Carolina (residing in California). She is also a senior IEEE member. Marcia leads the Software Group Architecture Board's Programming Model Workgroup, where she drives horizontal integration initiatives and promotes programming model simplification across Lotus®, Rational, WebSphere, DB2®, and Tivoli® products. Her 73 filed U.S. patents range from networking, Web, security, privacy, multimedia, wireless, pervasive devices, to radio frequency ID. She recently led efforts to define the architecture for identity management and for edge server distributed programming. She joined IBM in 1988 after five years developing networking software. She earned a B.A. from Swarthmore College in 1975. You can contact Marcia at

26 July 2005

Also available in Vietnamese


SOAs offer a flexible, extensible and composable approach to reusing and extending existing applications and constructing new ones. Services advertise capabilities, both offered and requested, by declaring interfaces they implement or expect other services to implement, and by declaring policies governing potential partner interactions. Web Services Description Language (WSDL) and other Web services standards, such as WS-Policy, provide the vocabulary for these declarations. (See Resources for a link to the WSDL, Version 2.0 Part 0: Primer.)

Virtualization of business functions, a key goal of an SOA, is achieved by isolating service definition and usage from service implementation. Services may be implemented using a wide range of technologies, including IBM WebSphere® MQ, IBM CICS® or IBM IMS™, Java™ 2 Platform, Enterprise Edition (J2EE) Enterprise JavaBeans (EJB), Java classes, IBM DB2® Queries, Java Message Services (JMS), or Microsoft® .NET. Service requesters dispatch requests to a service provider that offers the capabilities they desire, unaware of its implementation.

An ESB is an architectural pattern that supports virtualization and management of service interactions between communicating participants. It provides connectivity among service providers and requesters, facilitating their interactions even if they are not exactly matched. This pattern can be implemented using a variety of middleware technologies and programming models.

This article defines the ESB pattern and its role within the SOA. Subsequent articles will detail usage scenarios, implementing the ESB pattern with today’s technologies, and future directions for ESB technologies.

What is an ESB?

In the ESB pattern, rather than interacting directly, participants in a service interaction communicate through a bus that provides virtualization and management features that implement and extend the core definition of SOA. The IBM ESB pattern provides virtualization of:

  • Location and identity: Participants need not know the location or identity of other participants. For example, requesters don't need to be aware that a request could be serviced by any of several providers. Service providers can be added or removed without disruption.
  • Interaction protocol: Participants need not share the same communication protocol or interaction style. A request expressed as SOAP/HTTP may be serviced by a provider that only understands Java Remote Method Invocation (RMI).
  • Interface: Requesters and providers don't need to agree on a common interface. The ESB reconciles differences by transforming request messages into a form expected by the provider.
  • Qualities of (Interaction) Service (QoS): Participants declare their QoS requirements, including performance and reliability, authorization of requests, encryption/decryption of message contents, automatic auditing of service interactions, and how their requests should be routed (such as to available implementations based on workload distribution criteria). Policies that describe the QoS requirements and capabilities of requesters and providers may be fulfilled services themselves or fulfilled by the ESB compensating for mismatches.

Thus the ESB pattern shields requesters from awareness of the service provider's physical realization -- from the perspective of both application developers and deployers. The bus takes responsibility for delivering requests to a service provider offering the required function and QoS. Providers receive requests to which they respond without knowing the message's origin. The ESB itself is invisible to the service requesters and providers that use it. Application logic can invoke or deliver services using a range of programming models and techniques without considering whether the connection is direct or whether it traverses an ESB. Connection to an ESB is a deployment decision; the application source code is unaffected.

An ESB supports many interaction types, including one-way, request/response, asynchronous, synchronous, and publish/subscribe. It also supports complex event processing in which a series of events may be observed to produce one event as a consequence of the relationships in the series.

Figure 1 depicts the basic ESB pattern. Messages flow over a bus that interconnects a variety of communicating participants. Some participants invoke services offered by others; other participants publish information to interested consumers. The site where an endpoint interacts with the ESB is called a Service Interaction Point (SIP). A SIP can be, for example, a Web services endpoint, a WebSphere MQ queue, or a proxy for an RMI remote object. A service registry captures metadata describing requirements and capabilities of SIPs (for example, interfaces provided or required), how they wish to interact with other SIPs (such as synchronously or asynchronously, through HTTP or JMS), their QoS requirements (for example, secure, reliable interactions preferred), and other information that enables interactions with other SIPs (such as semantic annotations).

Figure 1. Basic ESB pattern
Basic ESB pattern

Interposing the bus between participants provides the opportunity to modulate their interaction through a logical construct called a mediation. Mediations operate on messages in-flight between requesters and providers. For complex interactions, mediations can be chained sequentially. The Mediation patterns section covers common mediation patterns implementing these virtualization, QoS, and management concepts.

The ESB pattern offers a flexible and manageable approach to SOA implementation. Transparently interposed between endpoints, the bus enhances qualities of service; facilitates requester-provider interactions despite mismatched protocols, interaction patterns, or service capabilities; and enables monitoring and management.

SOA user roles and their tasks

Examining the roles and tasks of users who create and manage SOA solutions sheds further light on the ESB pattern. The ESB tools and run times decompose the SOA solution lifecycle into four phases:

  • Discover and describe: Identify and describe the SIPs that can be interconnected across the ESB. This includes new service creation, existing service discovery, and description of their interfaces, requirements and capabilities.
  • Model and build: Interconnect SIPs through new or existing mediations to describe the end-to-end interactions of a solution.
  • Configure and deploy: Configure an abstract declaration of a solution for a particular runtime topology and deploy it, creating the necessary runtime artifacts.
  • Monitor and manage: Monitor and manage the solution through the behavior of the SIPs and mediation. This phase uses instrumentation and control points in the ESB run times, as well as mediations that observe and affect the flow of messages.

For ESB middleware, the most significant SOA solution development roles are integration developer and solution administrator, but also involved are business analyst, solution architect, implementer, adapter developer, and operator. (The roles are conceptual; one person could fill multiple roles.) Figure 2 shows how these roles interact.

Business analysts identify business requirements and review business processes. They outline a solution's goals, the business processes involved, key indicators to monitor the solution's health and status, and the types of business services the IT systems need to provide.

Solution architects determine which business requirements can be satisfied by reusing, modifying, or combining existing IT assets, and which require new IT assets to be written or purchased. They define the interactions between IT assets, including the content of message exchanges.

The development work is split among three roles. An implementer writes new application code that is called through a service interface. An adapter developer builds services that wrap existing or newly acquired applications and packages to provide accessibility by other services. An integration developer uses ESB-related tools and technology to build the logic that controls how requests are routed between these services.

Figure 2. User roles
user roles

A solution administrator makes new IT assets available by deploying them and importing their service definitions into the service registry. When the solution is in place, operators monitor its execution, start and stop IT systems as required, and advise the solution administrator, who may adjust the solution configuration.

ESB patterns

Integration developers and solution administrators use a set of patterns to design and deploy SOA solutions.

Figure 3. Elements of the basic ESB pattern
user roles

The basic ESB pattern abstracts application components into a set of services that interact through a bus rather than through direct, point-to-point communications. A given service can be a provider, a requester, or both. Any SOA implementation enables basic virtualization, allowing the substitution of an equivalent provider implementation without impacting dependent requesters. The ESB pattern improves upon this basic SOA capability through its explicit management of requester-provider interactions. Any provider can be replaced by another provider as long as it approximates the capabilities needed by the requester in ways that the ESB can mediate.

The ESB provides interaction points where services put messages on the bus or take them off. It applies mediations to messages in-flight and guarantees QoS to these managed interactions.

From an ESB perspective, all service interaction endpoints are alike in that they send requests/events or process requests/events; they require specific QoS; and they may require interaction facilitation. The ESB pattern enables integration developers to treat requesters or providers that interact with people in the same (service-oriented) way as new business logic, process choreography components, or external Web services.

Patterns for building ESB-based solutions are classified as:

  • Interaction patterns: Enable service interaction points to dispatch messages to, or receive messages from, the bus.
  • Mediation patterns: Enable the manipulation of message exchanges.
  • Deployment patterns: Support solution deployment into a federated infrastructure.

Interaction patterns

The ESB enables endpoints to interact in their native interaction modes through the bus. It supports a variety of endpoint protocols and interaction styles. A few examples of interaction patterns are:

  • Request/response: Handles request/response-style interactions between endpoints. The ESB is based on a messaging model, so a request/response interaction is handled by two related one-way message flows -- one for the request and one for the response.
  • Request/multi-response: A variant of the above, where more than one response can be sent.
  • Event propagation: Events may be anonymously distributed to an ESB-managed list of interested parties. Services may be able to add themselves to the list.
Figure 4. Interaction patterns
interaction patterns

Mediation patterns

Mediation patterns manipulate messages in-flight on the bus (requests or events). Messages dispatched by a requester are transformed into messages understood by a slightly incompatible provider selected from a set of potential endpoints.

These mediations operate on one-way messages rather than on request-response pairs, because the ESB overlays interaction patterns on top of mediation patterns.

Figure 5. Meditation patterns
meditation patterns

There are several basic patterns for mediations; more complex patterns can be built by combining the simple patterns:

  • Protocol switch: Enables service requesters to dispatch their messages using a variety of interaction protocols or APIs, such as SOAP/HTTP, JMS, and MQ Integrator (MQI). Transcodes requests into the targeted service provider's format. Can be applied at the requester or the provider end of an interaction, at both ends, or anywhere in between.
  • Transform: Translates the message payload (content) from the requester's schema to the provider's schema. May include enveloping, de-enveloping, or encryption.
  • Enrich: Augments the message payload by adding information from external data sources, such as customization parameters defined by the mediation, or from database queries.
  • Route: Changes the route of a message, selecting among service providers that support the requester's intent. Selection criteria can include message content and context, as well as the targets' capabilities.
  • Distribute: Distributes the message to a set of interested parties and is usually driven by the subscribers' interest profiles.
  • Monitor: Observes messages as they pass through the mediation unchanged. Can be used to monitor service levels; assist in problem determination or meter usage for subsequent billing to users; or record business-level events, such as purchases above a certain dollar value. Can also be used to log messages for audit or for subsequent data mining.
  • Correlate: Derives complex events from message or event streams. Includes rules for pattern identification and rules that react to pattern discovery, for example, by generating a complex event derived from content of the triggering event stream.

Mediations can be explicitly configured in a solution. For example, an integration developer might configure an enrich mediation that modifies the message content. A solution administrator might configure a route mediation to allow her to switch a service provider offline.

Other mediations are put in place by the ESB to satisfy QoS requirements of the service requesters and providers. For example, if a service provider's security policy declaration requires encrypted messages, the ESB can configure an encryption mediation automatically.

As well as being attributes of the services, policies can be set by the solution administrator for an interaction, or set of interactions. For example, to log all messages to a particular external provider or with a transaction value greater than US$1 million. The ESB would implement the policy by configuring a mediation, in this case, a monitor mediation.

Complex patterns

Figure 6. Complex patterns
complex patterns

Mediation and interaction patterns can be combined to realize more complex patterns.

For example, a protocol switch followed by a transformation can implement the canonical adapter pattern in which the set of messages and business objects used by all parties is normalized to a canonical format. The canonical adapter pattern converts endpoints' native bus-attachment protocols to a standard protocol, normalizes payload, and reverses these transformations upon delivery.

Another common complex mediation is the transform, log and route pattern.

The gateway pattern is a sophisticated protocol switch variant. It may incorporate transform and monitor mediations to provide encryption and logging, or auditing. It may also aggregate and disaggregate messages in a one-to-many relationship. Service portals typify this pattern, providing a single point of contact for multiple services and hiding the details of internal services.

Deployment patterns

Solution administrators have several choices for ESB topologies. Some common examples are shown below:

  • Global ESB: All services share one namespace, and each service provider is visible to every service requester across a heterogeneous, centrally administered, geographically distributed environment. Used by departments or small enterprises where all the services are likely to be applicable throughout the organization.
  • Directly connected ESB: A common service registry makes all of the services in several independent ESB installations visible. Used where services are provided and managed by a line of business but made available enterprise-wide.
  • Brokered ESB: Bridge services that selectively expose requesters or providers to partners in other domains regulate sharing among multiple ESB installations that each manages its own namespace. Service interactions between ESBs are facilitated through a common broker that implements the bridge services. Used by departments that develop and manage their own services, but share a few of them, or selectively access services provided across the enterprise.
  • Federated ESB: One master ESB to which several dependent ESBs are federated. Service consumers and providers connect to the master or to a dependent ESB to access services throughout the network. Used by organizations that want to federate a set of moderately autonomous departments under the umbrella of a supervising department.
Figure 7. ESB deployment patterns
ESB deployment patterns


The ESB pattern extends the virtualization capabilities of the SOA. Mediations can be composed from standard units of functionality and deployed to facilitate interactions between mismatched service requesters and providers. The ESB also provides a common model for deploying, managing and administering services. ESB concepts enable a separation of concerns according to user role, reducing the conceptual burden on any one person and improving the architecture's consumability. The ESB's comprehensive programming model, componentized tools, and infrastructure support significantly advance the realization of SOA principles.


The authors would like to thank Birgit Schmidt-Wesche, John Whitfield, Malcolm Ayres, Mandy Chessell, Peter Lambros, Rick Robinson, and Robert Berry for their contributions to this article.





developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into SOA and web services on developerWorks

Zone=SOA and web services
ArticleTitle=SOA programming model for implementing Web services, Part 4: An introduction to the IBM Enterprise Service Bus