Enterprise service bus

In computing, an enterprise service bus (ESB) refers to a software architecture construct. This construct is typically implemented by technologies found in a category of middleware infrastructure products, usually based on recognized standards, which provide fundamental services for more complex architectures via an event-driven and standards-based messaging engine (the bus).

An ESB generally provides an abstraction layer on top of an implementation of an enterprise messaging system, which allows integration architects to exploit the value of messaging without writing code. Contrary to the more classical enterprise application integration (EAI) approach of a monolithic stack in a hub and spoke architecture, the foundation of an enterprise service bus is built of base functions broken up into their constituent parts, with distributed deployment where needed, working in harmony as necessary.

An ESB does not implement a service-oriented architecture (SOA) but provides the features with which one may be implemented. Although it is a common belief, an ESB is not necessarily web-services basedFact|date=February 2007. An ESB should be standards-based and flexible, supporting many transport mediums. Based on EAI rather than SOA patterns, it tries to remove the coupling between the service called and the transport medium.

Most ESB providers now build ESBs to incorporate SOA principles and increase their sales.

What is an Enterprise Service Bus?

There is some disagreement on whether an enterprise service bus is an architectural style, a software product, or a group of software products. While use of an ESB certainly implies adherence to a particular architecture, the term "enterprise service bus" is almost always used to denote the software infrastructure that enables such an architecture.

An Enterprise Service Bus (ESB) brings flow-related concepts such as transformation and routing to a Service-Oriented Architecture. An ESB can also provide an abstraction for endpoints. This promotes flexibility in the transport layer and enables pluggability of POJO services.

ESB Architecture

The word "bus" is a reference to the physical bus that carries bits between devices in a computer. The enterprise service bus serves an analogous function at a higher level of abstraction. In an enterprise architecture making use of an ESB, an application will communicate via the bus, which acts as a message broker between applications. The primary advantage of such an approach is that it reduces the number of point-to-point connections required to allow applications to communicate. This, in turn, makes impact analysis for major software changes simpler and more straightforward. By reducing the number of points-of-contact to a particular application, the process of adapting a system to changes in one of its components becomes easier.

ESB as Software

In such a complex architecture, the ESB is the piece of software that lies between the business applications and enables communication among them. Ideally, the ESB should be able to replace all direct contact with the applications on the bus, so that all communication takes place via the bus. In order to achieve this objective, the bus must encapsulate the functionality offered by its component applications in a meaningful way. This is typically accomplished through the use of an enterprise message model. The message model defines a standard set of messages that the ESB will both transmit and receive. When it receives a message, it routes it to the appropriate application. Often, because the application was not built with the message model in mind, the ESB will have to transform the message into a legacy format that is understandable by the application. The software responsible for effecting these transformations is referred to as an adapter (analogous to a physical adapter). It is not widely agreed whether these adapters should be considered part of the ESB or not.

The connection between the enterprise message model and the functionality offered by the applications is crucial. If the message model does not completely encapsulate the applications' functionality, then other applications that desire that functionality will be forced to bypass the bus and invoke the applications directly. Doing so violates all of the principles outlined above, and negates many of the advantages of using an ESB.

Further description of an ESB is difficult because it is neither a single product nor a formal standard. To provide further details about the behavior and nature of an ESB necessarily requires using generalities. ESBs are typically built around the exchange of XML messages. (As such, the enterprise message model is defined in terms of a series of XML Schema definitions describing the set of legal messages.) While Web Services are not used exclusively, their use is common, and the message exchange is almost always done in a platform-independent manner. This allows the ESB to integrate applications that run on a variety of mainframe and client-server operating systems.

alient characteristics

