ServiceMix overview
Background
Apache ServiceMix provides an ESB implementation of the Java Business Integration (JBI) specification. The JBI specification describes a standard-based architecture for an integration platform, facilitating the use of components from different vendors on one integration platform. Apache ServiceMix is a top-level project of the Apache foundation, and foremost provides a JBI container and a set of binding components and service engines. Currently there are two main versions of ServiceMix, the production version 3.2.2, and ServiceMix 4, which currently only has milestones released, but will be the main production implementation in the near future, with support for OSGI.
Architecture
As already said, the architecture of ServiceMix is based on JBI. JBI consists of a few building blocks, which will clarify the terminology also used in ServiceMix. A JBI container consists of service engines (SEs) and binding components (BCs). A service engine provides functionality inside the JBI container, like for example a BPEL or a routing component. A binding component provides functionality to the outside of the JBI container focusing on connectivity. Examples of binding components are JMS, File and HTTP. Another important building block is the normalized message router (NMR). The NMR is a bus inside the JBI container which connects the service engines and binding components. So every communication between a binding component and a service engine is made via the NMR. The next figure shows the JBI architecture.
Service assemblies (SAs) and service units (SUs)
You as an integration developer must implement service assemblies and service units to get an integration solution running on ServiceMix. A service unit is a normal JAR file which consists of a configuration file, for ServiceMix this is a XBean configuration and optionally classes and libaries. A service unit is always configured for one service engine or binding component. So we have separate service units for JMS, File and routing configurations. Therefore we need a service assembly, that consists of all the service units (JAR files) for one integration solution. A service assembly is JAR file consisting of a jbi.xml configuration file and the service unit JARs. An example of a XBean configuration for a JMS binding component is:
Note that every consumer and provider configuration consists of a service and an endpoint attribute. The combination of the service and endpoint value uniquely identifies the consumer or provider in the JBI container. Therefore we can forward the JMS message consumed by the JMS consumer to the JMS provider by using the service and endpoint name of the JMS provider as the value of the targetService and targetEndpoint attribute. Also note that the communication between the JMS consumer and provider is made via the normalized message router. This examples consumes a message from the in.queue queue of an ActiveMQ broker and writes the same message to the out.queue queue. To complete this example let's look at the jbi.xml file of the service assembly.
