Are you still working with integration products from one of the typical large integration vendors such as IBM and Tibco and looking for a more lightweight approach? Then these two articles on Mule and Apache ServiceMix can serve as an eye-opener to the potential of Open Source ESBs. If you are already familiar with Mule or Apache ServiceMix, these articles will provide some insight in the new features of the latest versions of these Open Source ESBs and show you how to approach the design of your integration solution.
These two articles will also try to demystify the discussion between a Java Business Integration (JBI) based ESB implementation (Apache ServiceMix) and a custom developed ESB implementation (Mule). In these two articles we will implement an integration solution with both Mule and Apache ServiceMix, to show that both approaches each have their merits and that there is actually quite a bit of overlap between these two approaches.
In the first article, we discussed Mule. In this second article we’ll focus on JBI and ServiceMix, ServiceMix 3.2.1 to be more specific, which is the latest production release of the ServiceMix project.
A short introduction into JBI
To understand the architecture of ServiceMix, we will first need to discuss the JBI specification a little bit. JBI defines a standards-based architecture that can be used as the basis for Java-based integration products, in particular an ESB. Besides ServiceMix there are a couple of other Open Source ESBs that are based upon this standard, like OpenESB and Petals. Of course if you want to know more, the complete specification is available at http://jcp.org/en/jsr/detail?id=208. Even though this is a 240 page document, it’s very well written and readable.
There are a couple of key concepts in the JBI specification. There are two kinds of JBI components, the service engine (SE) and binding component (BC), which provide integration logic. BCs provide communication functionality to send messages to and from the JBI container, like for example a JMS BC, a File BC and a HTTP BC. SEs provide integration functionality that can be used to build your integration solutions, such as routing, transformation and routing logic. The BCs and SEs communicate with each other via a normalized message router (NMR). With the presence of a NMR, the BCs and SEs are decoupled and communication is done with so-called normalized messages. The communication layer between the BCs en SEs and the NMR is implemented with a delivery channel (DC). The DC is a bidirectional communication pipe that provides an API contract for BCs and SEs to be able to sent and receive messages from the NMR. An overview of these foundational concepts of JBI is provided in figure 1.
Figure 1 An overview of the important JBI concepts and their relationship.
The JBI infrastructure shown in figure 1 is exactly what Apache ServiceMix provides for you. ServiceMix provides a JBI container that implements a NMR, normalized message and DC and more important for an integration developer, it provides a lot of BCs and SEs. A couple of these BCs and SEs are shown in figure 2.
Figure 2 An overview of the Apache ServiceMix architecture, showing a number of the binding components and service engines provided out-of-the-box.
Now we have discussed the theory behind JBI and showed an overview of Apache ServiceMix in figure 2, it’s time to actually implement something. But what do we have to implement to get an integration solution running on ServiceMix? Well, we have to create service units (SUs) and a service assembly (SA). For every binding component and service engine that you want to use in your integration solution, you will have to create a service unit. The created service units can be packaged as a service assembly, which can be deployed on a JBI container such as ServiceMix. A SU is just a JAR file with a configuration file for the specific BC or SE. And a SA is also just a JAR file with a JBI deployment descriptor named jbi.xml. But let’s stop talking and implement a simple message flow for ServiceMix.