Enterprise Service Bus - per wikipedia

ESB architectureUse of the word “bus” stems from the physical bus that carries bits between devices in a computer. The ESB 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 of reducing 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 softwareIn 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 ESB. To achieve this objective, the ESB 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 format that the application can interpret. A software “adapter” fulfills the task of effecting these transformations (analogously to a physical adapter). Commentators[who?] disagree whether or not these adapters should be considered part of the ESB.

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.


Key benefitsFaster 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 disadvantagesUsually 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).
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.[4]
[edit] See alsoEnterprise Integration Patterns
Java Business Integration
Business Process Management
Universal Integration Platform
Enterprise application integration
Business Service Provider
Message Oriented Middleware
Complex Event Processing
Event Stream Processing
Event-driven programming
Comparison of Business Integration Software
Comparison of BPEL engines
event-driven SOA
[edit] Commercial ProductsIBM WebSphere ESB
JBoss Enterprise SOA Platform
Microsoft BizTalk Server
Progress Fuse ESB
Progress Sonic ESB
Oracle Enterprise Service Bus
TIBCO ActiveMatrix
JBoss Enterprise SOA Platform
[edit] BooksDavid Chappell, "Enterprise Service Bus" (O’Reilly: June 2004, ISBN 0-596-00675-6)