ESB Patterns that "Click"

One of the highlights of my trip to IBM Software University 2006 in Las Vegas last week was a session led by Marc-Thomas Schmidt, IBM Distinguished Engineer and Chief Architect WebSphere Enterprise Service Bus. He presented some architectural patterns which just “clicked” with me and I hope will “click” with any of my readers who might also be digging into Service Oriented Architectures (SOA) and the concepts behind an Enterprise Service Bus (ESB) in particular. With his permission, I will share some of the concepts he presented with you. Click on the embedded graphics to get a larger, more readable view.

What is an ESB
With an ESB, 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 ESB provides virtualization of:

• Location and Identity – participants need not know the location or identity of other participants, e.g., requesters need not be aware that a request could be serviced by any of several providers; service providers can be added or removed without disruption.


• Interaction protocol or style – 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). Interaction partners may chose to use one-way, request/response, asynchronous, synchronous, and publish/subscribe type interactions


• Interface – requesters and providers need not agree on 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 through policies which include, for example: performance and reliability, encryption of message contents, routing algorithms (e.g. to available implementations, based on workload distribution criteria, and so forth). Policies that describe the QoS requirements and capabilities of requesters and providers may be fulfilled by the services themselves or by the ESB compensating for mismatches.

As depicted in the left hand part of the picture, 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.

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.

The basic ESB pattern abstracts application components into a set of services that interact via a bus rather than through direct, point-to-point communications. A given service can be a provider, a requester, or both. 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.

Patterns for building ESB-based solutions are classified as: interaction patterns to enable service interaction points to dispatch messages to or receive messages from the bus, mediation patterns to enable the manipulation of message exchanges, and deployment patterns to support solution deployment into a federated infrastructure.

Interaction patterns

The ESB enables endpoints to interact in their native interaction mode via the bus. It supports a variety of endpoint protocols and interaction styles. A few examples of interaction patterns include request / response, request / multi-response or event propagation:

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 semantically matching but structurally incompatible provider selected from a set of potential endpoints.

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.

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


• 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 via a common broker that implements the bridge services. Used by departments which 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.

I throw in some additional graphics which seem to resonate with me (forgive me for not explaining them all in great detail) but I'll ask you to probe further at an article co-authored by Marc: SOA programming model for implementing Web services, Part 4: An introduction to the IBM Enterprise Service Bus.