Meet the Author - Jos Dirksen on ServiceMix 4
This week DZone has released the Getting Started With ServiceMix 4 Refcard. We met the author Jos Dirksen, to find out more about ServiceMix, the features it provides and how it competes with other ESBs.
DZone: Hi Jos, Thank you for joining us in this QA interview. Can you introduce yourself and let us know more about your experience in integration, SOA and ESB realm.
Jos: My name is Jos Dirksen and I work for Atos Origin, which is one of the largest European system integrators. My role there is very versatile, but mostly I act as software architect and team lead for integration projects. I've been doing integration and SOA projects for the last seven years and have worked with many open source and closed source products. The last 4 years the focus has been mostly on the open source solutions in the integration space, such as Mule, ServiceMix, Synapse etc.
I'm currently working on a large integration project which we're doing for a number of Dutch cities. We've created a open source based solution which local governments can use to better communicate with their citizens and improve the processing of permits (e.g. construction permits). Besides that I like to give presentations and write articles on SOA and ESB related issues, and together with a colleague have written a book on open source ESBs.
DZone: ServiceMix 4 is based on OSGI, can you please explain more what this kernel brings on the table and what kind of benefits end users (developers developing systems on top of ServiceMix) receive from OSGI based architecture?
Jos: I think most people will already know the basics which OSGi offers. Simply out, it provides a environment in which you can easily deploy services and manage dependencies within a single Java VM. The fact that ServiceMix is based on OSGi leverages those advantages to the developers and users of ServiceMix. Some of the most important advantages, for me at least, you get from such an architecture are the following:
standards based, easy to understand container One of the first advantages you get from ServiceMix and OSGi is that it's a lot easier to create components for ServiceMix. You just have to create an OSGi bundle which can then be installed in ServiceMix. Combine this with the available maven archetypes and you've got an easy and intuitive way to deploy new and custom functionality to ServiceMix. Besides this the OSGi life-cycle is well defined and easy to understand.
strict classloading separation Classloading has often been an issue for containers, whether we're talking about web containers, application servers or ESBs such as ServiceMix. In the previous version of ServiceMix classloading was handled the JBI way. Even though this provided a good separation creating JBI service units and assemblies was a bit cumbersome. With the OSGi based kernel, we also are forced (which in this case is a good thing) to think about the consequences of the classloading mechanics of OSGi. This means that we have to define which packages to expose, the dependencies we require etc. Even though this will probably take some getting used to, it will make it a lot easier to work with multiple versions of jars and avoid the various ClassNotFound and ClassCastExceptions that sometimes are caused by all the various jar files in the system.
comprehensive remote administration With OSGi we instantly get various ways to look into the system. ServiceMix has got a great ssh based console now, which allows you to see the details of your running system, and provides ways to monitor and manage your running system.
hot deploy of new services and components The classloading mechanisms and loose coupling OSGi provides is also used by ServiceMix for the deployment of new components. Not necessarily something to contribute to OSGi (previous versions also had this), but OSGi provides a good mechanism for this out of the box, which ServiceMix has used to make redeploying components at runtime very easy and flexible. You're not limited to just dropping a file into a directory, you can also use the remote administration console to install or update bundles and components.
DZone: ServiceMix is commercially supported by Fuse Source and we can compare it with other commercially available ESBs, how do you place ServiceMix in the global market of ESBs coming from SUN, TIBCO, IBM, ORACLE and others?
It's always hard to compare an open source ESB with the commercial offerings from IBM, Sun etc. If you look at the basic functionality that ServiceMix is offering it's easily on par with the commercial ESBs. Besides that ServiceMix is much more lightweight and, for me at least, easier to use than many of the commercial offerings. I think that for most integration/ESB scenarios ServiceMix is very valid option.
However where ServiceMix has some steps to make is in offering a complete suite. What I mean here is that ServiceMix for instance doesn't offer tight integration with a BPM engine out of the box, or with an business rule engine, or provide an extensive graphical editors. But since ServiceMix 4 has only been release a couple of months ago, I'm positive that this is an area where you'll see much improvement in the next couple of months. All in all though it's a case of use the best tool for the job. If you look closely at most requirements for an ESB or an integration solution you'll notice that ServiceMix is often a very good and valid choice.
DZone: In some cases ServiceMix benefits from alternatives which can replace each other, like CXF based NMR and Camel based NMR or EIP based routing and Camel based routing, How does it affects developers when they start evaluating ServiceMix, how does it affects the final solutions which are based on ServiceMix capabilities?
Jos: The first time you look at the routing part of ServiceMix it might be a bit overwhelming. You've got a couple of solutions that more or less do the same thing. In general though when you need routing capabilities in your application Camel is usually the best choice. It offers the most extensive support for enterprise integration patterns, and provides a rich java based DSL.
If on the other hand you just need some simple message routing the EIP service engine is also a good choice. It's very easy to route messages with this service engine without having to dive into Camel specifics. So when you're evaluating the various features of ServiceMix the EIP service engine might be a good start to get a simple message flow going. When your integration requirements however become more complex I think Camel in that case will be a better option. When you look at the future, I think we'll slowly see the EIP service engine based solutions disappearing. Camel is more powerful and when you get into it, really easy to use.
DZone: We know that JBI 2 (JSR 312) is an in-progress update for JBI 1 (JSR 208). What are differences between these two versions and how do you anticipate the success rate of JBI 2 in comparison with JBI 1?
Jos: I don't actually think JBI 2 will really make an impact. The spec has been running now for a couple of years but nothing has really been released yet. Information has been sparse, except a view small pieces of information at JavaOne. Personally I really liked the JBI spec, it was well written and provided a great base for integration product developers. It's a too bad the adoption of JBI really never took off. We've had a couple of implementations but the whole JBI components marketspace never really got started and the interoperability between JBI based ESBs (e.g. runnning OpenESB JBI components on ServiceMix) wasn't that great and involved a lot of source code hacking.
With JBI 2.0 the focus was more on a simpler POJO based development model, alignment with SCA and removing the restriction of using XML as the message payload.So while the ideas behind JBI 2.0 are very good, it's really lacking momentum. So personally I don't really think JBI 2.0 will ever be released and that we're slowly moving to more lightweight solutions. It would be great though to have something, perhaps OSGi based, so that components for instance developed for ServiceMix could run just as easily on one of the other ESBs.
So should JBI 2.0 eventually be released I don't think developers have to worry about this, since it's more a specification for the integration product builders, not so much for those using the ESBs.
DZone: Does ServiceMix provide clustering and high availability for service engines like BPEL engine?
Jos: ServiceMix can be used to provide the clustering and HA for service engines. ServiceMix uses activeMQ as its transport which can be configured to run in a clustered/HA mode. If you make sure all the messages sent by the various service engines are sent over the NMR you can easily create a robust clustered HA environment. This however will also require some work on the service engine front. So you won't get clustering and HA out of the box just by running a workflow engine on ServiceMix.
DZone: Monitoring has always been a big concern for developers and administrators, specially for work flow based services like BPEL, what does ServiceMix provides to address the monitoring requirement in general and service engine specific monitoring like BPEL process instance monitoring in particular?
Jos: For monitoring ServiceMix doesn't really provide anything out of the box besides standard log files etc. You can however very easily configure third parties to monitor the ESB. A good example of this is Hyperic. Hyperic can be used to monitor ServiceMix 4. If you look at the Fuse offering you can get Fuse HQ, which is based on hyperic. So for general monitoring of ServiceMix Hyperic should be sufficient.
Engine specific monitoring isn't included in ServiceMix. It's more up to the engine to deliver the hooks for monitoring then it is for ServiceMix. ServiceMix provides the container on which the service engines can run. Apache Ode, the BPEL service engine which can be used with ServiceMix, provides it's own management API which you can use to manage and monitor the processes. However no graphical tools for this are provided out of the box.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)