Gourt Home::Gourt :: Enterprise service bus
In computing, an enterprise service bus refers to a software architecture construct, implemented by technologies found in a category of middleware infrastructure products usually based on Web services standards, that provides foundational services for more complex service-oriented architectures via an event-driven and XML-based messaging engine (the bus). An enterprise service bus generally provides an abstraction layer on top of an Enterprise Messaging System which allows integration architects to exploit the value of messaging without writing code. Contrary to the more classical 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.
Salient characteristics
Although the exact definition of an ESB varies, most agree that the following are characteristics of an ESB:
- it is an implementation of Service Oriented Architecture
- it is usually operating system and programming language agnostic; it should work between Java and .Net applications, for example
- 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 & choreography
- it includes intelligent, content-based routing services (itenerary routing)
- it includes a standardized security model to authorize, authenticate, and audit use of the ESB
- it includes transformation services (often via XSLT) between the format of the sending application and the receiving application, to facilitate the transformation of data formats and values
- it includes validation against schemas for sending and receiving messages
- it can uniformly apply business rules, enrichment of the message from other sources, splitting and combining of multiple messages, and the handling of exceptions
- it can conditionally route or transform messages based on a non-centralized policy - meaning that no central rules engine needs to be present
- it is monitored for various SLA (Service-Level Agreement) thresholds message latency and other characteristics described in a Service Level Agreement
- 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
Key disadvantages
- Enterprise Message Model is usually mandatory
- Value of the ESB requires many disparate systems to collaborate on Message Standards
- Versioning of messages between systems, if not planned for, can cause tight coupling instead of the intended loose coupling
- Requires more hardware to run (A broad statement: depends on what vendor you are talking about)
- New skillset to learn to configure ESB
- Extra translation layer when compared to regular messaging solutions (Think about translating to Latin to get from English to Russian, just because you can)
- Rarely realizes ROI (Return On Investment) on first few projects to implement ESB. Next few projects generally refine messages and generalizes services better. The fifth project may begin to realize ROI. (These are hardly objective facts. Please supply a study backing this up)
- Requires mature IT governance model (such as ITIL) and a well defined enterprise strategy already in place to implement an ESB effectively.
See also
- Enterprise nervous system
- Digital Nervous System
- Java Business Integration
- Service Oriented Architecture
- Business Process Management
- Universal integration platform
- Enterprise application integration
References
- 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, and high volume scenarios may not be viable.
External links
- JSR-208: Java Business Integration (August 2005)
- Enterprise service buses hit the road : Infoworld Test Center (July 22, 2005)
- 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)
Enterprise application integration | Message Oriented Middleware
"Enterprise service bus"