Enterprise service bus

出典: Wikipedia
移動: ナビゲーション, 検索
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 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-orientated architecture (SOA) but provides the features with which one may be implemented. Although a common belief, ESB is not web-services based[citation needed]. ESB should be standards-based and flexible, supporting many transport mediums. Based on EI rather than SOA patterns, it tries to remove the coupling between the service called and the transport medium.

Most ESB providers (e.g. Oracle) now build ESBs to incorporate SOA principles and increase their sales, e.g BPEL.

Contents [hide]
1 Salient characteristics
2 Key benefits
3 Key disadvantages
4 Software
5 See also
6 Footnotes
7 Books
8 External links

[編集] Salient characteristics
Although the exact definition of an ESB varies, most agree that the following characteristics are common:

It is not an implementation of service-oriented architecture.
The Enterprise Service Bus (ESB) is to SOA as SOA is to e-business on demand.
The Enterprise Service Bus is emerging as a service-oriented infrastructure component that makes large-scale implementation of the SOA principles manageable in a heterogeneous world.
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 messaging (synchronous, asynchronous, point-to-point, publish-subscribe).
It includes standards-based adapters (such as J2C/JCA) for supporting integration with legacy systems.
It includes support for service orchestration and choreography.
It includes intelligent content-based routing services (itinerary routing).
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) 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 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.
It is comprised of selectively deployed application adapters in a (geographically) distributed environment.

[編集] 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).
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".

[編集] Key disadvantages
EMM 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.
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.

[編集] Software
Software AG crossvision Service Orchestrator
Oracle Enterprise Service Bus
Project Open ESB, an open-source ESB based on Java Business Integration, home page
Bostech Corporation ChainBuilder ESB, an open-source ESB based on Java Business Integration spec
Cordys Enterprise Service Bus
SUN Java Composite Application Platform Suite
BEA Aqualogic Service Bus
Fiorano Enterprise Service Bus
BridgeGate Enterprise Service Bus
Mule, an OpenSource ESB-framework, home page
Apache ServiceMix, an OpenSource ESB based on JBI specification, home page
Celtix - Open Source Java ESB framework
Wax Digital ESB
PEtALS - Open Source JBI compliant ESB
JBoss ESB - Open Source ESB
IBM WebSphere Message Broker
IBM WebSphere Process Server - Contains the same functionality as IBM WebSphere ESB plus additional business processing execution and transformation capabilities.
IBM WebSphere ESB
IBM Data Power can be considered also as en ESB
IONA Artix ESB
Microsoft BizTalk Server
Sonic ESB
CapeClear Enterprise Service Bus
Creative Science Systems BizZyme ESB

[編集] See also
Enterprise Nervous System
Java Business Integration
Service-oriented architecture
Business Process Management
Universal Integration Platform
Enterprise application integration

[編集] Footnotes
An alternative view, particularly for high-performance enterprise service buses, is that "standard" message formats should flow across the bus, not just XML. Generating XML and parsing it can be costly in terms of processing and memory, so high-volume scenarios may not be viable.

[編集] Books
Dave Chappell, Enterprise Service Bus (O’Reilly: June 2004, ISBN 0-596-00675-6)

[編集] External links
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 05, 2006)
JSR-208: Java Business Integration (August 2005)
Enterprise service buses hit the road : Infoworld Test Center (July 22, 2005)
SOA Factory to Enterprise Middleware
Getting Started with WebSphere Enterprise Service Bus V6 Last updated 14 June 2006
IBM Redbook: Implementing an SOA Using an Enterprise Service Bus with WebSphere Application Server V6 (March 2005)
IBM Redbook: Using Business Service Choreography In Conjunction With An Enterprise Service Bus (October 2004)
IBM Redbook: Implementing an SOA Using an Enterprise Service Bus (July 2004)
What Is Enterprise Service Bus? (Tuesday April 11, 2006)
ESB supporting both service-oriented architecture and event-driven architecture over a single technology base.
"Lasting concept or latest buzzword?" (Nicolas Farges, 2003]
ESB Resource Directory
Enterprise Integration Patterns
Understand Enterprise Service Bus scenarios and solutions in Service-Oriented Architecture, Part 1
ESB as Global dataspace (Jack van Hoof, 2006)
"http://en.wikipedia.org/wiki/Enterprise_service_bus" より作成