What is Distributed OSGI ?

Many of you have already heard about Distributed OSGi (DOSGi) OSGi initiative and about the CXF DOSGi RI subproject (superbly documented by David).

I'd just like to comment a bit more about DOSGi.

Quite a few people have just immediately branded DOSGi as yet another RPC-technology and thus being not worthy of their attention. This is not quite correct.

DOSGi does prescribe how the OSGI consumers can end up with a proxy after using an OSGI ServiceTracker to get hold of a particular service interface reference. So it does make it possible for OSGI clients to consume remote applications with the help of proxies. Guess what ? Sometimes proxies will just work really well - some of those remote services will probably not change ever again or has been written by the same developer who writes a client bundle - thus making the future changes more manageable.

In the end of the day it is obvious DOSGi will help popularize OSGi among many developers out there as it makes it quite straightforward to have an end-to-end (D)OSGI application working.

But of course DOSGi is more than just about creating proxies under the hood. The primary use case is to let users expose their OSGI applications as remote services - you don't even have to use DOSGi on the other end to consume such services. It's become more obvious with the DOSGi RI now letting users to expose their OSGI services as SOAP based or RESTful (JAX-RS) services. You can consume such services from your browser if you wish.

So what some people might've missed is that in its basic form a DOSGi RI is an OSGi-enabled (CXF-based) web services stack. DOSGi RI is a handy collection of a number of OSGI bundles which you can drop into your favorite OSGI container and start developing web services (SOAP or RESTful ones) with OSGI in mind. DOSGi RI is a composite Web Services OSGi feature.

But DOSGi offers few more options. DOSGi Discovery service is a useful thing indeed. Now, it does facilitate the creation of proxies by helping DOSGI to discover that some services have been published. But note that DOSGI does not force your consumer bundles to use proxies, especially those consuming the RESTful services.
You can just write the client code using an HTTP-centric client API and simply use OSGi to replace your consumer bundles as needed. Or you can get hold of the DOSGi Discovery service and still use an HTTP-centric client API by feeding it the address of the remote RESTful service you've just obtained from the Discovery service. It would probably be worth adding a utiltity bundle to the DOSGi RI distribution which will help interested users to interact with the Discovery service though consuming it directly should not be too difficult.

Hopefully this blog entry has shed some more light on what DOSGi is about.