In the last month I played a lot with ServiceMix4, I’m completely biased here, but I have to say I really like it. The name can be a little bit misleading, in fact, ServiceMix4 is not just a new version of the very popular JBI container ServiceMix3, it’s a sort of universal container based on OSGi. I think that it’s really important to understand this because SMX4 allows endless possibilities in terms of development  capabilities.

What makes really unique SMX4 is its OSGi soul. It is based on the OSGi framework from the Apache foundation, Felix. The dependency on a particular OSGi implementation is pretty loose, SMX4 could be easily layered on top of another OSGi implementation like Equinox.

SMX4 adds to the standard capabilities provided by the OSGi framework very nice features for monitoring, managing the container and very smart capabilities for application deployment. Then it provides different technical platform supports like a JBI container, a Web container and a sophisticated Spring container that can be used for deploying any Spring based applications. The Spring container can be used also for deploying CXF based webservices and Camel routes, very powerful indeed.

SMX4 is able to convert any supported deployable artifacts into an OSGi bundle, if it needs to. In this way those artifacts can be also managed as bundles inheriting all the dependency management capabilities provided by OSGi, as an example we could deploy multiple versions of the same servlet or of the same Camel route without conflicting each other.

I don’t want to enumerate all the features of SMX4 in this blog entry, you could find additional information on the Apache site and the open source Progress site for the supported version.

What it started to intrigue me is the effectiveness of SMX4 for developing component based applications. As I said multiple times, I’m strongly convinced that using the component abstraction for developing an application is a very good software engineering practice, the literature is plenty of evidence that component based development (CBD) is full of benefits.

SMX4 is an impressive enabling platform for CBD. OSGi provides a basic component model were a bundle can play the role of providing packages (set of classes) to other bundles and/or providing services. A bundle can be used only as a library where it’s explicitly defined what classes it’s exporting and/or as a component exposing one or more interfaces.

Looking at the OSGi specs I found that the architectural metaphor is very close to the SOA model. A bundle plays the role of a service provider registering its services in the registry and another bundle can play the role of service consumer looking up in the registry the desired services and then using them. Moreover, SMX4 combines OSGi and Maven, in fact it’s possible to deploy a bundle directly from  Maven repository. This feature allows managing in a coherent way the runtime dependencies and the development dependencies, I found this a very compelling features.

SMX4 can be used, then, as a container for developing service oriented applications where the bundle represents the implementation of one or more services.

Putting together all these features with the Spring support it’s possible to develop service oriented applications where it’s also possible to use WSDL as an interface definition language for formally describing the service interfaces. Just changing the configuration, a service described using a WSDL based contract can be accessed locally without any overhead or accessed remotely through all the supported CXF protocols like SOAP/HTTP, SOAP/JMS or even CORBA.

So, from a software engineering perspective an application can be described in terms of components/services exposing well defined interfaces described using WSDL interacting each other. Just changing the configuration then it’s possible to decide if a service should be also remotely callable.

In the picture above we could also introduce ActiveMQ, we could run a message broker embedded in the SMX4 container, in this way the components can exchange messages each other. Using the vm connector the components can exchange messages without passing through the network stack avoiding an useless overhead when the components reside on the same JVM. Even in this case only modifying the configuration the components can exchange messages across container instances or just locally preserving the same messaging abstraction.

We could go even further, we could use Camel for quickly assembling/orchestrating services into more complex services. Even in this case the location transparency is guaranteed by the fact that the remote/local location is configuration based.

Summarizing, I’m strongly convinced that SMX4, besides being a nice JBI container is much more. With a beautiful blend of OSGi, Maven, Spring, Camel, ActiveMQ and CXF, SMX4 allows finally to implement proven software engineering practices like CBD and proven architectural paradigm like SOA and SEDA in a very elegant and effective way.