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 implementing a communication system between mutually interacting software applications in a service-oriented architecture (SOA). It implements a software architecture as depicted on the right. As it implements a software architecture for distributed computing, it implements a special variant of the more general client-server model therefore also. Whereas in general any application using ESB can behave as server or client in turns. ESB promotes agility and flexibility with regard to high protocol-level communication between applications. The primary goal of the high protocol-level communication is enterprise application integration (EAI) of heterogeneous and complex landscapes.

Overview

The concept is analogous to the bus concept found in computer hardware architecture combined with the modular and concurrent design of high-performance computer operating systems. The 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 a common implementation pattern for service-oriented architecture.

Working

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 primary 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

Ambiguous use of the term ESB in commerce

There is no global standard for enterprise service bus concepts or implementations.^[1] Most providers of message-oriented middleware have adopted the enterprise service bus concept as de facto standard for a service-oriented architecture. The implementations of ESB use event-driven and standards-based message-oriented middleware in combination with message queues as technology frameworks.^[2] However, some software manufacturers relabel their existing middleware and communication solutions as ESB without adopting the crucial aspect of a bus concept.

History

The first published usage of the term "enterprise service bus" is attributed to Roy W. Schulte from the Gartner Group 2002 and the book The Enterprise Service Bus by David Chappell.

• 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. 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, followed by First Interstate Bank, then Salomon, eventually digitizing all of Wall Street. Teknekron was later acquired by Reuters in 1994 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 under the ticker symbol TIBX. Tibco stands for The Information Bus Company.

ESB as software

The ESB is implemented in software that operates 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 transmits and receives. 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 has 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.^[3]

ESBs rely on accurately constructing the enterprise message model and properly designing the functionality offered by applications. If the message model does not completely encapsulate the application functionality, then other applications that desire that functionality may have to bypass the bus, and invoke the mismatched applications directly. Doing so violates the principles of the ESB model, and negates many of the advantages of using this architecture.

The beauty of the ESB lies in its platform-agnostic nature and the ability to integrate with anything at any condition. It is important that Application Lifecycle Management vendors truly apply all the ESB capabilities in their integration products while adopting SOA. Therefore, the challenges and opportunities for EAI vendors are to provide an integration solution that is low-cost, easily configurable, intuitive, user-friendly, and open to any tools customers choose.

ESB hive of commodity components

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

These solutions often focus on low-level ESB functions, such as connectivity, routing and transformation, and require coding or scripting to implement orchestration.^[5] Developers operating at a project or tactical level, e.g., just trying to fix a problem, often gravitate toward lightweight service bus technologies, but there is often ongoing tension between these initiatives and an enterprise architecture whose goal it is to optimize infrastructure across multiple projects.^[6]

If the message broker, the ESB software, translates a message from one format to another, then as with any translation, there is the issue of semantics of the message. For example, a record can be translated from JSON to XML, but the same set of fields can be interpreted differently by different applications, specially in the case of the various corner cases that are usually known only to developers that have extensive experience with the application that is connected to the ESB. For the known corner cases the number of tests that cover all corner cases increases exponentially with every application that is connected to the ESB, because every ESB-connected application must be tested against every other application that is connected to the ESB.

Key benefits

• Scales from point-solutions to enterprise-wide deployment (distributed bus)
• More configuration rather than integration coding
• No central rules-engine, no central broker
• Easy plug-in and plug-out and loosely coupling system
• Incremental patching with zero down-time; enterprise becomes "refactorable"

Key disadvantages

• 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
• Comparison of BPMN 2.0 Engines
• Composite application
• Event-driven SOA

Existing ESB products

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

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. ↑ 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. 
2. ↑ 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
3. ↑ http://shop.oreilly.com/product/9780596006754.do
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."
5. ↑ Feraga, Matthias (6 Jun 2011). "How to: choosing between lightweight and traditional ESBs". Octo. Retrieved 23 April 2014. 
6. ↑ Fulton, Larry (12 Sep 2007). "Learn How to Embrace Lightweight ESBs". Fo2014. 

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. 
• The Enterprise Service Bus, re-examined (IBM developer Works, Greg Flurry and Kim Clark, May 2011)
• Six Problems When Implementing an Enterprise Service Bus (Adeptia, Raman Singh)