Enterprise service bus

Last updated
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 consumer service. ESB.svg
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 consumer service.

An enterprise service bus (ESB) implements a communication system between mutually interacting software applications in a service-oriented architecture (SOA). It represents a software architecture for distributed computing, and is a special variant of the more general client-server model, wherein any application may behave as server or client. ESB promotes agility and flexibility with regard to high-level protocol communication between applications. Its primary use is in enterprise application integration (EAI) of heterogeneous and complex service landscapes.

Contents

Architecture

The concept of the enterprise service bus 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 for the development of the architecture 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, including the intrinsically adopted network design of the World Wide Web.

No global standards exist 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 existing middleware and communication solutions as ESB without adopting the crucial aspect of a bus concept.

Functions

An ESB applies the design concept of modern operating systems to independent services running within networks of disparate and independent computers. Like concurrent operating systems, an ESB provides commodity services in addition to adoption, translation and routing of client requests to appropriate answering services.

The primary duties of an ESB are:

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. Although a number of companies take credit for coining the phrase, in an interview, Schulte said that the first time he heard the phrase was from a company named Candle and went on to say: "The most direct ancestor to the ESB was Candle’s Roma product from 1998" [3] whose Chief Architect and patent application holder was Gary Aven. Roma was first sold in 1998 making it the first commercial ESB in the market, but that Sonic's product from 2002 was also one of the early ESBs on the market. [4]

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. [5]

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 ESB Component Hive.png
ESB hive of commodity components

Characteristics

