IBM®
Skip to main content
    Country/region [select]      Terms of use
 
 
    
     Home      Products      Services & solutions      Support & downloads      My account     
 
developerworks > Dashboard > Bobby Woolf: WebSphere SOA and J2EE in Practice > ... > Service-Oriented Architecture > Enterprise Service Bus
developerWorks
Log In   View a printable version of the current page.
Overview Spaces Forums Blogs Podcasts Wikis Exchange
Enterprise Service Bus
Added by bwoolf, last edited by bwoolf on Dec 04, 2007  (view change)
Labels: 
(None)

Enterprise Service Bus

An enterprise service bus (ESB) is an architectural pattern for a set of connectivity to enable service invocation between the service consumers and service providers that make up the composite applications in a service-oriented architecture.


Definitions

It sometimes seems like everyone you ask has a different (but similar) definition of what an ESB is and does. Here are a few of the most authoitative ones (from IBM, at least):

  • "IBM SOA Foundation: An architectural introduction and overview":

    An enterprise service bus is an architectural pattern.

    The presence of an ESB is fundamental to simplifying the task of invoking services – making the use of services wherever they are needed, independent of the details of locating those services and transporting service requests across the network to invoke those services wherever they reside within your enterprise.


  • IBM SOA Glossary:

    An Enterprise Service Bus (ESB) is a flexible connectivity infrastructure for integrating applications and services by performing the following actions between services and requestors: ROUTING messages between services, CONVERTING transport protocols between requestor and service, TRANSFORMING message formats between requestor and service, and HANDLING business events from disparate sources.


  • "Discover how an ESB can help you meet the requirements for your SOA solution":

    The ESB is a key architectural pattern in the Foundation reference architecture, enabling loosely coupled interconnectivity between service requesters and service providers in service-oriented solutions. Loose coupling permits a clean separation of concerns (temporal, technological, and organizational) between the parts in a solution, enabling flexibility and agility in both business processes and IT systems.


My Definition

I tend to find each definition to be somewhat unsatisfactory. I'm looking for less of a statement about what an ESB is and more about what it does. So here's a definition I'm working on.

First, I should say that I haven't found the term "enterprise" in ESB to be very helpful. An enterprise tends to be a company or organization, yet many buses provide connectivity in a scope much smaller than a complete company, or even larger to include business partners. A truly company-wide bus tends to actually be a federation of many smaller buses. So I tend to ignore the enterprise part and focus more on what a service bus is and does.

Second, of those quoted above, I tend to like the last one because it has more detail. I'd like more detail still, especially around two of the main capabilities an ESB gives you: service virtualization and mediation.

So with that in mind, here's a working definition:

A service bus is an architectural pattern for a messaging layer that achieves service integration by enabling and managing remote invocation of services in a service-oriented architecture. It enables service requestors to invoke service providers remotely and manages the invocations. The bus' management of service invocations helps to decouple requestors and providers and enables service virtualization and mediation. A bus provides connectivity to service providers running outside of the bus; the service providers do not run in the bus.

Service virtualization decouples a service requestor from its service provider by hiding the provider's identity, service interface, and invocation mechanism. It enables multiple providers to act as a single provider of the requestor's service. When a requestor invokes a virtual service, it does not know nor care which provider ultimately executes. Service virtualization allows for: load distribution of service invocations across multiple providers, service providers to be added and removed without affecting the requestors, and providers to be avoided while they are busy or not operating properly without affecting the requestors.

Mediation enables service invocations to be adjusted inside the bus. Mediation for a particular service is implemented as a mediation flow composed of a series (a.k.a. microflow) of mediation primitives. Mediation performs a combination of three basic tasks:

  • Routing - Enables the bus to direct a service invocation to one of multiple different services without needing to transform between interfaces. The target service produces the same behavior as the source service, but is a generalization, a specialization, or backward-compatible version of the source service.
  • Transformation - Enables the bus to fulfill a service invocation by invoking another service that has a different interface but produces the same behavior. For a service invocation, corresponding transformations are applied to both the request and response.
  • Conversion - Enables the bus to fulfill a service invocation between a service requestor and service provider even when they connect to the bus via different network transports or APIs. The source and target service implement the same interface and behavior. For a service invocation, corresponding conversions are applied to both the request and response.

Resources

Some places to learn more (a certainly incomplete list, but a start):


    About IBM Privacy Contact