Today's enterprise applications are distributed by design. For applications to interact with one another over networks optimally, they require Service Oriented and Event Driven Architectures made up of loosely federated business resources, that interact by exchanging requests (for data delivery and integration, as well as for services) and that can handle streams of diverse business processes in real-time. To support large-scale, enterprise integration, organizations need to adopt strategies that rationalize the infrastructure for integration based on the requirements of business/IT organization itself. The only successful integration efforts are those that provide agile, pervasive and low cost solutions in order to cater to today's diverse deployment environments, while fully leveraging available standards.

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.

  Some have argued that integration functionality is best place at the edges of the network. Others prefer a logical ESB server to be separate from the edges - to keep the edges simple and lightweight. Both approaches have their strengths and weaknesses - so we wanted an ESB that is simple and lightweight to deploy into any JVM or into a web server or a full Java EE server - reusing all the available facilities in which it is deployed.

• 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.

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'd have just go a head and build one!

What Is JBI?
There has been a fair amount of buzz about JBI and there is some confusion over what JBI (JSR 208) is.

JBI is a simple API to a Normalized Message Service and Router along with a component and management model for deploying integration services such as routing engines, BPEL engines, rule systems, transformation engines etc.

JBI provides a logical XML messaging network which maps well to web services, HTTP, email and JMS/MOM while easily adapting to legacy systems, binary transports and RPC systems like EJB and CORBA. Think of it as the next logical abstraction above JMS, with support for different message exchanges (one way, request response etc).

The binding components deal with all the plumbing and protocol stuff, then service engine components work on a logical XML layer, providing content based routing, orchestration, rules, transformations and custom enrichment etc.

So BPEL engines no longer need to deal with all of the possible protocols, transports and wire formats; they can just delegate to JBI for the physical routing to service endpoints. Similarly content based routers, rules engines, transformation engines can sit on the JBI bus and do their thing. JBI is looking like being a great API for integration component developers.

Many application developers will still end up writing POJO services and dropping them into their container and exposing them as web services - so often they won't need to use the JBI APIs directly; but for integration vendors and open source integration projects, JBI provides a way for us to all work together at the ESB level and to reuse integration containers, components and tooling.

ServiceMix
ServiceMix is an open source (Apache licensed) Enterprise Service Bus which is compliant with the Java Business Specification (JBI), JSR 208.

ServiceMix already provides JBI support for Apache Geronimo, the first application server to provide this feature.