Background
The Enterprise Service Bus (ESB)- which can be defined as middleware that brings together both integration technologies and runtime services to make business services widely available for reuse - offers the best solution for meeting today's enterprise application integration challenges by providing a software infrastructure that enables SOA. However, there are currently a number of different vendors that provide ESB solutions, some of which focus purely on SOAP/HTTP and others who provide multi-protocol capabilities. Because these vendors span the horizon from big enterprise generalists (app servers), to mid-tier enterprise integration providers, all the way to smaller, ESB/integration specific-providers; there doesn't seem to be an established consensus regarding the key requirements for an ESB.
As application architects, we have often thought about what requirements would define an ESB designed specifically to cater to the needs of an agile, enterprise integration model. In building for these specific requirements, we realized that we actually needed to develop a new type of ESB, hence the ServiceMix project.
Characteristics of an Agile ESB
The main criteria we were looking for in our ESB are as follows:
Standards based
While standards-based support is marketed by many ESB vendors, the support is provided externally, requiring developers to work with proprietary APIs when directly interacting with internal APIs. ServiceMix was designed with the requirement to eliminate product API lock-in, by being built from the ground up to support the Java Business Integration specification (JSR 208). Our agile ESB needs to use JBI as a first class citizen, but also support POJO deployment for ease of use and testing.
Flexible
Another characteristic of an agile ESB is the flexibility with which it can be deployed within enterprise application integration framework: standalone, embedded in an application component, or as part of the services supported by an application server. This allows for component re-use throughout the enterprise. For example, the binding for a real-time data feed might be aggregated as a web-service running within an application server, or streamed directly into a fat client on a traders desk. An agile ESB should be able to run both types of configurations seamlessly.
To provide rapid prototyping, an agile ESB should support both scripting languages and embedded rule engines, allowing business processes to be modeled and deployed quickly.
Reliable
Our ESB needs to handle network outages and system failures and to be able to reroute message flows and requests to circumvent failures.
Breadth of Connectivity
An agile ESB must support both two way reliable Web-services and Message Oriented-Middleware and needs to co-operate seamlessly with EIS and custom components, such as batch files.
Conclusion
We also wanted our agile ESB to be vendor independent and open source, to promote user control of source code and direction. An added benefit of this is not only the zero purchase cost, but the total cost of ownership will be reduced where users are actively contributing and maintaining our ESB.
We rapidly came to the conclusion, that as there was no single product that would adequately meet our needs, we would have to just go a head and build one!
