Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Standard view
Full view
of .
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1


Ratings: (0)|Views: 49|Likes:
Published by api-26854087

More info:

Published by: api-26854087 on Oct 19, 2008
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less





SOA programming model for implementing Web
services, Part 4: An introduction to the IBM
Enterprise Service Bus
Level: Intermediate
Dr. Beth Hutchison (beth_hutchison@uk.ibm.com
), Senior Technical Staff Member, IBM
Marc-Thomas Schmidt (mtschmidt@uk.ibm.com

), ESB Chief Architect, IBM
Dan Wolfson (dwolfson@us.ibm.com), CTO, Business Integration, IBM
Marcia Stockton (mls@us.ibm.com), 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\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
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\u2019s 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:

\ue000Location 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.
\ue000Interaction 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
\ue000Interface: 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.
\ue000Qualities of (Interaction) Service (QoS): Participants declare their QoS requirements, including performance and
Page 1 of 8
SOA programming model for implementing Web services, Part 4: An introduction to the I...

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

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:
\ue000Discover and describe: Identify and describe the SIPs that can be interconnected across the ESB. This includes new
Page 2 of 8
SOA programming model for implementing Web services, Part 4: An introduction to the I...
service creation, existing service discovery, and description of their interfaces, requirements and capabilities.
\ue000Model and build: Interconnect SIPs through new or existing mediations to describe the end-to-end interactions of a
\ue000Configure and deploy: Configure an abstract declaration of a solution for a particular runtime topology and deploy it,
creating the necessary runtime artifacts.
\ue000Monitor 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
Page 3 of 8
SOA programming model for implementing Web services, Part 4: An introduction to the I...

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->