With the deadline for a grant proposal fast approaching, I’ve been placed in charge of writing about the development techniques and technologies we’ll be using in the project. Apparently, we don’t have to include promises to use specific products, but we should reference the options we’re considering and what standards we’re planning on using. In order to write a somewhat well thought through proposal, I’ve been researching:
1) Containers: JEE App Servers, OSGI frameworks (Felix and Equinox), and Spring DM
2) Web services frameworks: Axis2, CXF, and JAX-RS implementations (CXF and Jersey)
3) Messaging and Service Buses (Servicemix, Mule, and ActiveMQ)
From my brief experiments with these products, I’ve come up with a pretty trim proof-of-concept that might serve our needs in Matterhorn. It works like this:
A main class boots an instance of Apache Felix, which is configured to auto-start two OSGI bundles (there are others, but only two are of particular interest): CXF and a Jackrabbit JCR server. Other OSGI bundles can be added, removed, or refreshed at anytime via Felix’s web interface (I don’t have it up and running yet in this environment, though I have tested the management webapp that comes with Felix, and it’s pretty easy to use).
I’ve added a sample component that uses the JCR server to get or set content (currently a string… it’s just a proof-of-concept afterall 
) at a particular path in the repository, and this functionality is exposed as a webservice. I was pleasantly surprised that it took only a few minutes to publish a web service. The implementation of the component is under 100 lines of code, too.
What this setup buys us is a very lightweight way to manage components in a running system, so we should be able to hot-swap services as we make changes during development without stopping/restarting the entire system.
In addition to the cost of migrating code from existing projects (such as REPLAY) into OSGI bundles, the strict classloading rules of the OSGI environment take some time to learn, and will most likely slow developers down (not that everyone will need to work in this area of the system). Still, with the number of projects moving toward OSGI, it seems like this is becoming the de facto Java component system, and it will behoove us all to become adept in this environment. That, and we don’t have to get into the business of providing our own container, or trying to use one that doesn’t meet our needs for component isolation.