OSGi vs. JRuby on Rails, pt. 1
Posted on December 7, 2008
by Tommy McGuire
I am writing a note on our our of JRuby on Rails applications to an OSGi, SpringSource dm Server based platform. This is the first, introductory section; futher segments get into how to configure the Rails app for the OSGi environment and a nice technique for supporting Rails development.There are more than a few ways of deploying a Ruby on Rails web application. One way of narrowing the choices is to use JRuby, which also has the advantages of allowing the application to use the large number of Java libraries and of making use of a number of excellent deployment and monitoring options. [1] One of the best options involves deploying JRuby on Rails applications with Glassfish. It is well supported and well documented, and seems to be a pretty nice way to go.
On the other hand, OSGi has been generating a lot of interest in Java enterprise circles. OSGi provides a generalized Java container, a structured environment for deploying and executing Java code. The OSGi container, beyond other Java containers, supports modularity and the disciplined use of modules in separate applications. Further, and a unique (to my knowledge) feature of OSGi, the OSGi container can use multiple versions of a module simultaneously. As a result, an OSGi system can provide an ideal software ecosystem for an organization developing and deploying multiple related applications on a consistent and reusable underlying framework.
Current versions of Glassfish and other Java application platforms do not make use of OSGi although they will in the future, to a greater or lesser extent. [2] However, the SpringSource dm Server does. In fact, it does so particularly nicely: a deployed web application is treated as just another OSGi bundle: it can use its choice of other modules, it can access the OSGi services registry, and multiple versions are supported easily.
Our current framework is based on the SpringSource dm Server and a locally written framework for configuration, services, and logging. (The SpringSource dm Server is known here as SSdmS, which is just lame, or dmS, which is shorter but still lame. Is there a good short form of that monstrosity?)
Internally, dmS uses a large number of open source systems, such as Equinox, AspectJ, Log4j, and most importantly for us, Tomcat. JRuby on Rails applications can easily be deployed to Tomcat using Warbler to pack the Rails application as a .war. The remainder of this document attempt to describe how we are handling the deployment and configuration of the Rails applications, and some some additional support we have for application development.
Footnotes
[1] It also may or may not perform better than MRI. Some have reported that the performance is better or much better. My own observation is that the performance is not worse, and might be better.
[2] I have yet to see how a Glassfish application, such as a Rails web app, would interact with OSGi. According to what I have read, Glassfish does not intend to automatically deploy .war files as OSGi bundles, as dmS does. On the other hand, it seems impossible for them not to, since that would be a significant limitation. Other OSGi-based application platforms such as JOnAS do, although in different ways.
