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 [b]dynamic [/b]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 cos 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, cos not only are their products based on OSGi , it offers developers the opportunity to leverage the OSGi power to build apps. The gud 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 b4 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 dat I have seen shops that have been very successful with EJB. Tell mi am not smart enof, I wld 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 kinda rocket science software. But, rily, aw much better wld 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 dat it’s not all talk wen 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 wld 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 ur development career den it might not rily be worth looking at.

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

I think you're mismatching by comparing JSR-168 with OSGi. From what I just read about it again (been a while i heard of OSGi) the competing technologies should be CORBA, SOAP and in the realm of Java-only frameworks you could mention Jini. It simply seems to be the JavaBean spec on steroids. JSR-168 can as a matter of fact benefit from OSGi but of course that will be implemented in the Portal Server (e.g a Portal Server version of GlassFish can developed. The Portal Server hopefully will be JSR-168 compliant, but the server itself could be based on OSGi. I am not sure if the existing Liferay bundle that's based on GlassFish is OSGi-based simply because GlassFish supports OSGi). OSGi is for Java, JSR-168 is actually more HTML+Javascript. Even though the code that generates and formats the portlets may be Java, in reality it could be any programming language. Of course there are non-Java JSR-168 compliant Portal Servers.

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

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

sorry about that. what i had in mind was WSRP not JSR-168. JSR-168 is a java specification. but in general portlets are browser-based and manifest as a bunch of HTML/Javascript code @ the client end.

let me read up on OSGI and get back

that's why i said JSR-168 for instance will benefit from OSGi, since OSGi is a spec for Java code & therefore can only be implemented in the server architecture.

facebook has really done some good stuff with some other portlet providers with the pluggable web-apps they serve. does anybody have an idea what the technology is based on?

Am thinking 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.

@candylips
I doubt if a revision of servlet spec is required as most next gen App servers are already providing support, invariably making dem OSGi containers of some sort. check out Glassfish v3.

To modularise web apps, based on OSGi u mite want to check out Spring-DM 1.1 project. It comes with out of box support for Tomcat and Jetty web servers. Also, i fink anoda great project for building module based apps is impala.

Yes i have had a look at Spring DM and it sure works very well with Tomcat and Jetty.

OSGI is a great piece of technology i hope it makes it into the mainstream

@candylips

Nice to know that you are exploring OSGi.  Funny thing is that i have not been devoting enof time to developments in OSGi space. Mite need to get myself updated.

yea i had a look at equinox and felix but i had better joy with Spring DM .

Basically Spring DM sheilds you from all the OSGI apis by providing a very easy way for you to set up and reference osgi services as normal Spring beans.

Do have a look you will see how easy it is compared to the other implementations