Enterprise service bus

All customer services communicate in the same way with the ESB: the ESB translates a message to the correct message type and sends the message to the correct producer service.

An enterprise service bus (ESB) is a software architecture model used for designing and implementing the interaction and communication between mutually interacting software applications in service-oriented architecture (SOA). As a software architecture model for distributed computing it is a specialty variant of the more general client server software architecture model and promotes agility and flexibility with regards to communication and interaction between applications. Its primary use is in enterprise application integration (EAI) of heterogeneous and complex landscapes.

Overview

The concept has been developed in analogy to the Bus concept found in computer hardware architecture combined with the modular and concurrent design of high-performance computer operating systems. Motivation was to find a standard, structured and general purpose concept for describing implementation of loosely-coupled software components (called: services) that are expected to be independently deployed, running, heterogeneous and disparate within a network. ESB is also the intrinsically adopted network design of the World Wide Web and the common implementation pattern for Service Oriented Architecture.

Duties of an ESB

An ESB transports the design concept of modern operating systems to networks of disparate and independent computers. Like concurrent operating systems an ESB caters for commodity services in addition to adoption, translation and routing of a client request to the appropriate answering service.

The prime duties of an ESB are:

• Monitor and control routing of message exchange between services
• Resolve contention between communicating service components
• Control deployment and versioning of services
• Marshal use of redundant services
• Cater for commodity services like event handling, data transformation and mapping, message and event queuing and sequencing, security or exception handling, protocol conversion and enforcing proper quality of communication service

ESB and Atomic Services

An ESB generally provides an abstraction layer on top of an implementation of an enterprise messaging system. In order for an integration broker to be considered a true ESB, it would need to have its base functions broken up into their constituent and atomic parts. The atomic components would then be capable of being separately deployed across the bus while working together in harmony as necessary. ^[1]

Ambiguous use of the term ESB in commerce

There is no global standard for ESB.^[2] Most modern providers of Message-oriented middleware have adopted the ESB concept as de facto standard for SOA. Today's implementations of ESB use event-driven and standards-based Message-oriented middleware in combination with message queues as technology frameworks.^[3] Unfortunately confusion is occasionally caused by software manufacturers who relabel their existing middleware and communication solutions as ESB without adopting the crucial spirit of a bus concept.

History and name

The first published usage of the term Enterprise Service Bus is attributed to Roy W. Schulte from the Gartner Group 2002[2] and the book "The Enterprise Service Bus" by David Chappell[3].

• Service - denotes non-iterative and autonomously executing programs that communicate with other services through message exchange
• Bus - is used in analogy to a computer hardware bus
• Enterprise - the concept has been originally invented to reduce complexity of enterprise application integration within an enterprise; the restriction has become obsolete since modern Internet communication is no longer limited to a corporate entity

In fact, the term "bus" was created in the 1980s by Teknekron Software Systems^{[citation needed]}. Frustrated by how software seemed to always under-deliver, while hardware was always on time and under budget, Vivek Ranadivé set out to build software based on the premise of a "Software Bus" (which later became known as "The Information Bus" or TIB), where a "bus" is the standard data highway by which various elements—such as a computer system such as the CPU, the memory, the I/O devices, etc.—communicate. This concept would allow for the "tight" coupling of applications.

In 1986 Teknekron Corporation embarked on a consulting project with Goldman Sachs to redefine the "trading floor of the future" applying this approach. In 1987 the first TIB—for the integration and delivery of market data such as stock quotes, news, and other financial information—went live at Fidelity^{[citation needed]}, followed by First Interstate Bank^{[citation needed]}, then Salomon, eventually digitizing all of Wall Street^{[citation needed]}. Teknekron was later acquired by Reuters in 1994^{[citation needed]} to expand its use of the Information Bus in the financial services markets. In January 1997, Ranadivé founded Tibco Software Inc. to create and market software for use in the integration of business applications outside the financial services sector. In 1998 TIBCO Software released TIB/ActiveEnterprise suite. In July 1999 TIBCO went public on the NASDAQ Stock Market^{[citation needed]} under the ticker symbol TIBX. TIBCO stands for The Information Bus Company.

