OSGi and Jini
Last year I wrote a blog about why we let Jini out of OSGi R4 which I think reflects our thinking at the time. However, yesterday I accidentally ran into a mailing list archive Jini vs/and OSGi that turned out to look like some heavy soul searching by some people in the Jini community caused by my blog. (disclaimer, blogs are personal and do not reflect any official position from the OSGi Alliance).
This was a very interesting read, first because some posters felt there was a struggle for market and mindshare between Jini and OSGi. The title of vs/and left this as a question,but some posters focused on the vs. Some posters felt that OSGi dislikes Jini, and others seem to think that Eclipse equals OSGi and they do not like the Eclipse people and IDE, which it clearly does not: look at Knopflerfish, Apache Felix, ProSyst, and many others. Fortunately, Niclas Hedmann and Richard Nicholson joined the discussion to shed some OSGi light.
First in my mind there is no struggle because comparing Jini and OSGi is like comparing a car and a road. These two specifications are quite orthogonal with completely different requirements. Jini is about a network computing model and OSGi is an execution point.
The OSGi Alliance does not want to be an all encompassing framework. We are working very hard to create a layered model where the lower layers are useful also in environments where there is no network, resources are too limited, or where other networking standards are more prevalent. I see Jini and OSGi as two layers in a layered model. OSGi defines the bottom layer that defines how to wrap your code and how code from different sources can work together in a single VM. On top of this layer Jini code can sit and do its Jini thing.
OSGi is missing ...
Interestingly, with the higher rate of OSGi adoption I see more and more complaints about OSGi. OSGi is lacking distribution, OSGi has no management protocol, OSGi does not have a serialization model, OSGi does not support whatever. In my mind, these are compliments; It meant we have been able to keep the OSGi specifications focused.
We are lacking features if you could for example not use Jini on an OSGi framework, or if you could not support a specific management protocol. We worked very hard to create a model that is useful in small constrained environments without constraining large systems in their possibilities. Our hardest task is too keep it as mean and lean as it is today.
The focus of the OSGi specifications is that in almost any case you need to manage deployments. Even in a network computing model like Jini there is a need to execute the software on some CPU. Plain Java is lacking the deployment and modularity features that I think the OSGi service platform provides as an execution point. Well defined version handling, remote management, deployment format etc. It even allows non-Jini code to easily interact with Jini code.
The only important overlap I see between Jini and OSGi is the service model. These models are enticingly similar, both are based on registering objects with a registry and reacting to registered and unregistered objects. If you are a programmer deploying your code on an OSGi box with Jini, which service model should you use?
OSGi advocates the model where you register your service with the OSGi service registry. A Jini driver could then register these services with the Jini registry. The Jini advocates likely propose registration with the Jini registry where the OSGi Jini driver could pick them up and register them in the OSGi service registry.
In the first case, you couple yourself to OSGi, in the second case you couple yourself to Jini (and of course all invocations will have the remote call overhead). This raises the interesting question of transparency of the distribution. Billy Joy's key insight for the Internet has been that creating a perfect network that never lost a package was impossible. By handling errors on the end points a network component like a router could always throw away packages if it ran into problems, simplifying these components enormously. The end points would use retries, back off algorithms, and alternatively routing to solve this problem.
He translated this insight into remote computing: do not hide the distribution. Jim Waldo informed me that the story is different. This is interpreted by many that applications should always be aware that they do remote procedure calls. The pesky Remote interface and the obligation to throw the checked RemoteException on RMI generated interfaces are the exponents of this view. However, this flies directly in the face of POJOs and aspect oriented programming. Both practices do not say one should ignore remote issues, they say do not bother the application logic with these problems; handle them on the side.
Paramount is that errors in the distribution are handled by the system and not ignored, this does not mean application logic needs to be involved.
In a normal Java environment there are no primitives that can express this failure model but in the OSGi service platform there are such primitives. OSGi services can come and go at any time and bundles can be stopped and restarted. If a Jini service is registered with the OSGi service registry it can be unregistered when the lease expires or the connection is not responsive anymore. Bundles that depend on these services must react accordingly. Dependency handlers like Spring-OSGi and Declarative Services can automatically reconfigure the application on the basis of the available services dynamically, with just activating and deactivating the POJOs. The service availability problem is intrinsic in the OSGi model and it handles much of the distributed problems.
Another issue is the remotability of the service. Jini services by definition can be remoted, all arguments must be serializable. OSGi services do not have this requirements so not all of these services can be remoted, but this can be a choice of the developer, not all services in an OSGi platform have to be Jini services.
The only real difference that remains is the difference in timing. Distributed calls take magnitudes more time than local calls. This is true, and applications that work ok in a local call environment can come to a grinding halt when distributed. However, this should not be an issue at programming. If I create a component and it depends on a service with remotable interface X, then it is the responsibility of the deployer to decide who and where X is implemented, not the developer of the component. He can put a requirement on the implementation but it is just plainly not his choice. If the deployer links it to a Jini service he will get less performance than when he links it to a resident service. In many cases, the lower performance is a small cost for the flexibility to call remotely.
I wish the Jini community would take a closer look at OSGi and see how we can collaborate. The by far most important reason we dropped Jini from R4 was lack of a party pushing it into the organization. At the time we dropped it, Jini was at a low, and as a scorned lover my regards for Jini were very low. However, from reading the exchange and seeing what Paremus is doing, I think a collaboration would be fantastic for our communities, especially after seeing what the Paremus people are doing with Jini and OSGi.
As Niclas said, the OSGi process requires the writing of an RFP that expresses the requirements. We already have an RFP for changes required by RMI from Paremus. That said, once the RFPs are approved we do need members that want to take this up and write the proper specifications.
Hmm, this article made me curious to Jini again, its promises were always very enticing ...