), ESB Chief Architect, IBM
Dan Wolfson (firstname.lastname@example.org), CTO, Business Integration, IBM
Marcia Stockton (email@example.com), Senior Technical Staff Member, IBM
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\u00ae MQ, IBM CICS\u00ae or IBM IMS\u2122, Java\u2122 2 Platform, Enterprise Edition (J2EE) Enterprise JavaBeans (EJB), Java classes, IBM DB2\u00ae Queries, Java Message Services (JMS), or Microsoft\u00ae .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
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:
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).
Interposing the bus between participants provides the opportunity to modulate their interaction through a logical construct called am e dia tio n. 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.
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.
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.
This action might not be possible to undo. Are you sure you want to continue?