"Enterprise Service Bus" is a convenient catch-all term for a set of "capabilities", which can be implemented in different ways. There is considerable debate on whether an ESB is a tangible product or an architectural style, and on exactly how an ESB may be implemented (e.g., centralised (broker or hub) versus decentralised (smart endpoints)). For example, [http://jim.webber.name/downloads/presentations/2005-10-Quarterly-Technology-Briefing.ppt some SOA practitioners claim] that SOAP + WS-Addressing is the Bus. In any case, certain core capabilities are generally accepted as being functions of an ESB:

¹ "Some do not consider Process Choreography to be an ESB function.

² "While Process Choreography supports implementation of complex business processes that require coordination of multiple business services (usually using BPEL), Service Orchestration enables coordination of multiple implementation services (most suitably exposed as an aggregate service) to serve individual requests."

In addition, an ESB is expected to exhibit the following characteristics:
* It is usually operating-system and programming-language agnostic; for example, it should enable interoperability between Java and .NET applications.
* It uses XML (eXtensible Markup Language) as the standard communication language.
* It supports web-services standards.
* It supports various MEPs (Message Exchange Patterns) (e.g., synchronous request/response, asynchronous request/response, send-and-forget, publish/subscribe).
* It includes adapters for supporting integration with legacy systems, possibly based on standards such as JCA
* It includes a standardized security model to authorize, authenticate and audit use of the ESB.
* To facilitate the transformation of data formats and values, it includes transformation services (often via XSLT or XQuery) between the format of the sending application and the receiving application.
* It includes validation against schemas for sending and receiving messages.
* It can uniformly apply business rules, enriching messages from other sources, the splitting and combining of multiple messages and the handling of exceptions.
* It can provide a unified abstraction across multiple layers
* It can route or transform messages conditionally, based on a non-centralized policy (i.e. no central rules-engine needs to be present).
* It supports queuing, holding messages if applications are temporarily unavailable.

Key benefits

* Faster and cheaper accommodation of existing systems.
* Increased flexibility; easier to change as requirements change.
* Standards-based.
* Scales from point solutions to enterprise-wide deployment (distributed bus).
* Predefined ready-for-use service types.
* More configuration rather than integration coding.
* No central rules engine, no central broker.
* Incremental changes can be applied with zero down-time; enterprise becomes "refactorable" Fact|date=August 2008.

Key disadvantages

* Enterprise Message Model is usually required, resulting in additional management overhead. May not be a simple task to achieve many disparate systems collaborating on message standards.
* Requires ongoing management of message versions to ensure the intended benefit of loose coupling. Incorrect, insufficient, or incomplete management of message versions can result in tight coupling instead of the intended loose coupling.
* It normally requires more hardware than simple point to point messaging.
* New skills needed to configure, manage, and operate an ESB.
* Extra overhead and increased latency caused by messages traversing the extra ESB layer, especially as compared to point to point communications.
* Some critics remark that ESB require a significant effort to implement, but produces no value unless SOA services are subsequently created for the ESB. [ [http://www.infoq.com/news/2007/08/esb-oriented-architecture ESB-Oriented Architectures considered harmful] ]

ee also

* Enterprise Integration Patterns
* Java Business Integration
* Service-oriented architecture
* Business Process Management
* Universal Integration Platform
* Comparison of Business Integration Software
* Enterprise application integration
* Service-Oriented Architecture Implementation Framework
* Business Service Provider
* Message Oriented Middleware
* Complex Event Processing
* Event Stream Processing
* Service-Oriented Modeling
* Event-driven programming

Books

* Dave Chappell, "Enterprise Service Bus" (O’Reilly: June 2004, ISBN 0-596-00675-6)
* Binildas A. Christudas, "Service Oriented Java Business Integration" (Packt Publishers: February 2008, ISBN 1847194400; ISBN 13 978-1-847194-40-4)
* Michael Bell, "Service-Oriented Modeling: Service Analysis, Design, and Architecture" (2008 Wiley & Sons, ISBN 978-0-470-14111-3)

References

External links

* [http://www.infoq.com/presentations/Enterprise-Service-Bus The Role of the Enterprise Service Bus (InfoQ - Video Presentation)] (October 23, 2006)
* [http://www.infoq.com/articles/ESB-Roundup-Part1-Defining-ESB ESB Roundup Part One: Defining the ESB (InfoQ)] (July 13, 2006)
* [http://www.infoq.com/news/ESB-Roundup-Part-Two--Use-Cases ESB Roundup Part Two: Use Cases (InfoQ)] (July 5, 2006)
* [http://www.jcp.org/en/jsr/detail?id=208 JSR-208: Java Business Integration] (August 2005)
* [http://www.infoworld.com/article/05/07/22/30FEesb_1.html Enterprise service buses hit the road: Infoworld Test Center] (July 22, 2005)
* [http://searchwebservices.techtarget.com/tip/1,289483,sid26_gci913058,00.html "Lasting concept or latest buzzword?"] (Nicolas Farges, 2003)
* [http://www.iasahome.org/c/portal/layout?p_l_id=PUB.1.266&p_p_id=20&p_p_action=1&p_p_state=exclusive&p_p_col_id=null&p_p_col_pos=3&p_p_col_count=4&_20_struts_action=%2Fdocument_library%2Fget_file&_20_folderId=62&_20_name=19-Services.pdf "Services Fabric—Fine Fabrics for New Era Systems"] (Binildas A. Christudas, 2007)
* [http://www.webopedia.com/TERM/E/ESB.html "What is ESB?"] (June 4, 2004)
* [http://www.ebizq.net/hot_topics/esb/features/8480.html "ESBs in 2007: Taking the Open Source Bus to SOA"] (Dennis Byron, September 20, 2007)
* [http://www.infoq.com/articles/louis-esb-topologies ESB Topology alternatives] (InfoQ, A. Louis, May 23, 2008)
* [http://www.infoq.com/articles/louis-dutoo-esb-routing Choosing between Routing and Orchestration in an ESB] (InfoQ, A. Louis & M. Dutoo, July 2, 2008)
* [http://www.packtpub.com/article/aggregate-services-in-servicemix-jbi-esb Aggregate Services in ServiceMix JBI ESB: PACKT Publishers] (Binildas A. Christudas, November 30, 2007)