It allows for provisioning of services on the fly. So you're able to not only bring up instances of ESB containers and plugging that into service-oriented architecture; but you're also able to provision the actual services and bring them up or down and be able to federate your services so you can earmark certain instances inside the cloud to only execute certain kinds of services. What are the biggest challenges with getting an ESB to work with the cloud?
The challenges are the ability to hot deploy without having to restart – to both deploy and un-deploy. To be able to turn instances on and off and have them instantly be able to communicate as one big solid bus. What's so special about ServiceMix4? What does it do?
One of the things that ServiceMix4 does is the ability to have OSGi bundles that makes it so there's no real impact on the class loaders. It makes it so as you deploy and un-deploy it makes it so the need to restart your instances is diminished. Service Mix was basically a [right] of the Java Business Integration (JBI) for Java and open source implementation. It's an apache-based product. It was mainly focused on JBI implementation but as time went on, folks kind of understood that there's some acceptance and adoption of JBI and some not. Some like to send messages without having the overhead of JBI implementations. So ServiceMix 4 came out with the lessons learned from ServiceMix3, which was the
Because Java was originally put together to have JAR files that are deployed and un-deployed. The idea was to make these web applications hot deployable and un-deployable without impact on Java EE. The problem ended up being that we noticed that it wasn't really clean, that class loaders effected memory. There was this big push to modularize dependencies between different modules, give them lifecycles for when they stop, when they start – and mace it so it truly is a secure way to deploy a component or an application that will not affect the container, and would not have memory and class loading impacts. And it was also a way to implement dependency management between the different modules. So how mature is OSGi right now?
I think its adoption at this stage is becoming quite the standards. Eclipse is nearly completely based on that from a plug-in perspective. More and more containers are utilizing it. We've got the new Glassfish coming up that's going to have OSGi, Geronimo3 looks like it's going to be OSGi based. You've also got the Spring OSGi containers. It's really becoming a standard across the board for being able to hot deploy and un-deploy applications within some form of container whether it be an IDE or a Java EE server. I think that it's certainly on its way. It's certainly matured from where it's been. It certainly has a ways to go. It would be really nice if there were more mechanisms to handle dependency management so that there's not just simple failure; where if it needs a certain dependency it would just be able to go out and grab it. But it's certainly matured, and I think it's well on its way to becoming a clear standard.
Genender will be presenting at The ServerSide Java Symposium this March. Genender is a member of the JSR-316 Java EE6 expert group committee, and author of Professional Apache Tomcat 6, Professional Apache Geronimo, and Enterprise Java Servlets.