CategoryFunctions
Invocationsupport for synchronous and asynchronous transport protocols, service mapping (locating and binding)
Routingaddressability, static/deterministic routing, content-based routing, rules-based routing, policy-based routing
Mediation adapters, protocol transformation, service mapping
Messagingmessage-processing, message transformation and message enhancement
Process choreography¹implementation of complex business processes
Service orchestration²coordination of multiple implementation services exposed as a single, aggregate service
Complex event processing event-interpretation, correlation, pattern-matching
Other quality of service security (encryption and signing), reliable delivery, transaction management
Management monitoring, audit, logging, metering, admin console, BAM (BAM is not a management capability in other words the ESB doesn't react to a specific threshold. It is a business service capability surfaced to end users.)
Agnosticism general agnosticism to operating-systems and programming-languages; for example, it should enable interoperability between Java and .NET applications
Protocol Conversion comprehensive support for topical communication protocols service standards
Message Exchange Patterns support for various MEPs (Message Exchange Patterns) (for example: synchronous request/response, asynchronous request/response, send-and-forget, publish/subscribe)
Adaptersadapters for supporting integration with legacy systems, possibly based on standards such as JCA
Securitya standardized security-model to authorize, authenticate and audit use of the ESB
Transformation facilitation of the transformation of data formats and values, including transformation services (often via XSLT or XQuery) between the formats of the sending application and the receiving application
Validationvalidation against schemas for sending and receiving messages
Governance the ability to apply business rules uniformly
Enrichment enriching messages from other sources
Split and Mergethe splitting and combining of multiple messages and the handling of exceptions
Abstractionthe provision of a unified abstraction across multiple layers
Routing and Transformationrouting or transforming messages conditionally, based on a non-centralized policy (without the need for a central rules-engine)
Commodity Servicesprovisioning of commonly used functionality as shared services depending on context

¹ Some do not regard process choreography as an ESB function. For example, see M.Richards. [6]

² 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. [7] 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. [8]

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, specifically 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

Key disadvantages

Products

Notable products include:

See also

Related Research Articles

The Jakarta Messaging API is a Java application programming interface (API) for message-oriented middleware. It provides generic messaging models, able to handle the producer–consumer problem, that can be used to facilitate the sending and receiving of messages between software systems. Jakarta Messaging is a part of Jakarta EE and was originally defined by a specification developed at Sun Microsystems before being guided by the Java Community Process.

Middleware in the context of distributed applications is software that provides services beyond those provided by the operating system to enable the various components of a distributed system to communicate and manage data. Middleware supports and simplifies complex distributed applications. It includes web servers, application servers, messaging and similar tools that support application development and delivery. Middleware is especially integral to modern information technology based on XML, SOAP, Web services, and service-oriented architecture.

<span class="mw-page-title-main">BEA Systems</span> Defunct American software corporation

BEA Systems, Inc. was a company that specialized in enterprise infrastructure software products, which was wholly acquired by Oracle Corporation on April 29, 2008.

In software engineering, service-oriented architecture (SOA) is an architectural style that focuses on discrete services instead of a monolithic design. By consequence, it is also applied in the field of software design where services are provided to the other components by application components, through a communication protocol over a network. A service is a discrete unit of functionality that can be accessed remotely and acted upon and updated independently, such as retrieving a credit card statement online. SOA is also intended to be independent of vendors, products and technologies.

Enterprise application integration (EAI) is the use of software and computer systems' architectural principles to integrate a set of enterprise computer applications.

An enterprise messaging system (EMS) or messaging system in brief is a set of published enterprise-wide standards that allows organizations to send semantically precise messages between computer systems. EMS systems promote loosely coupled architectures that allow changes in the formats of messages to have minimum impact on message subscribers. EMS systems are facilitated by the use of structured messages, and appropriate protocols, such as DDS, MSMQ, AMQP or SOAP with web services.

Java Business Integration (JBI) is a specification developed under the Java Community Process (JCP) for an approach to implementing a service-oriented architecture (SOA). The JCP reference is JSR 208 for JBI 1.0 and JSR 312 for JBI 2.0. JSR 312 was removed from the JCP balloting process on 17 Dec, 2010 by the submitters without being accepted.

An XML appliance is a special-purpose network device used to secure, manage and mediate XML traffic. They are most popularly implemented in service-oriented architectures (SOA) to control XML-based web services traffic, and increasingly in cloud-oriented computing to help enterprises integrate on premises applications with off-premises cloud-hosted applications. XML appliances are also commonly referred to as SOA appliances, SOA gateways, XML gateways, and cloud brokers. Some have also been deployed for more specific applications like Message-oriented middleware. While the originators of the product category deployed exclusively as hardware, today most XML appliances are also available as software gateways and virtual appliances for environments like VMWare.

Mule is a lightweight enterprise service bus (ESB) and integration framework provided by MuleSoft. It has a Java-based platform and can alap act as broker for interactions between other platforms such as .NET using web services or sockets.

Oracle Fusion Middleware consists of several software products from Oracle Corporation. FMW spans multiple services, including Java EE and developer tools, integration services, business intelligence, collaboration, and content management. FMW depends on open standards such as BPEL, SOAP, XML and JMS.

This article is a comparison of notable business integration and business process automation software.

IBM App Connect Enterprise is IBM's premier integration software offering, allowing business information to flow between disparate applications across multiple hardware and software platforms. Rules can be applied to the data flowing through user-authored integrations to route and transform the information. The product can be used as an Enterprise Service Bus supplying a communication channel between applications and services in a service-oriented architecture.

<span class="mw-page-title-main">Message broker</span> Computer program module

A message broker is an intermediary computer program module that translates a message from the formal messaging protocol of the sender to the formal messaging protocol of the receiver. Message brokers are elements in telecommunication or computer networks where software applications communicate by exchanging formally-defined messages. Message brokers are a building block of message-oriented middleware (MOM) but are typically not a replacement for traditional middleware like MOM and remote procedure call (RPC).

OpenESB is a Java-based open-source enterprise service bus. It can be used as a platform for both enterprise application integration and service-oriented architecture. OpenESB allows developers to integrate legacy systems, external and internal partners and new development in business processes. It supports a multitude of integration technologies including standard JBI, XML with support for XML Schemas, WSDL, and BPEL with the aim of simplicity, efficiency, long-term durability, and low TCO.

Oracle Enterprise Service Bus, a fundamental component of Oracle's Services-Oriented Architecture suite of products, provides integration of data and enterprise applications within an organisation and their connected enterprises.

<i>Enterprise Integration Patterns</i>

Enterprise Integration Patterns is a book by Gregor Hohpe and Bobby Woolf and describes 65 patterns for the use of enterprise application integration and message-oriented middleware in the form of a pattern language.

Event-driven SOA is a form of service-oriented architecture (SOA), combining the intelligence and proactiveness of event-driven architecture with the organizational capabilities found in service offerings. Before event-driven SOA, the typical SOA platform orchestrated services centrally, through pre-defined business processes, assuming that what should have already been triggered is defined in a business process. This older approach does not account for events that occur across, or outside of, specific business processes. Thus complex events, in which a pattern of activities—both non-scheduled and scheduled—should trigger a set of services is not accounted for in traditional SOA 1.0 architecture.

Middleware analysts are computer software engineers with a specialization in products that connect two different computer systems together. These products can be open-source or proprietary. As the term implies, the software, tools, and technologies used by Middleware analysts sit "in-the-middle", between two or more systems; the purpose being to enable two systems to communicate and share information.

A canonical model is a design pattern used to communicate between different data formats. Essentially: create a data model which is a superset of all the others ("canonical"), and create a "translator" module or layer to/from which all existing modules exchange data with other modules. The canonical model acts as a middleman. Each model now only needs to know how to communicate with the canonical model and dont need to know the implementation details of the other modules.

The JBoss Enterprise SOA Platform is free software/open-source Java EE-based service-oriented architecture (SOA) software. The JBoss Enterprise SOA Platform is part of the JBoss Enterprise Middleware portfolio of software. The JBoss Enterprise SOA Platform enables enterprises to integrate services, handle business events, and automate business processes, linking IT resources, data, services and applications. Because it is Java-based, the JBoss application server operates cross-platform: usable on any operating system that supports Java. The JBoss SOA Platform was developed by JBoss, now a division of Red Hat.

References

  1. ↑ Lapeira, Raul. "ESB is an architectural style, a software product, or a group of software products?". Artifact Consulting. Archived from the original on 2014-08-08. Retrieved 2010-04-16. The first thing an 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" [ permanent dead link ]. 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. ↑ McKendrick, Joe. "The great ESB squabble of 2005". ZDNet. Retrieved 2020-12-31.
  4. ↑ "Difference between a Message Broker and an ESB" . Retrieved 2017-07-19.
  5. ↑ "Enterprise Service Bus [Book]".
  6. ↑ 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.
  7. ↑ Feraga, Matthias (6 Jun 2011). "How to: choosing between lightweight and traditional ESBs". Octo. Retrieved 23 April 2014.
  8. ↑ Fulton, Larry (12 Sep 2007). "Learn How to Embrace Lightweight ESBs". Fo2014. Archived from the original on 27 January 2022. Retrieved 23 April 2014.

Further reading

This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.