01st May 2008 by Mark Turansky
You can’t keep a good idea down
Filed under Our message bus project was more than just replacing JMS with a POJO messaging system. It’s a whole piece of infrastructure designed to make it easy for different folks to do their jobs.
How did we do this and why do the next couple of paragraphs sound like I’m bragging? Because many of the features we implemented were recently announced in a new open source project (more on that later). Bear with me as I go through some of the features we implemented, knowing that I’ll tie them to the features of a recently announced (and exciting) open source middleware product.
Configuration Management and Network Deployments …
We deploy applications to our bus over the network by the way of a simple little bootstrap loader. You’ll note the Java class I used in my blog article uses a URLClassLoader. My example used a file URL (”file://”) but there’s nothing stopping those URLs from beginning with “http://…”
This lets our Config Mgt. team deploy applications to a single place on the network. As nodes on the network come up, they’ll download the code they need to run.
… via Bootstrapping
While we’re on the subject of bootstrapping, there’s nothing stopping a smart developer from bootstrapping different applications into different classloaders. Again using the Java class from my blog article, you’ll notice the code finds the “main” class relative to the classloader. Who says you need just one classloader? Who says you can only run “main” methods? Stick all your classloaders in a Map and use the appropriate classloader to resolve an interface like, say, Service (as in Service Oriented Architecture) with an “execute” method. Suddenly, you can have applications that are invoked by a Service. We used this very technique to integrate legacy, stand-alone applications into an SOA.
Take bootstrapping and isolated classloading one step further and you’ll soon realize you can load multiple versions of the same application side-by-side in the same container. One could be your release branch version, the other could be your trunk code. Same infrastructure and container. We did that, too.
Lastly, what happens if you dump a classloader containing an application and replace it with a new one containing a new version of the application? Well, you just hot swapped your app. You updated the application without restarting your container.
Focus on Developer Productivity
Developers? We got them covered, too. We went for a simple pure Java POJO model. No app servers, databases, or anything else required. A developer can run the entire message bus — the entire infrastructure — in a single JVM, which means inside your IDE. Unit tests are a snap because all Services are POJO classes. Did I mention it takes one whole second for someone to start a local instance of our message bus in a single JVM? I’m a developer first, architect second. I like to think about how my decisions affect other developers. If I make it easy, they’ll love me. If I don’t make it easy, well, … I don’t think I’ve done my job well.
Utility Computing w/o Virtualization
It’s a lot easier to get efficient use of hardware once you can load all your applications into a single container/framework. If you bake in queuing and routing (a message bus), then you can implement the Competing Consumers pattern for parallelism in processing. Also, if all message consumers are running all applications (thanks, classloading!), then your consumers can listen on all queues to process all available work. This is utility computing without a VM. Our project lets us use all available CPU cycles as long as there is work in the queues.
There’s also the Master/Worker pattern to process batch jobs across a grid of consumers. Grid computing is one aspect of our project, but a minor one. I’m more interested in the gains we achieve through utility computing and the integration of several legacy applications to form our SOA.
The Open Source Version
Here are some features from the open source project, tell me if they sound familiar:
- You can install, uninstall, start, and stop different modules of your application dynamically without restarting the container.
- Your application can have more than one version of a particular module running at the same time.
- OSGi provides very good infrastructure for developing service-oriented applications
http://www.javaworld.com/javaworld/jw-03-2008/jw-03-osgi1.html
SpringSource recently announced a new “application platform” with some of the following features and benefits:
- Real time application and server updates
- Better resource utilization
- Side by side resource versioning
- Faster iterative development
- Small server footprint
- More manageable applications
http://www.springsource.com/web/guest/products/suite/applicationplatform
http://www.theserverside.com/news/thread.tss?thread_id=49243
Now, if only the SpringSource Application Platform could add queuing and routing to their project, we might consider porting to it. In the meantime, I’m happy to see other projects validating the ideas we pitched here at our company.
I’m excited, too, to announce that I’ve received the blessing of Management and PR to write a white paper about our project. It will cover all the above features as well as a slew of others, such as service orchestration and monitoring, asynchronous callbacks, a few other key Enterprise Integration Patterns, and it will explain how we used Terracotta Server to tie it all together. Stay tuned! I’m going to write blog articles to coincide with the sections of the paper.
What's next?
Leave a comment
Digg it
Save This Page
I’ve just implemented a version of this message bus, built a service loader using a classloader-per-service (going to enhance to be closer to the bootstrapping design you mention), and will be enhancing the service loading to support hot-deploy-undeploy of service jar files.
Of course, without Terracotta, it doesn’t make sense to do it because you can’t scale it without adding a lot of complexity for distribution - but thanks to Terracotta and your post about the message bus you did, we have stripped all J2EE out of our architecture making it much simpler for service developers, much faster, and much more scalable. What has us so excited about this approach is exactly what you said about developer productivity - that is Right On!
So thanks for putting two and two together so easily and pointing the way - this should be the standard architecture for any pure Java distributed system.
Spring-integration has queuing & routing like ESB but I don’t know how easily it would be integrated into spring-ap. Perhap it must be an OSGI modules first?
As a member of Mark’s team, let me say: good luck with cleanly un-deploying services developed outside of your control.
A good summary of the problems you might face:
http://opensource.atlassian.com/confluence/spring/pages/viewpage.action?pageId=2669
It’s harder getting classes to unload than you might think, even if you control the classloader in which they were instantiated!
More ClassLoader fun: http://bugs.sun.com/view_bug.do?bug_id=4950148
Every paragraph I read I thought, Well, yes, that’s great.. but we’ve been doing that in scripting languages for ages.
It is good, though, that Java gets a short-cut to using less life per app. This really is very good.
Still, should you become inclined to look, there are are similar treasures further out, for free.
We’re lucky in that our system is pretty much all-new development where every service is being built by us, so that we can enforce lifecycle control and notifications. I’m looking into using annotations that our classloader can introspect when it loads a service - both for pattern conformance and also to possibly generate/map the necessary subscribers and callbacks to the bus, leaving the developer free to just write business logic.