ServiceMix 4 into the play

So, what's new in SMX4? This is the first question I asked when I heard that a new major release of ServiceMix is on the horizon. Like most people, I pulled down the latest binaries of SMX4 and started going through the documentation. However, first before jumping into SMX4 lets get a quick picture of what the ServiceMix 3.x (SMX3) technology stack looks like so we can get a point of reference.

In SMX3 the JBI 1.0 container is a runtime environment for a Normalized Message Router (NMR) and JBI components (e.g. Service Engines and Binding Components) leveraging Apache ActiveMQ as the Message Broker. Typically an ESB offers at least message routing (e.g. ServiceMix EIP & Apache Camel), transformation (e.g. XSLT) and connectivity (e.g. File, JMS, HTTP, etc.) as does SMX3. Apache CXF is used to provide SOAP support and xml marshaling. From an operations perspective, SMX3 provides JMX-based management for running components and other internals as well as run standalone or embedded in an application server or web container (e.g. JBoss, Tomcat, etc.). There is a lot more that SMX3 has to offer however for this post that's a good picture. One last note on SMX3, version 3.2 and higher requires Java 5.

In SMX4 the technology stack really hasn't changed much. The key technologies are still there like Apache ActiveMQ, Apache CXF, JMX, etc. Apache Camel is the preferred technology for routing however, ServiceMix EIP appears to still be supported. Ok, so what has changed?

Looking at the architecture, the most noticeable change is the separation of the JBI container into a ServiceMix Kernel and a ServiceMix NMR. The ServiceMix Kernel is a lightweight OSGi-based environment deployed on Apache Felix (an OSGi R4 Services Platform implementation). The kernel and NMR are their own projects in Apache and can be downloaded and built separately. However, not to worry, if you download FUSE 4 preview (certified release of SMX4) from IONA you get the kernel and NMR bundled along with other stuff to run the ESB.

Why the change to OSGi?

James Strachan (ServiceMix co-founder and committer) pointed out to Rod Biresch, that one of JBI's weakest areas is the cumbersome classloader model and that needed to be addressed.

OSGi solves this problem with advanced OSGi bundling and classloading mechanisms. Ok, that sounds good but what is OSGi? Well in a nutshell, it is an environment where bundles (modules) communicate through well-defined services while hiding their internals from other bundles. OSGi also specifies how components are installed and managed. Components can be started, stopped, updated and uninstalled dynamically without bringing down the entire server. This is very beneficial for high availability systems (like an ESB). OSGi bundles are versioned and only bundles that can collaborate are wired together in the same class space. This solves the problem with library dependencies or JAR hell :) There are many more benefits to OSGi and the OSGi Alliance is a great place to start learning. With this change, ServiceMix now becomes an OSGi and JBI-based ESB.

What changed in the NMR?

The obvious change is that the NMR is now it's own Apache project, ServiceMix NMR. So, theoretically you could run different versions of the SeviceMix Kernel and NMR. Unfortunately I don't have a good use case for that although, this separation does provide flexibility. The NMR is now a set of OSGi bundles that can be deployed on any OSGi runtime but mainly built on top of the ServiceMix Kernel. The NMR project is also the JBI 1.0 implementation with plans to support JBI 2.0 in the future. There are a few things missing with ServiceMix NMR 1.0-m1 release (from the release notes):

• no support for JMX deployment and ant tasks
• no support for Service Assemblies Connections
• no support for transactions (a transaction manager and a naming context can be injected into components if they are available as OSGi services, but not transaction processing - suspend / resume - will be performed, as it would be requested for real support)...more on this a little later.

So depending on what you're doing, these missing capabilities may or may not hamper early adoption.

A few other interesting changes to mention. First, SMX4 is now a standalone only runtime. Previous versions supported embedding in application servers, web containers as well as applications. Flows are no longer used for message exchanges. This confused me a little however, thanks to James he clarified things. Flows are NMR flow types that are the mechanism by which the NMR sends messages from one Binding Component or Service Engine to another. SMX3 has 4 flow types that ended up causing confusion and added complexity for developers. This was simplified in SMX4 with a tendency to use explicit routes by exploiting Camel's routing capabilities.

Last change to note, SMX4 no longer performs transaction specific processing. However, it will pass transaction information along as it would any other message. Guillaume Nodet (Apache Project Management Committee Chair and active committer) gave some insight regarding the changes in transaction support and it turns out that the release notes are a little misleading. Guillaume explained that previously the NMR was considered as a transactional resource, which means the sending of a JBI exchange through the NMR could be part of the transaction (depending if it was sent synchronously or not). This is no longer the case with SMX4. Transactions are now conveyed along with the exchanges whether they are sent synchronously or asynchronously. As a result, the NMR does not need to be aware of transactions because they are now controlled by the different components instead. The benefits from this change include:

• Improved scalability of ServiceMix when using transactions because all JBI exchanges are now sent asynchronously.
• Improved interoperability as the other JBI containers tend to follow the same pattern when/if they support transactions.

Hopefully that gives you a pretty good sense of what is new in SMX4.

full window