Open source ESBs

ESB Introduction

In computing, an enterprise service bus (ESB) refers to a software architecture construct. This construct is typically implemented by technologies found in a category of middleware infrastructure products, usually based on recognized standards, which provide foundational services for more complex architectures via an event-driven and standards-based messaging engine (the bus).

Enterprise Service Bus is an evolving architecture technique to integrate incompatible business applications over a common messaging bus. The ESB 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 bus. In order to achieve this objective, the bus must encapsulate the functionality offered by its component applications in a meaningful way. This is typically accomplished 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 it receives a message, it routes it to the appropriate application. Often, owing to the fact that the application was not built with the message model in mind, the ESB will have to transform the message into a legacy format that is understandable by the application.


Role of ESB in SOA world

ESB is one architecture style that abides by the rules of a Service Orientated Architecture.


Figure 1 explains the basic architecture of any ESB binding. All ESBs support a set of protocols for endpoint binding. Messages received at an end point undergo transformation using message transformer provided. Message transformation is done to convert the request to a data structure known by the service to be invoked. It can then be passed to the component service like Java POJO itself, EJB, JDBC, etc. Integration with other container frameworks like Spring or PicoContainer also happened at this logical stage. The response from service invocation is then routed an appropriate outbound endpoint. Response message is transformed appropriately to match a format known by the receiver before it is sent to the receiver endpoint.

Main advantages that the ESB architecture inherits to the SOA world are given below.

•Faster and cheaper accommodation of existing systems. Increased flexibility makes it easier to change as requirements change.
•Predefined ready-for-use service types.
•No central rules engine, no central broker.
•Incremental changes can be applied with zero down-time.


There also are a few overheads that need to be considered before one goes the ESB way.

•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.
•Extra overhead and increased latency caused by messages traversing the extra ESB layer, especially as compared to point to point communications.
•All benefits and cost advantages of ESB come into play only when you have a SOA based system in consideration.

Component integration standards

There is no de-facto standard for SOA service/ component integration as of today. ESB is only a mechanism to make this integration easier by making communication between components independent of the service.

There are two emerging standards in component integration which look very good in what they promise and there are ESB tools that support either of these standards.

There also are tools that just do what ESBs are supposed to do without going by a particular standard. E.g.: Mule

Reason for mentioning these standards in this document is that one of the criterions in selecting an ESB could be selecting, if need be, the standard itself that one want to pick for component integration.


a.JBI

Java Business Integration (JSR208) is an emerging standard that defines common interfaces for components and message exchanges for application integration. It is a JAVA community process initiative.

JBI is built on a Web Services model, and provides a pluggable architecture for a container that hosts service producer and consumer components. Services connect to the container via binding components (BC) or can be hosted inside the container as part of a service engine (SE). The services model used is Web Services Description Language 2.0.

The central message delivery mechanism, the normalized message router (NMR), delivers normalized messages via Message Exchange Patterns (MEPs).

b.SCA

Service component architecture, as a standard for assembling services together, stands one step ahead of JBI in the fact that it supports multiple technologies and languages whereas JBI is limited to Java components. This means, SCA services can be implemented in languages and technologies more than just Java [For e.g.: An implementation of SCA supports invocation of services implemented in EJBs, Java POJOs, BPEL process, COBOL, C++, PHP, Ruby etc.]. SCA standard is promoted by vendors like IBM, Oracle, TIBCO, BEA and supported by OASIS committee.

Service Component Architecture defines a simple, service-based model for construction, assembly and deployment of network of services (existing and new ones) that is language-neutral. Main artifacts in an SCA style design are

Service Data Object (SDO) provides a uniform interface for handling different forms of data, including XML documents that can exist in a network of services and provides the mechanism for tracking changes.

Data Access Service (DAS) provides a simple SDO interface to relational databases.

Even though SCA looks more promising and futuristic in terms of acting as a framework for SOA, it is too early to write a verdict on the success of this technology as it is in its incubator stages.


The messaging infrastructure would help ease application integration

a.Via loose coupling of components, including legacy assets, communicating over disparate transport protocols
b.With minimal re-programming effort for message transformations

The supporting tools should enable

a.Quick development and configuration of messaging channels though established frameworks and patterns
b.Administration of the messaging infrastructure elements by operational staff

Please note that #1 above implies assurance of inter-operability of components residing on diverse technology stack like .net, j2ee, AS400, mainframes over a messing infrastructure only.

Transaction and security support is also desired from the ESB framework.

ESB Options

Some of the best and popular open source ESBs are

��. Mule
��. Mirth
��. Apache ServiceMix
��. OpenESB
��. FuseESB
��. Apache Tuscany
��. Fabric3



Recommendations

Mule stands as an excellent choice if alignment with a particular component integration standard is not desired. The fact that it supports POJO message objects is very much suited for normal development models.

In the availability or plan to have the availability of standard messaging models with WSDL, a JBI container based routing is the best option to go for. An alternate option to this is to additionally develop marshallers at endpoints so that JBI containers still get to work with normalized XML messaging model.

The decision for JBI over SCA can be well supported by the fact that there already are a number of JBI components that stand good and ready to use for most of the domains. Having said this, the future of SCA in the commercial arena doesn’t look dim at all provided the fact that it is supported by many of the industry giants like BEA, IBM, Oracle, and TIBCO and supported by OASIS.

SCA, as already mentioned in the previous sections is too early for serious adoption unless decided to go for a commercial framework like the one from TIBCO.

This evaluation was only limited to open source candidates in the industry. Provided commercial tools are an option, frameworks like Fiorano or Sonic MQ could prove a better solution to our requirement in terms of performance and support.

Glossary

��. ESB – Enterprise Service Bus
��. JBI - Java Business Integration. A standard for component integration for application development.
��. SOA – Service Oriented Architecture
��. SCA – Service Component Architecture. A standard for component integration for application development.
��. JSR208 – This is the Java Community Process specification for JBI standard.
��. BPEL – Business Process Execution Language. A language for Business Process Modeling.
��. IONA – A software firm focused on distributed middleware solutions for IT.
��. JMX – Java Management Extension.


References

1. Enterprise Service Bus
http://en.wikipedia.org/wiki/Enterprise_service_bus

2. Java Business Integration
http://en.wikipedia.org/wiki/Java_Business_Integration
http://www.jcp.org/en/jsr/detail?id=208
http://wiki.open-esb.java.net/Wiki.jsp?page=Jbicomps

3. Service Component Architecture
http://www.osoa.org/pages/viewpage.action?pageId=46
http://dev2dev.bea.com/pub/a/2005/11/sca.html
http://www.davidchappell.com/articles/Introducing_SCA.pdf

4. Mule
http://mule.mulesource.org/display/MULE/Home
http://mule.mulesource.org/display/MULE/Transports+Guide

5. ServiceMix
http://servicemix.apache.org/home.html
http://servicemix.apache.org/components-list.html

6. OpenESB
https://open-esb.dev.java.net/

7. Fabric3
http://fabric3.codehaus.org/

8. Tuscany
http://incubator.apache.org/tuscany/home.html

9. Open source licenses
http://opensource.org/licenses/alphabetical