ESB defination

Enterprise service bus

From Wikipedia, the free encyclopedia

(Redirected from Enterprise Service Bus)

Jump to: navigation, search

In computing, an enterprise service bus (ESB) refers to a software architecture construct, implemented by technologies found in a category of middleware infrastructure products usually based on standards, that provides foundational 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 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

[hide]

• 1 Salient characteristics
• 2 Key benefits
• 3 Key disadvantages
• 4 See also
• 5 Footnotes
• 6 Books
• 7 External links

[edit] Salient characteristics

"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 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, publish/subscribe Other Quality of Service Security (encryption and signing), reliable delivery, transaction management Management Monitoring, audit, logging, metering, admin console, BAM

¹ Some do not consider Process Choreography to be an ESB function. E.g., In the IBM WebSphere suite of products, WebSphere Process Server is a separate product to WebSphere 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.

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 is monitored for various SLA (Service Level Agreement) threshold message latencies and other SLA characteristics.
• It (often) facilitates "service classes," responding appropriately to higher and lower priority users.
• 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 mandatory.
• Value of the ESB requires many disparate systems to collaborate on message standards.
• Without forward planning, the versioning of messages between systems can cause tight coupling instead of the intended loose coupling.
• Vendor depending, it requires more hardware to run.
• New skills needed to configure ESB.
• Extra translation layer when compared to regular messaging solutions. Instead of contacting the message recipient directly, the sender contacts the bus, who then contacts the recipient for it.
• Rarely realizes ROI (Return On Investment) within first few projects; next few projects generally refine messages and services; the fifth project may begin to realize ROI.^{[citation needed]}
• For effective implementation, requires a mature IT governance model (such as ITIL) and a well-defined enterprise strategy to be in place already.
• If used as designed, it does not eliminate the one-to-many interfaces (custom mapping) between a service provider and its consumers, rather it shifts this complexity to the middle layer (the ESB). Therefore, it can hinder the promotion of standard interfaces in favor of "manage all customizations in the ESB"

 Supplement

1. ESBs must provide adapters to enterprise data sources (SAP, Peoplesoft, Oracle, SQL Server)
2. ESBs must support at least rudimentary business process management
3. Open standards (JMS, Web services) support is/was a requirement for our ESB implementation
4. An ESB must integrate smoothly with existing enterprise application integration (EAI) and message-oriented products. 

• A consumer talks HTTP/S based authentication, a producer uses WS-Security
• A consumer talks HTTP/RSS, a producer uses WebSphere MQ or JMS
• A consumer talks HTTP/REST and URIs, a producer talks SOAP/WSDL
• A consumer has one set of credentials, a producer has another set (keychain mapping).
• An FTP site is the "service interface" for one end, but the files are broken up into JMS messages on the other end
• A message may need enrichment before routing to a destination, so I can perform callouts to gather extra information
• Protocol independent load-balancing and/or failover is required for a producer
• Messages need to stored and forwarded, retrofitting reliability onto an unreliable service