Appendix A. ServiceMix 4.0
The examples in this book are based on ServiceMix version 3.2.1, which is the latest production release at the time of writing. But a milestone of the next version of ServiceMix is already available: version 4.0. This version of ServiceMix is based on a new architecture and therefore has many changes compared to version 3.x. We chose to use ServiceMix 3.2.1 in this book because ServiceMix 4 wasn’t yet available. With ServiceMix 4.0, it will only become easier for integration developers to use ServiceMix in your integration projects.
Let’s look at the new architecture of ServiceMix 4.0 in the first section. After that, we show you an example of how you can use ServiceMix 4.
The new architecture of ServiceMix 4
The new ServiceMix architecture tries to simplify the classloading mechanism, the development of (JBI) components, and packaging of your developed integration logic. The foundation of ServiceMix 4 is an OSGi container, which takes care of classloading and deployment of new or changed components. OSGi also provides a packaging structure that ServiceMix can use.
Before we dive into the details of OSGi in the next section, let’s look at the revised architecture, shown in figure A.1, as described on the ServiceMix 4 website (http://servicemix.apache.org).
Figure A.1. The new architecture of ServiceMix 4. The architecture is described from three viewpoints: the developer view, the technology view, and the kernel view.
Figure A.1 shows the ServiceMix 4 architecture from three different viewpoints. The technology view has probably changed the least since version 3.x, because JBI 1.0 is still supported and JMS, JAX-WS, and Spring are important implementation technologies for ServiceMix. But the direct support for EJB3 components is new, and potential support for SCA looks promising.
The developer view has changed quite a bit: The figure doesn’t include service units and service assemblies, but only shows Camel routes, Spring XML configurations, and annotated POJOs. ServiceMix 4 provides the functionality to deploy a Spring XML configuration file or a Camel route configuration without any packaging required—you just copy the file to the ServiceMix container. But for more robust and enterprise-class deployments, ServiceMix 4 uses OSGi packages as its deployment model in addition to the (legacy) support for JBI 1.0 packaging with service assemblies.
The part that has changed the most is the kernel view. Let’s look at this in some more detail.
A new project structure with Servicemix 4
Whereas ServiceMix 3.x consists of only one project and distribution, ServiceMix 4 consists of at least three projects:
- The kernel is an OSGi-based runtime that provides a lightweight container that enables the deployment of various bundles. The ServiceMix kernel provides functionality like hot deployment, dynamic configuration of property files, logging, and a security framework based on JAAS.
- ServiceMix NMR implements the Normalized Message Router based on Apache ActiveMQ and also provides the JBI 1.0 implementation. The ServiceMix NMR project provides a set of OSGi bundles that can be deployed on the ServiceMix kernel. At the time of writing, you can deploy JBI components of ServiceMix 3 on the ServiceMix NMR, but the NMR doesn’t yet fully implement the JBI specification. For example, using JMX for deployment and Ant tasks are missing.
- The ServiceMix features project provides a number of additional OSGi bundles, which can be deployed on the ServiceMix kernel. This project provides a distribution that includes the ServiceMix kernel and NMR. In this appendix, we use a milestone 2 SNAPSHOT version of the ServiceMix features project.
In addition to these three projects, the ServiceMix development team is preparing a restructuring of the entire ServiceMix project (including version 3.x). There are plans for each JBI component to be placed in a separate distribution, to allow a different release plan for every JBI component and, more important, to enable easy sharing of JBI components between ServiceMix 3 and 4.
The kernel is an essential part of ServiceMix 4: It provides important functionality like hot deployment and enables logging and security capabilities. As we’ve said, the foundation of the ServiceMix kernel is an OSGi container: Apache Felix. In the next section, we look at OSGi in more detail to help you understand this choice for the new architecture of ServiceMix 4.
A little background in OSGi
You may already have heard about the OSGi (an acronym of Open Services Gateway initiative) specification. OSGi is hot, and almost every self-respecting open source project is thinking about OSGi enablement, including ServiceMix. The article “OSGi for Beginners” by Joseph Ottinger, on theServerSide (http://www.theserverside.com/tt/articles/article.tss?l=OSGiforBeginners), gives a good, short explanation of OSGi:
OSGi is a framework for Java in which units of resources called bundles can be installed. Bundles can export services or run processes, and have their dependencies managed, such that a bundle can be expected to have its requirements managed by the container. Each bundle can also have its own internal classpath, so that it can serve as an independent unit, should that be desirable. All of this is standardized such that any valid OSGi bundle can theoretically be installed in any valid OSGi container.
In essence, OSGi is a module system for Java. Modules are important as a solution to versioning and JAR dependencies. The OSGi specification describes a module system that can be used in a Java environment regardless of JEE version. In OSGi terminology, a module is called a bundle. A bundle is nothing more than a JAR with some extra meta information.
Let’s implement a small OSGi bundle so you can see what we’re talking about. A bundle typically implements a bundle activator interface named BundleActivator, which provides a hook into the lifecycle of an OSGi bundle. An overview of the OSGi bundle lifecycle is shown in figure A.2.
Figure A.2. The lifecycle of an OSGi bundle. The first state of an OSGi bundle is always installed, and from that state an OSGi bundle can eventually be started.
The OSGi bundle lifecycle is pretty much self-explanatory. When a new OSGi bundle is deployed to an OSGi container, its first state is always installed. Then, all dependencies of the OSGi bundle are resolved by the OSGi container, and the bundle can be started. If necessary, an OSGi bundle can be stopped and uninstalled from the OSGi container.
Let’s look at an example of a BundleActivator implementation class, which is invoked when the bundle is stopped and started:
public class SimpleActivator implements BundleActivator {
public void start(BundleContext bc) {
// do your bundle's startup logic
}
public void stop(BundleContext bc) {
// shutdown your bundle
}
}
As you can see, a BundleActivator interface isn’t difficult to implement. The OSGi container calls the start method of the BundleActivator when all the dependencies have been resolved. It’s now up to the bundle implementer to correctly start its service.
The BundleActivator also specifies a stop method. This method is called when you stop this bundle or want to uninstall the bundle. It’s your job as bundle implementer to clean up the resources your bundle is using and make sure it shuts down neatly.
Getting started with ServiceMix 4
Now that you have a little background about ServiceMix 4 architecture and the OSGi specification, let’s implement an example that shows some ServiceMix 4 functionality. The first step is to download ServiceMix 4.0 (we used a ServiceMix 4.0 M2 SNAPSHOT). You can also download the ServiceMix kernel and NMR separately, but for this example we use the ServiceMix 4.0 distribution, which includes both subprojects.
When you’ve extracted the distribution, start the ServiceMix container with the following script executed from the root directory:
binservicemix.bat (Windows) bin/servicemix.sh (Unix/Linux)
When the ServiceMix 4 container starts, you see the following output in your console:
ServiceMix (1.0-m3) Type 'help' for more information. ------------------------------------------------ username@computer:/>
From this console, you can interact with the ServiceMix 4 container. The help command shows you the available commands. To show all the OSGi bundles installed in the ServiceMix container, you can use the command osgi list. By default, 81 OSGi bundles are installed and in the active state in the ServiceMix 4 container, including Spring and ServiceMix JBI bundles.
The JBI components that we describe and use in this book’s examples, such as the JMS binding component and the file binding component, can also be deployed on the ServiceMix 4 container. Depending on the version you’ve downloaded, you may already have the JBI components installed and active. If you don’t see the JMS and JBI components, execute the following OSGi commands to install them:
osgi install -s jbi:mvn:org.apache.servicemix/servicemix-shared-compat/ 3.2.1/zip/installer osgi install -s jbi:mvn:org.apache.servicemix/servicemix-jms/ 3.2.1/zip/installer osgi install -s jbi:mvn:org.apache.servicemix/servicemix-file/ 3.2.1/zip/installer
The jbi list command lists all installed JBI components in the command console. With these JBI components installed, you can deploy any service assembly using the JMS and file binding components, as in the file or JMS queue example from chapter 6. You copy the service assembly file to the deploy directory of the ServiceMix distribution, and the integration logic is automatically deployed and started.
In addition to using service assemblies to deploy integration logic on the ServiceMix 4 container, you can also deploy an OSGi bundle. You can find OSGi bundle examples in the ServiceMix user guide (http://servicemix.apache.org/SMX4/users-guide.html).