Thursday, October 08, 2009

Slides from JAOO: OSGi on the Server

It was my first time being at JAOO in Aarhus, Denmark, and it was absolutely great. Lots of interesting talks and discussions and I enjoyed a lot to talk in this fantastic cinema-like room:

I talked about the different settings how you can use OSGi on the server-side and about the dynamics of OSGi applications:
And you can find most of the slides of the other talks at the schedule pages of the conference. Enjoy!


Steve said...

I spotted a minor typo: Spring Titan instead of Sprint Titan.

You had me interested in a new Spring project until Google crushed my hopes 2 minutes later ;-)

Martin Lippert said...

Hi Steve!

Thanks for the feedback on the typo and sorry for the confusion regarding the "new spring project"... ;-)


Dominique De Vito said...

I have questions:

- are you aware of existing OSGi-based deployment as a replacement of EAR deployment ? And which servers do support easily that kind of deployment ?

- are you aware of OSGi-based deployment instead of portlet-based web site for portal building, as stated here ?


Martin Lippert said...

Hi Dominique,

if you don't have heavyweight EJB stuff in your apps, there are plenty of servers that allow you to deploy your app as a set of OSGi bundles. The simplest setting is to use Tomcat or Jetty embedded into OSGi. If you download the Eclipse SDK, for example, you already got everything you need. These is a OSGi-yfied Jetty running on top of OSGi. You could also use SpringSource dm Server, which is a payware product from SpringSource that contains much more features and the SpringSource Tool Suite that makes it easier for you.

If you would like to deploy EJB stuff, you could take a look at Jonas, which is also an OSGi-based app server that allows you a tight integration between OSGi and EJB stuff.

With regards to you portlet question: You can think of building modular web apps based on OSGi, this seems logical when using a module system such as OSGi. I have no idea why you should use portlet stuff instead, but I guess that portlet technology aims at solving other problems like single-signon etc., which as far as I know people are solving differently nowadays (than which portlet APIs).


Dominique De Vito said...

Hi martin,

Thanks for your quick+kind answer.

To be precise, I don't want to use portlet. In fact, I am much more in favor of OSGi. My idea is that portlet technology is more or less doomed when OSGi rises on the server-side.


Fred said...

Question to dominique, did you end up with an answer to your question ?
Do you think OSGi coud be a replacement for a portal, and that it is possible to start now on such a project ?
Any framework to recommend ?

Dominique De Vito said...


IMHO in a long-term view, OSGi servers are going to provide an alternative portal solution. But for the short-term, OSGi raises a bit slowly on the server-side to fight portals within a mainstream point of view.

For short/medium-term, my opinion is that the main portal competitor is GWT. I have already written about it:

Portlet life looks like EJB, but future sounds like GWT

The portlet/GWT comparison is in favor of GWT