I’ve seen quite a few blogs/articles/etc. lately related to the adoption (or lack thereof) of OSGi in the mainstream web application/enterprise application space. A nice summation of these is encapsulated in this excerpt from a comment by Peter Kriens on DZone (you’ll find it in the comments section for http://java.dzone.com/articles/osgi-perspectives:
Yes, one of the next frontiers is to make OSGi easier to use for the web app developers. The solid foundation is there, so stop whining and help us create the tools, books, and tutorials that will make OSGi palatable in those markets.
There’s nothing like a call to action to get me stirred up. It’s no secret that I think OSGi is an excellent tool for tackling the complexity of enterprise applications (see my talks on the NFJS tour this year: http://www.nofluffjuststuff.com/conference/speaker/matt_stine). However, I will readily admit that the learning curve for tackling any non-trivial application in OSGi is rather steep. My bar for non-trivial is quite low – try learning OSGi while simultaneously attempting to get a mainstream framework like Hibernate working properly.
I think that what we need is a tool that will enable a developer new to OSGi to get an OSGi-enabled web application up and running fairly readily. In fact, I think it would be good to absolutely minimize the amount of OSGi know-how required to get a basic web application into production, while at the same time leaving all of OSGi available just under the covers so that it can be easily accessed when I know what I need and how to use it. So here’s my proposal:
1) Follow in the footsteps of AppFuse, Grails, Rails, Roo, etc. and put together a web application toolkit that will allow one to instantly spin-up a deployable OSGI-enabled web application.
2) Since we’re talking about catering to mainstream here, Java the language ought to be the primary language used for development. With that said, we should not put up any barriers to using other languages available on the JVM.
3) Bootstrap a DB-agnostic persistence layer leveraging JPA and make it easily accessible across the application bundles.
4) Bootstrap a dependency injection framework for OSGi services based on the Blueprint standard.
5) Bootstrap a security layer and provide a basic user/role security module with provided login, logout, etc. facilities.
6) Pick a set of modern Java web application frameworks (e.g. Spring MVC, Struts 2, etc.) and make them easily pluggable.
7) Wrap a nice build system around all of this that leverages a modern build tool (e.g. Gradle or Maven 3), the best of the PAX Tools features (especially Pax Construct, Exam, and Runner), and good facilities for automated testing.
So, who’s with me? I’m open to any suggestions/comments/rants, etc.
Posted by Ian Skerrett on April 29, 2010 at 12:38 pm
This is a great idea and exactly what is needed. Unfortunately my developer skils are a distant memory but I’d be thrilled to see this happen.
Posted by Is it time for OSGi on Rails? « Ian Skerrett on April 29, 2010 at 12:50 pm
[...] it time for OSGi on Rails? Matt Stine is proposing to create an OSGi on Rails. This is exactly the type of innovation and easy on ramp the OSGi community needs to embrace if [...]
Posted by Wolfgang Schell on April 30, 2010 at 3:04 am
Hi Matt,
I think you’re right and I’m working on exactly this for Grails. The first version of the OSGi plugin (http://grails.org/plugin/osgi) simply makes the generated WAR an (monolithic and therefore huge) OSGi bundle. I’m working on the next version, which creates a bundle-ized Grails app without dependencies and some integration with the OSGi environment, i.e. services. Fully modular Grails apps are the final goal, but this is somewhat in the future. See http://blog.jetztgrad.net/category/plugin/osgi/ for some thoughts on Grails and OSGi.
Regards,
Wolfgang
Posted by Martin Cleaver on July 16, 2010 at 9:48 am
I’m totally with you Matt. And I see that Wolfgang (who’s Grails on OSGI plugin I was going to suggest) has already replied!
You know the phrase, “This Changes Everything”?
I think OSGi for Rails has the potential to do so.
Best,
Martin.
Posted by Ryan Hill on August 18, 2010 at 10:00 pm
Matt,
I think you are spot on with this idea; particularly with points 1 and 4 in your list.
Since you seem interested in NoSQL databases as well, why not combine the two?
CouchDB already includes a facility for handing specified HTTP requests off to external processes (using JSON over stdin/stdout), and erlang provides a simple means of communicating with Java processes in a more sophisticated fashion. In fact, running bnd on the jinterface jar that comes with the standard erlang distribution yields a perfectly usable osgi bundle, so getting the project started is relatively easy.
I am far from being a seasoned Java programmer (thankfully?), and I have had some trouble digging up non-trivial examples of how best to use EventAdmin in osgi; but I still managed to muddle my way to a rudimentary ‘hello world’ implementation — that is, taking a request from couch, publishing an event in osgi, and handling that event by passing a message back to couch. The source, such as it is, can be found in github. For now, I have an additional erlang script between the couch side and the osgi side. This is only to ease the task of prototyping a concurrent message/event passing interface, and I would expect the escript artifact to disappear altogether at some point.
Going forward I propose letting CouchDB handle the task of serving up static html, css, and media fies (in addition to data), and leveraging an external osgi based application to take care of more complex logical operations. CouchDB is well suited for its part of the equation (see http://couchapp.org), and is only going to get better.
Any feedback on this approach, positive or negative, would be most welcome.
I know I will be checking out the Grails plugin mentioned in an earlier comment.
Cheers,
Ryan