ESB Architecture

ESB is a modular and component based architecture. It assumes that services are generally autonomous and availability of a service at a certain moment of time cannot be guaranteed. Therefore messages need to be routed consequently through the message bus for buffering (message queuing) to allow inspection and enhancement of content as well as filtering, correction and rerouting of message flow.

Managed Message Processing

The word “bus” reflects the analogy to a computer hardware bus that is common architecture in computer design today. Like in a computer bus it is the basic concept to allow applications to be easily plugged in and out (switched on and off) of the network without impact on other components and without the need to restart the system or even stop running applications.

In an enterprise architecture that makes use of an ESB, an application will communicate via the bus, which acts as the single message turntable between applications. That approach reduces the number of point-to-point connections between communicating applications. This, in turn, makes impact analysis for major software changes simpler and more straightforward. By reducing the number of points-of-contact from and to a particular application, it is easier to monitor for failure and misbehavior in highly complex systems and allows easier changing of components.

It is an essential design concept of an ESB that every client directs all its requests through the ESB instead of passing it directly to a potential server. This indirection allows the ESB to monitor and log the traffic. The ESB can then intervene in message exchange and overwrite standard rules for service execution. Possible uses of an intervention are:

• Buffer and delay a message in a staging area and automatically deliver it when the receiver is ready
• Monitor messages and services to be well-behaving
• Enforce compliance with dynamic processing and security policies
• Marshal service execution based on dynamic rules
• Prioritize, delay, and reschedule message delivery and service execution
• Write logs and raise exception alerts

Another common ESB model is "Publish/Subscribe" or Pub/Sub. In this example, the ESB will route data to active data event "Subscribers" from active data event "Publishers". For example, a name change in the customer system may cause a message to be "Published" on the ESB for use by a number of systems un-known to the "Publisher", but managed by the ESB. Data consumers with active listeners for specific event messages called "Subscribers", can then retrieve the name change messages as they are published.

Enterprise Service Bus Communication Layers

ESB commodity services

An ESB hosts a large collection of services. There will be many commodity services that are useful and regularly needed by other services. Most services deal with directing and marshalling the routing of messages, doing common and often needed data transformations. Popular commodity service are compressing and encrypting data, splitting data into smaller chunks, filter unwanted data, extract routing information from the content via a rule engine.

Basic commodity services rendered by an ESB are the transformation and conversion of multiple protocols. Delegation of protocol conversion, mapping and transformation to an ESB gives services of many different legacies a convenient and standardized way to easily plug into the bus system, no matter which protocol it decides to use to initiate a request or the response needs to be delivered in. That way even older and exotic legacy systems can be easily hooked up into the SOA without requiring the service client to adapt itself to it.

Commonly needed commodity services:

• Event handling - Guarantee event processing
• Protocol conversion - Transparently translate between communication protocols (e.g., HTTP, FTP, REST, SOAP, JSON, DCOM, CORBA, SAP RFC etc.)
• Mapping - Transfer between tabular data formats
• Translation and transformation - Change data content based on rules
• Queuing and buffering - Handle differing data processing speeds between sender and receiver

ESB and message queueing

A mandatory and hence characteristic component of an ESB is a staging (buffering) component that usually is implemented as a message queue and can be controlled and used by internal and external services at discretion. The message queue is required to cope with differing handling speed and temporary failure of services as well as being able to reschedule processing in case of a processing error of a service.

ESB as software

In such a complex architecture, the ESB represents the piece of software that lives 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 ESB. To achieve this objective, the ESB must encapsulate the functionality offered by its component applications in a meaningful way. This typically occurs 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 the ESB receives a message, it routes the message to the appropriate application. Often, because that application evolved without the same message model, the ESB will have to transform the message into a format that the application can interpret. A software “adapter” fulfills the task of effecting these transformations (analogously to a physical adapter). Commentators disagree whether or not these adapters should be considered part of the ESB.

