While preparing guidelines for the usage of the Oracle Service Bus (OSB) I was looking for a definition of a Service Bus. There wasn’t one on my blog yet (more posts on integration) so i decided to use the following and share them with you.
Forrester Service Bus definition
From 2009 Forrester has used this one:
An intermediary that provides core functions to makes a set of reusable services widely available, plus extended functions that simplify the use of the ESB in a real-world IT environment.
Erl Service Bus definition
Thomas Erl offers the following description of a Service Bus::
An enterprise service bus represents an environment designed to foster sophisticated interconnectivity between services. It establishes an intermediate layer of processing that can help overcome common problems associated with reliability, scalability, and communications disparity.
An Enterprise Service Bus is seen by Erl et al as a pattern. That is why it is even more important to share what that patterns is. Later on I’ll also shortly describe the VETRO pattern. Also a very useful pattern to use when comparing integration tools or developing guide lines.
Erl Enterprise Service Bus pattern
On the SOA patterns site we learn that an enterprise service bus represents an environment designed to foster sophisticated interconnectivity between services. The Enterprise Service Bus pattern is a composite pattern based on:
- Asynchronous Queuing basically an intermediary buffer, allowing service and consumers to process messages independently by remaining temporally decoupled.
- Service Broker composed of the following patterns
- – Data Model transformation to convert data between disparate schema structures.
- – Data Format transformation to dynamically translate one data format into another.
- – Protocol bridging to enable communication between different communication protocols by dynamically converting one protocol to another at runtime.
- Intermediate routing meaning message paths can be dynamically determined through the use of intermediary routing logic.
- With optional the following patterns: Reliable Messaging, Policy Centralization, Rules Centralization, and Event-Driven Messaging. Also have a look at slide 12 etc of the SOA Symposium Service Bus presentation.
VETRO pattern for Service Bus
The VETRO pattern was introduced by David Chappell, writer of the 2004 book Enterprise Service Bus.
- V – Validate: Validation of messages eg based on XSD or schematron.
- E – Enrich: Adding data from applications the message doesn’t originate from.
- T – Transform: Transform the data model, data format or the protocol used to send the message.
- R – Routing: Determine at runtime where to send the message to.
- E – Execute: You can see this as calling the implementation.
We also used this pattern to compare Oracle integration tools and infrastructure. It can be very well used while choosing the appropriate tools for a job and deciding on guidelines on how to use these tools.