What Is Enterprise Service Bus? : Composite Materials

Tuesday Apr 11, 2006

What Is Enterprise Service Bus?

Enterprise Service Bus (ESB) is a way to create a service-oriented architecture. Leaving aside the marketing wars between various ESB vendors (and wanna-be vendors), the following are useful definitions of an ESB, and ones that we use in the Open ESB project.

In a Sentence

An Enterprise Service Bus (ESB) is a distributed middleware system for integrating enterprise IT assets using a service-oriented approach.

In a Paragraph

An Enterprise Service Bus (ESB) is a distributed infrastructure used for enterprise integration. It consists of a set of service containers, which integrate various types of IT assets. The containers are interconnected with a reliable messaging bus. Service containers adapt IT assets to a standard services model, based on XML message exchange using standardized message exchange patterns. The ESB provides services for transforming and routing messages, as well as the ability to centrally administer the distributed system.

As a Bullet List

An Enterprise Service Bus (ESB) is an infrastructure used for enterprise integration using a service-oriented approach. Its main features are:

It has a set of service containers, used to adapt a wide variety of IT assets to the ESB.
It has a reliable messaging system, used to allow the service containers to interact.
It has a standard (WSDL) services model is used for inter-container interaction. That is, all adapted assets are modelled using services. An asset can be a provider of services, a consumer of services, or both. The services model is based on message exchange.
It uses messages that are exchanged between containers using standard message exchange patterns.
It uses messages that consist of XML data, and message metadata.
It provides message transformation services
It provides message routing services
It provides security features to control access to services
It is centrally administered, despite being a distributed system.
It allows incremental changes to services without requiring shutdown or other disturbance to system availability.

As I mentioned at the start, ESB is a way to create a SOA, but not the only one. As we have demonstrated at Project Open ESB, JBI is an important element in constructing an ESB, but is not an ESB by itself. Open ESB isn't unique in this regard; the open JBI standard is the basis of several ESBs, both open source and closed.

Posted at 05:40PM Apr 11, 2006 by rtenhove in Service Oriented Architecture | Comments[4]

Comments:

Ron, Thanks for this, one of the clearer summaries of ESB I've seen. I come at this from the BPM side, so I hope my perspective makes sense. Most BPM suites give some kind of lip service to SOA but very few provide an ESB or even talk about it. They all provide an integration framework including introspecting adapters (typically reflecting WSDL and XML request/response schemas), and I'm assuming these adapters are what you call service containers. In many (most?) cases these are synchronous JCA adapters -- I'm not sure if that puts them inside or outside the ESB box. To the extent BPMS talks about ESB at all it seems to be in the context of reliable messaging, transaction management, and security, i.e. the communications infrastructure not the process intelligence. Things like data transformation are done by the process engine not ESB; ditto for message "routing" if you mean it like the old message brokers. Now some ESB providers have added BPEL orchestration (i.e. process engine). It's not on your list, however. From your perspective, what is the relationship between ESB and process orchestration? (For now let's just ditch the business-oriented connotations of BPM.) Depending on what you're selling, either process is an optional part of an ESB or ESB is an optional part of BPM.

Posted by Bruce Silver on April 11, 2006 at 06:40 PM EDT #

Bruce, I'm glad this was of some use to you.

A service container in an ESB can be many things: an integration framework, a host for Java connectors, or even a BPEL engine. Containers provide and consume services; the ESB links the containers together, allowing them to interact.

I don't think it is really profitable to talk about BPMS and ESB; it is more reasonable to talk about BPMS and SOA. (ESB is just a way to create a SOA.) The BPM view of SOA has, to my mind, always been a bit shakey. BPEL is a good example. Orchestration of web services is not equivalent to business process management; web services are not equivalent to the various types of work performers in a BPMS. (I worked on workflow engines years ago, so my definition of "business process" is colored by that experience.)

Your comments about vendors is all too true; ESB has become one of those "must have" acronyms. Since ESB isn't well-defined yet, a lot of marketing muscle is being spent trying to "win" this new market in various ways. To me, ESB will always primarily mean Extra Special Bitter.

Posted by Ron Ten-Hove on April 12, 2006 at 09:19 AM EDT #

Thanks Ron, really helpful. I had some thoughts also (http://www.egjug.org/Enterprise_Service_Bus) and glade we have a couple of common points. Although I believe that a service modeling and orchestration tool is a critical feature that should be mentioned. Now, how far do you think OpenESB or any other ESB really cover the points you mention?

Posted by Hossam Karim on April 15, 2006 at 08:28 PM EDT #

Hossam,

I'm glad you found this definition helpful. The Open ESB team has found it to be helpful as well.

Your points about service orchestration are well taken. Most use cases for an ESB involve creation of composite applications, which almost always involve orchestration. I don't think we disagree there. However, I look at an ESB as a way of creating a SOA, and orchestration as a way of using a SOA. A minor distinction, to be sure. Any "real" ESB will include support for orchestration, such as a BPEL engine.

I think we are getting close to having Open ESB cover all the points I gave in my definition, and you gave in yours; it certainly includes a BPEL engine now.

One of the key features of JBI-based ESB's (such as Open ESB) is extensibility based on standard, plug-in components. This opens the ESB service containers, allowing you to add support for new technologies to the ESB. This is an important (and pragmatic!) feature for any integration technology, which must be extensible to integrate all those things that haven't been integrated in the past!

Posted by 192.18.42.249 on April 17, 2006 at 08:13 AM EDT #