Minimal OSGi Systems

Every now and then the question pops up about OSGi in really tiny environments. The press release from ProSyst last week about the smallest OSGi stack caused this question to enter my inbox: "Can OSGi be used in constrained embedded solutions?"

Though OSGi is a no-brainer, the underlying question of the use of Java turns out to be harder, even after a decade where memory prices tumbled and processor speeds exploded. In this market the Bill Of Material (BOM) still is the all overriding concern, combined with 99% experience in C(++) coding in this world. Java is usually seen as a sidekick. Nice to have but real men use C(++).

The first OSGi app I worked on was the Ericsson e-box, a home gateway with 32 Mb of RAM and 2 Mb of flash. I always wanted to get rid of the Linux on it and run Java on the bare metal so we would have a single management model. I actually wrote Java implementations of DNS, DHCP, and even wrote a Java implementation of the TCP/IP stack to be able to communicate with SLIP devices! However, others in the project were experienced Linux people and found it a lot easier to just do everything with existing software. Fighting about this architecture wasted a lot of time and in the end we ended up with an ugly hybrid that was hard to manage.

Last week, a presentation from Andre Bottaro (Orange Labs/France Telecom) and IS2T on the OSGi community event seems to indicate that things are moving again. These companies developed a minimum OSGi stack in a really small device by removing Linux and running the VM on bare metal. However, though these tiny OSGi implementations are interesting exercises I must admit that I have mixed feelings. OSGi is about downloading modules, such a model requires some headroom to have value. Why waste resources to a mechanism that can only be used for trivial downloads? Java in the phone did not become very useful until Android provided an SE like class library that was sufficiently rich and the hardware had sufficient headroom to make downloadable apps feasible.

That said, I do believe that in the end OSGi is the way to go because providing new and updated functions become more and more a necessity. And there are more activities around this. Also at the community event Tim Ellison (IBM) demonstrated Apache Harmony and how the modular approach of Harmony (it uses OSGi metadata for its modules) can be used to create really small and efficient VMs. I am going to look more in Harmony because it looks like an ideal VM to run OSGi on. I also spoke to Marcel Offermans (Luminis) who is submitting a proposal to Apache for a C(++) based runtime that is based on the principles of OSGi and will work together with OSGi through the service registry. This seems even more ambitious than the Universal OSGi idea that we played with in the OSGi Alliance a few years ago.

I do hope we do see more efforts shrinking the OSGi stack like ProSyst, Luminis, Orange Labs, IS2T and many others are doing. One day we will be at a place where OSGi is a no-brainer, in small devices, including the Java part.

Peter Kriens