R-OSGi and Distributed OSGi: differences and similarities

4 September, 2008 at 15:51 2 comments


ECF Eclipse Communication Framework is a framework for supporting the development of distributed Eclipse-based tools and applications. It can be used to create other plugins, tools, or full Eclipse RCP applications that require asynchronous point-to-point or publish-and-subscribe messaging.

ECF providing two things to developers:

  • Real-time communication and collaboration features for teams using Eclipse such as peer-to-peer file sharing, remote opening of Eclipse views, screen capture sharing, and real-time shared editing.
  • A set of communications APIs and frameworks built upon existing protocols (like Google Talk, XMPP, SSH, HTTP/HTTPS, Rendevous, IRC, and others) for developers to add communications and messaging to their own Equinox-based plugins, or customize and extend the ECF applications. The APIs support peer-to-peer as well as client-server and multipoint messaging, and are focused around specific types of communication, such as peer-to-peer file transfer, presence/IM/chat, dynamic service discovery, remote OSGi services, channels for messaging, etc.

Introduction: ECF Containers

ECF introduces the concept of a communications container. ECF containers represent access to a protocol-specific communications context. For connection-oriented communications, an ECF container loosely corresponds to the traditional notion of a communications session, but the more general container concept is also useful for capturing context even if the communications are not session-oriented.

ECF containers can represent both point-to-point communications (e.g. client/server) or publish-and-subscribe (group) communications. Container instances can provide access to synchronous communications only, asynchronous communications only, or both together. This flexibility allows many communications applications to be constructed out of one or more ECF containers…each of which provides access to some specific communications context and some protocol(s) for communicating within that context. (more)

Distributed OSGi

The goal of distributed OSGi is to extend the OSGi framework for distributed computing capabilities by configuring an existing distributed computing software system (such as Web services, CORBA, or Eclipse ECF) behind an OSGi service. The goal of distributed OSGi is to allow a service running in one OSGi framework to invoke a service running in another, potentially remote, OSGi framework (meaning a framework in a JVM). This excerpt makes it quite clear what this initiative is all about:

The Distributed OSGi effort also seeks to enable “a service running in one OSGi framework to invoke a service running in another, potentially remote, OSGi framework (meaning a framework in a JVM),” Newcomer wrote. As the current OSGi standard only defines how services talk to each other only within a single JVM, “extensions are needed to allow services to talk with each other across multiple JVMs — thus the requirements for distributed OSGi on which the design is based…. Overall we recieved good feedback, and a lot of questions pertaining to work that still needs to be done. We hope to be able to publish the code to Apache and publish a draft of the design doc this summer, perhaps in August, after we have a chance to formally review the initial implementation with the EEG membership, and get their blessing (no doubt there will be some changes as well since this is just the start).” he said.


R-OSGi runs as an OSGi bundle and facilitates distribution for arbitrary OSGi framework implementations. All that a service provider framework has to do is registering a service for remote access. Subsequently, other peers can connect to the service provider peer and get access to the service. Remote services are accessed in an entirely transparent way. For every remote service, a local proxy bundle is generated that registers the same service. Local service clients can hence access the remote service in the same way and without regarding distribution. R-OSGi, a distributed middleware platform that extends the centralized industry-standard OSGi module interface to support distributed module management. To the developer, R-OSGi looks like a standard module management tool. However, at deployment time R-OSGi can be used to turn the application into a distributed application by simply indicating where the different modules should be deployed. In particular, at run time R-OSGi represents distributed failures as conventional module insertion and withdrawal operations so that the logic to deal with failures is the same as that employed to deal with dependencies among standard modules. In doing so, R-OSGi greatly simplifies the development of distributed applications with no performance cost. Hal Hildebrand in his blog said:

At this year’s EclipseCon, I went to a talk by Jan Rellermeyer regarding his R-OSGi system. His stuff is open source, which you can find here. The slides for his talk are available here. It’s extremely interesting and I would suggest anyone who’s interested in the distributed OSGi stream to both download and play with the r-OSGi system and to read the paper and presentation. In particular, I think that his discussion of the alternatives vis a vis Jini, UPnP and SLP is quite illuminating. (more)

NB the presentation slides for R-OSGi have just been posted .

Differences between Distribuited OSGi and r-OSGi:

Hal Hildebrand wrote the differences between Distribuited OSGi and r-OSGi:

A couple of people have asked about the differences between the implementation I have for a distributed OSGi framework and the framework described by Jan Rellermeyer (see my previous entry on the subject). In a nutshell, the primary difference is that the way services are advertised and discovered is completely hidden in my implementation. The implications, though, that this small difference has on usability and integration with existing OSGi frameworks is rather profound.

    // obtain the reference to the RemoteOSGi Service

    // insert standard method for obtaining services

    RemoteOSGiService remotingService = ....
    // create listener for the desired remote service 

    DiscoveryListener listener = .....
    // create the properties for the listener service

    String[] ifaces = new String[] {"ch.ethz.iks.r_osgi.sample.api.ServiceInterface"};

    Dictionary props = new HashTable();

    props.put(DiscoverListener.SERVICE_INTERFACES, ifaces);

In Jan’s implementation, the primary interface to the system – from the client’s POV – is the RemoteOSGiService interface. To make use of a remote service the client does the following: (more)


Bookmark and Share


Entry filed under: Distributed Systems, OSGi. Tags: , , , .

Functional programming: Examples, Methods and Concepts The Internet’s Biggest Security Hole: exploiting the internet routing protocol BGP (Border Gateway Protocol)

2 Comments Add your own

  • 1. interesting business articles  |  14 November, 2011 at 11:35

    Best advice ever is never to just jump into any business. First do research and find out all every possible thingabout that field. Make sure you are able to draw client base.Do your market research read about other bussiness what they have done. I found some interesting business articles here

  • 2. click here  |  28 May, 2014 at 17:36

    Woah! I’m really loving the template/theme of this
    website. It’s simple, yet effective. A lot of times it’s very difficult to
    get that “perfect balance” between usability and appearance.
    I must say you have deliver a great job with this.

    Additionally, the blog loads very quick for me on Internet explorer.
    Excellent Blog!


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed

IT Passion’s Store



Get the Source
OSGi supporter
JUG Milano

Upcoming Events


Blog Stats

  • 328,400 hits

My PageRank

What's My Google PageRank?

%d bloggers like this: