Is Osgi Rily The Next Big Tng On Java Server Side ?

OSGi seems to be getting all the buzz these dayz. As it not uncommon to see Java server side bloggers spitting OSGi. OSGi is just a module  specification by OSGi Alliance. The main theme of the spec is modularization, and component/service orientation. It’s a dynamic module system for Java. I must say that the “technology” has been around for quite some time, and its bin receiving adoption by the open source community.  Ever imagined building modularized apps? I have always believed in apps based on modules but never rily did build apps based on modules because I didn’t just feel competent enof to do it. OSGi gives me the gut! Nywayz, the lumped up monolithic apps still did the job, so why bother. OSGi is probably going  to be the next Big tng on Enterprise Java, as it was made evident in the last JavaOne conference. Almost every meaningful entity on the Java Enterprise bandwagon is going OSGi. Even Sun! The Glassfish community only recently announced their V3 would be OSGi based. IBM, Oracle BEA, JonAs, SpringSource, Jboss etc are not left behind. I must say that SpringSoucre is rily leading the way here in driving OSGi to the Enterprise, with its recent announcement of SpringSource application platform (S2AP). Its not just about war and ear files now, we are looking at par (platform archives). I rily like SpringSource’s offerings, because not only are their products based on OSGi , it offers developers the opportunity to leverage the OSGi power to build apps. The good tng about OSGi is that it’s POJO driven.  Unlike the confusion called EJB. While EJB3 has seen some measures of  improvement, I had gotten off the boat long before its release. Spring framework just feels way lighter and simple. I believe the EJB tng added to the Java is hard commentaries. But I must admit that I have seen shops that  have been very successful with EJB. Tell mi am not smart enof, I would rather say I like my tngs simple. JSR 168 Portlets provide some form of modularity but its nothing compared to OSGi.

Nywayz, back to the OSGi. I recently had an interview, where one of  my interviewers  was saying their dev team had bin working on an upgrade version of their software for over a year now. I guess they must be building  some kind of rocket science software. But, rily, aw much better would it have been if the app was modularized and as such they  cld afford  to have incremental releases such that their esteemed customers cld begin to enjoy enhanced features due to the nature of industry they service. I understand that it’s not all talk when it comes to delivering great production apps. There are plenty of info online on OSGi. While I not too sure if there are plenty of books on OSGi, articles and tutorials would definitely get u wet. I am already playing around the major open source implementations ( Eclipse equinox, Apache felix and Knopflerfish). I shld add that OSGi  is not all server side, client/mobile side Java also use it. Enof said! If u just have about a year or so left in your development career den it might not rily be worth looking at.

So are u finking of leveraging OSGi in your next gig? Java still rules the Enterprise! Share your thoughts on this, or similar offerings on Microsoft .NET platform.

I just referenced portlets as providing some form of modularity when it comes to application development. Portlets and OSGi don't actually compete in the same space.

Rily i didnt know they were non-Java JSR-168 compliant Portal Servers.

Very interesting project.
Definately bleeding edge technology right there .

But you most ask yourself, can OSGi power a web application's plugin architecture? It doesn't seem like it (at the moment).
The web application would have to be deployed in an OSGi container to make this possible. Either that, or the web application would have to be an OSGi container itself 

Yes all webapps (including portlets) should theoritically benefit from OSGi based on its plugin architecture.

what i am yet to see from the current implementations of the OsGi spec (Equinox for instance) is the fact that you need an OSGi contanier to actually drive this. I see no benefit to this because you can still modularize an app by using webservices all over the place so this begs the question why use OSGi.

I think for OSGi to be widely adopted, app servers or servlet containers need to actually implement the OSGi spec and serve as OSGi containers. Sun probably need to revise its servlet specs to drive this.