Say “OSGi” and Java is not very far behind, they have been married since the early days. When we started working on the specifications Java was our obvious partner, and OSGi’s parents were well acquainted which made the marriage quite convenient. We needed a portable and security sensitive environment and we were very smitten with Java. However, the world has moved on since then and many other interesting partners are popping up all the times. People tell me that the adoption of OSGi technology is often hindered by the overhead that is introduced by a Java Virtual Machine and its sometimes obese library (it was very slim when we started!). We should also not forget the enormous amount of legacy code available in a diverse range of languages that many companies are unable to port. So far we had to deny them the wonderful features that OSGi offers like modularization and (remote) management. Why not let our minds wander off a bit and see what options there are?
A very interesting trend at this moment is the efforts of many to port native environments to the Java VM. Last week at Oredev a Ruby expert told me that JRuby (the Java implementation of the interpreter) had a significant better thread model than Ruby itself. JRuby is getting awfully close to implement the full Ruby language, which could create a drive to make JRuby a preferred environment because it can painlessly integrate any efforts written in Java. A similar story can be told about Jython, a Java based implementation of Python.
Even PHP is possible; I am currently preparing a demonstration for the 7 December OSGi members only webinar. We will show standard PHP applications running on an OSGi framework. The PHP interpreter (Quercus, from the Resin web server) is completely written in Java and it was not hard to turn it into a bundle. I just needed an activator that tracks bundles with PHP pages and registers a servlet under the right namespace. It is really cool to see how you can now write a web site in PHP and deploy it to an OSGi framework as a bundle!
The Java VM misses a few instructions to implement dynamically typed languages efficiently, but there are discussions going on to add these instructions to the VM. VM based solutions remain almost all of the advantages of using Java because they use the same programming and security model. Using the Java VM as the common denominator is therefore a very nice model and I expect to see many examples of this model in the coming years.
The VM model still leaves out native applications, and there are some really cool native applications out there. The standard Java solution is JNI, which, well, ehh, sucks; JNI is extremely intrusive and pedantic. Porting a C application to run under a Java VM is a painful exercise. The alternative is to use some communication mechanism, like for example sockets, and communicate over this medium. Doable, but it is hard because it requires addressing mechanisms, marshalling (serializing) to communicate any parameters, and many more chores: see CORBA if you want to know how painful this can be.
One of the best features of the OSGi Framework is the service registry. The service registry really decouples bundles from each other. A bundle that needs to communicate with another bundle never directly addresses that other bundle but uses a shared service to communicate. A service is defined by the API it implements and a set of properties. Services are detected or found dynamically and then bound. The service registry arbitrates between providers and consumers and provides appropriate security and life cycle control.
The most elegant solution to the legacy and native problem is an implementation of the service registry in C. Most languages besides Java support a very easy integration with C libraries. On the PC and on Linux it is quite easy to directly call DLLs or shared libraries from most dynamic languages. Writing a service registry in C that has the same semantics as the OSGi service registry should not be rocket science. Using a fast communication medium like shared memory would minimize any overhead. Key problems are the garbage collection, leasing issues, and marshalling. You could optimize the registry for tightly coupled clusters, though the technology obviously enables more loosely coupled solutions.
There are of course many interesting questions remaining. Should the management of the bundles remain in Java, or should these aspects be moved to a C library as well, allowing full Java free implementations? Obviously Java will be the best supported environment for a long time to come, however, living apart together might not be a bad solution to satisfy the requirements that I am hearing more and more.
Peter Kriens
No comments:
Post a Comment