Enterprise service bus

From Wikipedia, the free encyclopedia

  (Redirected from Enterprise Service Bus)
Jump to: navigation, search
 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 is in need of attention from an expert on the subject. WikiProject Computing or the Computing Portal may be able to help recruit one. (November 2008)

In computing, an enterprise service bus (ESB) consists of a software architecture construct which provides fundamental services for complex architectures via an event-driven and standards-based messaging-engine (the bus). Developers typically implement an ESB using technologies found in a category of middleware infrastructure products, usually based on recognized standards.

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. Unlike the more classical enterprise application integration (EAI) approach of a monolithic stack in a hub and spoke architecture, an enterprise service bus builds on base functions broken up into their constituent parts, with distributed deployment where needed, working in harmony as necessary.

An ESB does not itself implement a service-oriented architecture (SOA) but provides the features with which one may implement such. An ESB does not necessarily depend on web-services[citation needed]. An ESB should[citation needed] build on the basis of standards and provide flexibility, supporting many transport mediums capable of implementing both traditional SOA patterns as well as SOA 2.0-enriched business architecture. ESBs attempt to isolate the coupling between the service called and the transport medium. Most ESB providers incorporate SOA principles and allow for independent message formats.

Contents

[edit] Definitions and scope

Commentators[who?] disagree over whether to define an enterprise service bus as 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" almost always denotes the software infrastructure that enables such an architecture, and in essence, the ESB is considered a platform to realize a service-oriented 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 loose coupling and easy connection between services.[citation needed]

[edit] ESB architecture

Use of the word "bus" stems from 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. Such an approach has the primary advantage 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 represents 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 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 legacy format that the application can interpret. A software "adapter" fulfills the task of effecting these transformations (analogously to a physical adapter). Commentators[who?] disagree as to whether to consider these adapters as part of the ESB or not.

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.

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

The phrase "Enterprise Service Bus" serves as a convenient catch-all term for a set of capabilities, which systems can implement in different ways. Commentators[who?] debate over whether to regard an ESB as a tangible product or as an architectural style, and on exactly how to implement an ESB (for example: centralised (broker or hub) versus decentralised (smart endpoints)). For example, some SOA practitioners claim that SOAP + WS-Addressing is the bus. In any case, most observers[who?] accept certain core capabilities as 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 choreography[1] 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


² 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[by whom?] to exhibit the following characteristics:

  • general agnosticism to operating-systems and programming-languages; for example, it should enable interoperability between Java and .NET applications
  • general use of XML as the standard communication language
  • support for web-services standards
  • support for various MEPs (Message Exchange Patterns) (for example: synchronous request/response, asynchronous request/response, send-and-forget, publish/subscribe)
  • adapters for supporting integration with legacy systems, possibly based on standards such as JCA
  • a standardized security-model to authorize, authenticate and audit use of the ESB
  • 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
  • validation against schemas for sending and receiving messages
  • the ability to apply business rules uniformly
  • enriching messages from other sources
  • the splitting and combining of multiple messages and the handling of exceptions
  • the provision of a unified abstraction across multiple layers
  • routing or transforming messages conditionally, based on a non-centralized policy (without the need for a central rules-engine)
  • queuing, holding messages if applications temporarily become unavailable

[edit] Key benefits

 This section is written like an advertisement. Please help rewrite this section from a neutral point of view. (June 2009)
  • 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 patching with zero down-time; enterprise becomes "refactorable".

[edit] Key disadvantages

  • Usually requires an Enterprise Message Model, resulting in additional management overhead. Potential difficulties integrating many disparate systems to collaborate via 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.
  • Middleware analysis 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. The increased latency also results from additional XML processing (the ESB normally uses XML as the communication language).
  • ESB becomes a single point of failure.
  • Though ESB systems can require a significant effort to implement, they produce no commercial value without the subsequent development of SOA services for the ESB.[2]

[edit] See also

[edit] Books

[edit] References

  1. ^ Richards, Mark. "The Role of the Enterprise Service Bus (presentation)". http://www.infoq.com/presentations/Enterprise-Service-Bus. Retrieved on 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."
  2. ^ Woolf, Bobby (2007-09-27). "ESB-oriented architecture: The wrong approach to adopting SOA". developerWorks. IBM. http://www.ibm.com/developerworks/webservices/library/ws-soa-esbarch/. Retrieved on 2009-06-22. "An ESB-oriented architecture doesn't produce business value. A project based on ESB-oriented architecture needs to be made into one based on SOA to help ensure that it successfully delivers business value." 

[edit] External links

Retrieved from "http://en.wikipedia.org/wiki/Enterprise_service_bus"
Personal tools