Distributing OSGi

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.
After I went to Jan’s talk I went back to my cave and started to play around with my own version of the system. I had been playing with SLP (Service Location Protocol) quite a bit in other distributed systems and it was quite obvious after Jan’s talk that SLP and OSGi are a good fit. However, I was rather troubled by the degree that SLP was exposed to the end programmer and started on my own implementation.
What I ended up with is a system which has, I believe, a minimal surface exposed to the end programmers of an OSGi system. From the service interaction perspective of the programmer, the only mechanism which is added to standard OSGi is the way you indicate which services you would like to import into your local OSGi process registry. There is no exposure of SLP or any other system for discovering services. Rather, the system simply makes use of the already existing mechanisms in OSGi for discovering services – i.e. the service registry, filters, ServiceReferences and ServiceTrackers n’ such.


From the perspective of a service which wants to export itself to other processes, a property is added to the service when it is published which indicates the intent to distribute the service. I’m simply reusing Jan’s property conventions that are relevant. In this case, when the service is published, a property with the key “service.remote.registration” is supplied (the value is irrelevant at this point, as the presence of the property triggers the distribution of the service). This is all that is required to distribute a service.
From the perspective of the client, or user of the distributed service, the only addition to OSGi is the indication of what services the client would like to see imported into the client’s local registry. This is done in the standard OSGi fashion using a Filter – i.e. an LDAP expression indicating the service properties for selection which one normally uses when selecting services from the local OSGi service registry. Here’s a straw man:
public interface UnifiedRegistry {
    void track(Filter);
    void forget(Filter);
}
When a filter is submitted to this service for tracking, any service which is provided by another OSGi process for distribution which matches the indicated Filter is automatically imported into the local OSGi registry. So, from the perspective of the client code, there is no difference is accessing local services from the OSGi registry than there is accessing remote services. This illusion is maintained by registering proxies for the distributed services in the local OSGi registry.
What is interesting is that from the end programmer’s perspective, the above sums up literally everything that one needs to use – the only service the end programmer will interact with is the UnifiedRegistry service shown above. Nothing else more is needed to be defined to create a distributed OSGi implementation – from the perspective of a standard.
Now, there certainly is more to the system underneath the hood. The whole mechanism that services are advertised and how the actual remote communication is accomplished still has to be implemented. However, the beauty of re-using the existing OSGi mechanisms means that these implementations are completely orthogonal to the experience of the end programmer. Service advertisement may be accomplished by a SLP implementation, or by any mechanism the vendor wishes to implement – the service advertisement mechanism does not need to be defined by OSGi.
Likewise, the distributed communication implementation does not need to be defined because it is really is completely hidden. The activation and lifecycle of the distributed service is completely defined by OSGi – in my implementation, I’m just using a service listener to listen for the lifecycle events of distributed services. Likewise, control of the proxy lifecycle is also completely controlled by OSGi – the import into a local registry is the act of installing a bundle and the proxy lifecycle is, again, the OSGi lifecycle. When the distributed service disappears, the proxy service (in all the clients) will also disappear. The client code uses the local service registry and the standard OSGi mechanisms to find distributed services. Interaction with the lifecycle of the distributed service is accomplished through the same OSGi mechanisms, listening for service lifecycle events.

5 thoughts on “Distributing OSGi

  1. Thanks for the links to the talk and slides, I was looking for them at another website where they had disappeared.
    I am currently doing a research project that is a distributed services system, that can use mobile tech, like phones or PDA’s. I found your insight very useful. Do you know of any other interesting reading material or projects with similar goals.
    One of the major concerns that I have to consider which you mention but not in great detail is the use of OSGi life-cycle event handling distributed. For instance the handling of a service provider that fires no life cycle event because they disconnect.
    Cheers
    Graham Jenson

  2. In Jan’s implementation, this is handled by a traditional lease on the distributed service – i.e. the infrastructure periodically polls to ensure liveness. So, technically, things work as you’d expect because the service will be unregistered when it’s discovered that the underlying service has been disconnected. So, all the life cycle events you expect to see are provided.
    In the systems I’m developing, the underlying system uses group membership protocols to proactively detect liveness, so the experience is much more seamless. But the effect is the same: when the remote service disconnects, the client sees the service removed from the registry and the correct OSGi life cycle events fire.

  3. Hey back again after looking at Jan’s slides. I was wondering after getting the main ideas of r-OSGi, if you could have services provided by nodes that are not running a OSGi framework.
    I have a small robot that can connect to a wireless network and host some byte code, I don’t know how I will broadcast the service(Probably robot discovery service off a computer), but I can host a controlling GUI, or just a service that allows the robot to be moved, at a URL. I was wondering if there is support for this, it also could be that a phone with wireless but not enough grunt to run OSGi may want to host some services, but not the full OSGi.
    Also I am planning to have it so that the network that is queried for services, is a P2P so that there is no centralized server, what are your thoughts on how supported r-OSGi would be for this requirement.

  4. Sure. there are several ways to do this. The first is to bridge the external service through an OSGi service – essentially proxying it. Alternatively – and this would entail some modifications and extensions to Jan’s work – you could work things such that you could generate the necessary proxying structure from the SLP advertisement and plug that into the service registry. The difference here is that there’s no OSGi service representing the “other end”. Rather, the proxy at the front end is the communication end point. The lifecycle would still be controlled through the SLP advertisement lifecycle.

Leave a Reply