Enterprise service bus

From Wikipedia, the free encyclopedia

 This article needs additional citations for verification.
Please help improve this article by adding reliable references. Unsourced material may be challenged and removed. (October 2007)
This article or section is in need of attention from an expert on the subject.

WikiProject Computing or the Computing Portal may be able to help recruit one.

If a more appropriate WikiProject or portal exists, please adjust this template accordingly.

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.

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, ESB is not necessarily web-services based[citation needed]. 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, e.g. Business Process Execution Language (BPEL).

Contents

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

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

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

[edit] Salient characteristics

 This section needs additional citations for verification.
Please help improve this article by adding reliable references. Unsourced material may be challenged and removed. (October 2007)

"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, 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:

Category Functions
Invocation Support for synchronous and asynchronous transport protocols, service mapping (locating and binding)
Routing Addressability, static/deterministic routing, content-based routing, rules-based routing, policy-based routing
Mediation Adapters, protocol transformation, service mapping
Messaging Message processing, message transformation and message enhancement
Process Choreography1 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

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

[edit] 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". (please cite reference or explain this.)

[edit] 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.[1]

[edit] See also

[edit] 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)

[edit] References

  1. ^ ESB-Oriented Architectures considered harmful

[edit] External links