You are on page 1of 8

SOA programming model for implementing Web services, Part 4: An introduction to the I...

Page 1 of 8

SOA programming model for implementing Web

services, Part 4: An introduction to the IBM
Enterprise Service Bus
Level: Intermediate

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

Marc-Thomas Schmidt (, ESB Chief Architect, IBM
Dan Wolfson (, CTO, Business Integration, IBM
Marcia Stockton (, Senior Technical Staff Member, IBM

26 Jul 2005

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.

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
 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 2/19/2008
SOA programming model for implementing Web services, Part 4: An introduction to the I... Page 2 of 8

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

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 2/19/2008
SOA programming model for implementing Web services, Part 4: An introduction to the I... Page 3 of 8

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

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 2/19/2008
SOA programming model for implementing Web services, Part 4: An introduction to the I... Page 4 of 8

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 2/19/2008
SOA programming model for implementing Web services, Part 4: An introduction to the I... Page 5 of 8

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

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
 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
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 2/19/2008
SOA programming model for implementing Web services, Part 4: An introduction to the I... Page 6 of 8

Figure 6. 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

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
 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 2/19/2008
SOA programming model for implementing Web services, Part 4: An introduction to the I... Page 7 of 8

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.

 Read Part 1 of this series, "Introduction to the IBM SOA programming model" (developerWorks, June 2005).

 Link to the Web Services Description Language (WSDL), Version 2.0 Part 0: Primer.

 Visit the developerWorks SOA and Web services zone for extensive how-to information, tools, and project updates on
SOA and Web services technologies.

 Browse all the SOA and Web services articles and free SOA and Web services tutorials available from

 Participate in the discussion forum.

 Get involved in the developerWorks community by participating in developerWorks blogs. 2/19/2008
SOA programming model for implementing Web services, Part 4: An introduction to the I... Page 8 of 8

About the authors

Dr. 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 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, 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 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

The following terms are trademarks of International Business Machines Corporation in the United States, other countries, or both:

Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.
Microsoft is a trademark of Microsoft Corporation in the United States, other countries, or both. Other company, product, or
service names may be trademarks or service marks of others. 2/19/2008