Article: Why Do We Need Distributed OSGi?

| by Stefan Tilkov on Feb 23, 2009. Estimated reading time: less than one minute |

OSGi, which initially started out as a Java modularization technology for embedded scenarios, has recently been adopted in a number of application servers, ESBs and other enterprise middleware products. While it has initially been restricted to running within a single JVM instance, the question of how one might go about distributing it to multiple processes becomes asked more and more often.

Recently, an early release draft of a Distributed OSGi requirements and design document has been published, along with a reference implementation as part of Apache CXF. In a new article, Eric Newcomer writes about the current status of distributed OSGi and explains the reasons for standardizing it in the first place, and its significance to the OSGi specification and community.

Check out the article for more information on the current status of Distributed OSGi

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

well-trodden path by Gerald Loeffler


my understanding of distributed OSGi is that it is the appropriation of extremely well-understood concepts in distributed computing to the OSGi component model and platform:
- meta-data to denote services as remotable
- in keeping with the OSGi spirit remote services are described via Java interfaces
- registry and discovery of remote services
- as-good-as-possible location transparency for the developer. there is even a remote exception for one case where this abstraction doesn't hold.
- re-use of existing remoting protocols and technologies (WS, CORBA, RMI, ), also in the area of service registries and discovery (UDDI, LDAP, ...)
- the use of SCA-like intents (quite a lot feels like SCA anyway) to match what services offer and clients need

all this is, as i said, perfectly well-established. it's "just" the introduction of these concepts into the OSGi technology space. and that's probably a good thing for a standard, although it makes one wonder how many reincarnations of the same ideas we will keep seeing.

the problems, as before, will be in interoperability and performance.

or am i missing anything fundamental here? is there some revolutionary innovation luring somewhere?

just trying to understand it as much as possible,

Re: well-trodden path by Eric Newcomer


Yes, your understanding is correct. The main reason for it is to allow an OSGi service to communicate with another OSGi service in another JVM. The existing specification defines service oriented behavior only for services running within a single JVM. Enterprise application requirements often require designs that span JMVs/address spaces - load balancing, failover, scalability. Although we have not explicitly defined how to achieve any of these, our intention was to define how existing technologies used to support such topologies can be integrated with an OSGi framework in a standard way.

Just as we are not defining anything new, nor are we solving any problems with existing technologies. Interoperability and performance challenges remain as they did before D-OSGi. But as a developer of a distributed enterprise system you will be able to get the benefits of OSGi in a standard way.


Belorussian translation by Eric Newcomer

I'm pleased and flattered to point to a Belorussian translation of this article:

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

3 Discuss