ESBs rely on accurately connecting the enterprise message model and the functionality offered by applications. If the message model does not completely encapsulate the applications’ functionality, then other applications that desire that functionality may have to bypass the bus, and invoke the mismatched applications directly. Doing so violates all of the principles outlined above, and negates many of the advantages of using an ESB.

ESB Hive of Commodity Components

Salient characteristics

Most observers accept certain core capabilities as functions of an ESB:

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

Key benefits

• Increased flexibility; easier to change as requirements change
• Scales from point-solutions to enterprise-wide deployment (distributed bus)
• More configuration rather than integration coding
• No central rules-engine, no central broker
• Incremental patching with zero down-time; enterprise becomes "refactorable"

Key disadvantages

• Increased overhead
• Slower communication speed, especially for those already compatible services

See also

• Enterprise Integration Patterns
• Java Business Integration
• Business Process Management
• Universal Integration Platform
• Enterprise application integration
• Business Service Provider
• Message Oriented Middleware
• Complex event processing
• Event Stream Processing
• Event-driven programming
• Comparison of Business Integration Software
• Comparison of BPEL engines
• Event-driven SOA

Commercial and Open Source Products

A more complete overview can also be found in the Comparison of business integration software in Wikipedia.

Books

• David 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 1-84719-440-0; ISBN 978-1-84719-440-4)
• Michael Bell, "Service-Oriented Modeling: Service Analysis, Design, and Architecture" (2008 Wiley & Sons, ISBN 978-0-470-14111-3)

References

1. ↑ Dilip, Chittoor. "ESB Myth Busters: 10 Enterprise Service Bus Myths Debunked. Clarity of Definition for a Growing Phenomenon". Retrieved 2009-10-05. 
2. ↑ Lapeira, Raul. "ESB is an architectural style, a software product, or a group of software products?". Artifact Consulting. Retrieved 2010-04-16. "The first thing a ESB architect should have in mind is that as of 2010 there is no global standard for ESB." 
3. ↑ Curry, Edward. 2004. "Message-Oriented Middleware". In Middleware for Communications, ed. Qusay H. Mahmoud, 1-28. Chichester, England: John Wiley and Sons. doi:10.1002/0470862084.ch1. ISBN 978-0-470-86206-3
4. ↑ Richards, Mark. "The Role of the Enterprise Service Bus (presentation)". Retrieved 2009-06-04.  "I do not consider process choreography part of an ESB, if we consider an ESB as a high-speed messaging middleware. However, I do consider process choreography part of the ESB *platform*. Fortunately most ESB vendors separate out these major components into different products, but package them under a consolidated ESB offering. So, in the strictest sense of the word, no, I would not consider it as part of an ESB. It is a related capability."

External links

• "Lasting concept or latest buzzword?" (Nicolas Farges, 2003)
• Enterprise service buses hit the road: Infoworld Test Center (July 22, 2005)
• JSR-208: Java Business Integration (August 2005)
• The Role of the Enterprise Service Bus (InfoQ - Video Presentation) (October 23, 2006)
• ESB Roundup Part One: Defining the ESB (InfoQ) (July 13, 2006)
• ESB Roundup Part Two: Use Cases (InfoQ) (July 5, 2006)
• "Services Fabric—Fine Fabrics for New Era Systems" (Binildas A. Christudas, 2007)
• "ESBs in 2007: Taking the Open Source Bus to SOA" (Dennis Byron, September 20, 2007)
• Aggregate Services in ServiceMix JBI ESB: PACKT Publishers (Binildas A. Christudas, November 30, 2007)
• ESB Topology alternatives (InfoQ, A. Louis, May 23, 2008)
• Rethinking the ESB: Building a Simple, Secure, Scalable Service Bus with a SOA Gateway (Computerworld, J. Ryan, 2011)
• Louis, Adrien; Marc Dutoo (2010-07-02). "Choosing between Routing and Orchestration in an ESB". InfoQ. Retrieved 2009-07-02.  Cite uses deprecated parameters (help)
• The Enterprise Service Bus, re-examined (IBM developer Works, Greg Flurry and Kim Clark, May 2011)