I spent some time recently getting myself oriented with the open source offerings in the Enterprise Service Bus area.  My intent was specifically to focus on the recently released Version 4 of ServiceMix.  However, the latest release is only a milestone release and is incomplete in many respects.  Nonetheless, I attempted to identify and evaluate the value of this release, at least as it is intended by the authors.  This necessarily involved reviewing release 3 and making some assumptions about their inclusion in release 4.

Overview

ServiceMix is intended to be a robust, enterprise service bus which offers tools and frameworks to allow diverse enterprise systems to be integrated to solve business problems or take advantage of business opportunities.  Its value comes in providing an easier way to integrate systems of different architectures, languages, and protocols in a consistent, repeatable, and manageable way.  While there are different architectures to accomplish this, the ServiceMix product, and many other ESB products, use a message-driven approach to allow loose coupling between provider applications and consumer applications.  An application should be able to make a request for information to the ESB in the form of a message, delivered in whatever format and whatever protocol suits the requester, and the ESB should be able to deliver the request to the responding application, in whatever format and whatever protocol suits the responder.  My research in the EI space established that a well-equipped ESB should provide the following:

• Location Transparency – applications to be integrated may reside on different platforms in separate locations without the need for the applications to know each others location

• Transport Protocol Conversion – applications to be integrated may not share a common native transport protocol ( or any protocol at all)

• Message Transformation – integrated applications may utilize different formats for common information

• Message Routing – consumer applications should be agnostic regarding the location or identity of the providing application.

• Message Enhancement – in order to service a request, providing applications may need information not available to the requesting application

• Message Security – messages need to be protected from exposure or tampering during transport and standard authentication and authorization needs to be assured

• Management and Control – granular deployment, version control, and run-time visibility and control over the integration environment is a necessity

In addition to providing the above, ServiceMix is also integrated with Apache ODE, a BPEL-compliant process engine, which would allow a consumer request to the ESB to invoke a process flow which could involve one or more of the integrated services defined in the ESB.  In this scenario, the process flow would be defined in BPEL and executed by ODE, and ServiceMix would provide the seamless access to the various services necessary to satisfy the flow logic. 

Observations

Previous versions of ServiceMix were based on the Java Business Integration standard (JSR-208).  This standard provides for a JBI container which manages Service Engines and Binding Components, entities which expose business functions as services (the Service Engine) and connects them to the world outside the container (the Binding Components).  Within the container, SE's and BC's communicate via a Normalized Message Router.  However, ServiceMix 4 is based on a new kernel from the Apache Felix project.  This kernel is an implementation of an OSGi container.  While both approaches provide for the deployment, integration, and management of discrete services, their underlying workings are fundamentally different.  The ServiceMix 4 distribution includes a JBI container for backwards compatibility with the older ServiceMix 3 implementations so that existing versions can be deployed under version 4.  Any new ESB development should probably be done under the OSGi framework.  However, there is relatively little documentation yet available as to how to take advantage of the OSGi capabilities in the newest release, aside from a few basic examples.  In working through the examples, it is easy to see the utility and value of an ESB in general and ServiceMix in particular. 

ServiceMix follows a “don't re-invent the wheel” philosophy.  As such, it relies on existing open source projects for much of its capability.  Messaging support is provided by Apache ActiveMQ, message routing by Apache Camel, web service support through Apache CXF, message translation through XSLT and Xpath, monitoring and control through MBeans exposed through JMX, and of course hot deployment and management through an OSGi kernel, Apache's Karaf OSGi runtime from the Felix project.  This keeps the actual ServiceMix ESB code thin and leverages the work of a whole host of open source developers to make for robust capabilities, but an ESB implementation of any size would require a learning curve in a number of these open source technologies.

Using ServiceMix is as easy as downloading the binary distribution and then starting the container through a command line script.  Services are deployed to the container by installing features, which consist of one more OSGi bundles.  An OSGi bundle is essentially a jar file with a special manifest containing information on the jar's dependencies and some other OSGi parameters.  Maven is the build tool of choice, and creation of bundles is simplified through use of a maven plug-in which creates the manifests for you.  There are also Maven archetypes for creating the project files for the common types of ServiceMix projects, e.g. a Camel message route or a CXF web service.   The Maven “install” command then creates the bundle file.  Related bundles would then be grouped into features by including a simple XML configuration file, so that bundles could be installed, started, stopped, and removed as a group by referencing the feature name in an OSGi command.

The Eclipse IDE is based on the Equinox OSGi-compliant runtime.  An Eclipse plug-in is essentially an OSGi bundle.  Eclipse provides a native capability to create OSGi bundles and run them within Eclipse.  This capability would be handy for quick prototypes or testing.

ServiceMix 3 supported distributed processing and clustering through the deployment of multiple JBI containers.  A high-availability implementation was available by deploying two containers in a master/slave configuration whereby the slave was deployed but inactive until failure of the master, whereupon it would take control and continue processing.  A JBI clustering component was also available to support multiple containers in a clustered implementation which allowed different services to be deployed to different containers to accomplish distribution of work and load balancing.  Each container was able to “discover” the services deployed on the others.  In Service Mix 4, these services are  available, but they are still dependent on the JBI container, so clustering support is up-in-the-air for services deployed as OSGi bundles.  This capability is being worked on, but is not yet available in the current milestone release.

Installing ServiceMix4 and getting the examples to work was a relatively straight-forward task.  However, understanding all the configuration and relationships between the moving parts was tougher.  I found myself having to continually go to the other open source projects (Camel, CXF, etc) to gain any understanding of what was going on behind the scenes.  Because of this and also because of the incomplete nature of the ServiceMix 4 documentation at this time, the learning curve associated with using this product in a large ESB implementation would be great.  That said, any significant ESB implementation is likely going to be a complicated endeavor, so a longer learning curve up front would not necessarily be a show-stopper if the gains to be realized down the line were significant enough. 

What's Next?

For existing ServiceMix users who have already invested in building JBI components, the current milestone release might provide some benefits.  But if I were starting a large ESB implementation and wanted to use ServiceMix 4, I would want to take advantage of the OSGi capabilities and avoid having to develop/support both OSGi and JBI components.  Unfortunately, I don't think the OSGi stuff is fully developed yet in version 4 (clustering and distribution), and the documentation certainly isn't there yet.  So, I wouldn't feel comfortable staring a new integration effort with release 4.  I'd prefer to wait and see what the next full release offers.   I certainly think there is great promise in progress to date.