Universal OSGi

There is an idea that has been simmering in the OSGi Alliance for quite some time: Universal OSGi. My first recollection of this idea is from 1999, when I was working in Linkoping at Ericsson Wireless Technology, a place in the middle of nowhere. I worked there a couple of days a week helping them to use the OSGi specifications on the Ericsson ebox. This was not an easy task because there were virtually no Java programmers and lots of native Linux device driver developers. These guys have it in their genes to see anything between them and the Linux API as a personal insult. The fact that the ebox was severely underpowered for Java, 25Mhz 486 - 32Mb RAM - 8Mb flash, did obviously not do anything for my popularity either. However, these guys are intelligent and once they understood the modularity model and the remote management model that this enabled, they decided that they wanted to have it too. well, not the Java but the modularity. They even had visions to replace the OSGi specifications with something more native.

I objected to that model, and I still do. Though I am all too aware of the many flaws that the language was born with (I am a Smalltalker by heart, how could they miss closures!), I am profoundly impressed with what has been done on security and the abstraction of the the operating system. The OSGi technology provides some very crucial missing parts in Java, but a very large number of the features we provide are enabled by Java. I really do not believe that what is done in the modularity layer, the life cycle management layer, the service layer, and the security model can be done in any other existing environment. Not even .NET, though they get closest.

However, the need for integrating with native code does not go away because our model is better. The battlefield is littered with corpses that had a better model. It is a plain fact that in many of the markets that use OSGi technology, native code integration plays a major role. Java is good, but there is a lot of legacy code out there that is just not Java.

The only thing we have on offer for native code integration is through the Java Native Interface (JNI) and remote procedure calls like with web services, CORBA, etc. Anybody that tried to program with JNI knows how painful and intrusive it can be. I do not think I would have survived Linkoping proposing JNI. Remote procedure calls are better, and well known in the industry. However, remote procedure calls provide interoperation but no modularity, life cycle, or security. The interoperation through remote procedure calls works well as is proven many times, it lacks the tight integration of all important computing aspects that the OSGi technology provides.

Meet Universal OSGi. This is not a worked out concept but work in progress. Universal OSGi is an attempt to use the normal run of the mill Java based OSGi service platform but provide a model where native code can be integrated. This means that you should be able to download bundles with a native executable, like a DLL or shared library. Lets call these native bundles.

You should be able to express the dependencies of these native bundles in the manifest on other native bundles so that a management system could calculate the transitive dependencies, just like a Java bundle. Then you should be able to start and stop these bundles, which should result in loading the native code in another process and providing it with its dependencies, and starting it. The native code should be able to get and register services which are used by the native code to communicate with the rest of the system.

Handling the native code dependencies and the life cycle issues is not trivial but definitely doable. A native handler bundle can use the extender model to detect native bundles of a type it recognizes. This bundle would somehow have to interact with the resolver because the Java resolver needs to know when a native bundle can be resolved (or maybe this could be expressed with Require-Bundle). If the native bundle is started, the native handler will load the native code in another process. When the native bundle is stopped, the native handler cleans up by killing the process. Not trivial, but doable.

The hard part is the communication aspect. Obviously, the service layer is the crucial middle man, requiring that the native code can communicate with the OSGi service registry, hosted in the Java VM process. This requires a native API that maps the primitives of the OSGi service registry to C, C++, .NET, PHP, Haskell, etc. Primitives like registering a service, getting a service, and listening for services. And of course coupled to the life cycle layer. If a bundle is stopped, all its services must be unregistered. This registry is still doable, albeit a bit less trivial. The hardest part is how the services are mapped in the remote procedure calls. This is the problem that many have tried and few really succeeded because it somehow always remains messy. CORBA has the Interface Definition Language (IDL) which was supposed to be the mother of all languages but largely failed in the Java world because its C++ orientation made mapping it to Java painful. I remember a long ago project where we had two class for every parameter because that was the way output parameters could be modeled, a concept well known to C++ but unkown to Java.

For Universal OSGi, it is likely that the best solution is the Java interface as an "IDL". Not only do we already have a lot of experience with Java interfaces, they are also conceptually very clean, not associated with an implementation. In Java it is already trivial to proxy interfaces. it will therefore be necessary to map Java interfaces in a mechanical way to concepts known in the native environment. For example, in C++ a Java interface can be mapped to an abstract base class that can be used as mixin. Most OSGi service specifications are very suitable for this mapping.

A key problem in designing such a communication system is how the remote procedure calls are handled. A remote procedure call crosses the process boundary and pointers to memory locations are therefore no longer valid. Each process has its own memory. There are two solutions to this problem. One can pass the value to which the pointer is pointing, or one can pass a symbolic reference of the object. Passing a value can be done with immutable objects like int, String, etc. but it can not be done for complex objects like java.lang.Class. If a mutable object is passed by value, changes on the remote side are not reflected on the caller's side, changing the behavior for remote and local calling. However, one can proxy any complex object by passing a symbolic reference and doing the same for any objects that are exchanged in method calls. The other side must recognize this reference and do a remote procedure call back into the caller's process for all methods. This model is called proxying. It is too expensive for real life communications due to the latency and bandwidth constraints. For Universal OSGi it might be viable because it runs all the participants on the same device. That allows all communications tobe done with very fast techniques like shared memory.

These are intriguing and exciting ideas that could truly make OSGi technology more universally applicable. However, there are a lot of technical details to iron out and even when that has been done, there is a lot of spec work for different native languages. We need members that are willing to make this work. Interested?

Peter Kriens