Eclipse Corona Project. Distributed OSGi?

As a virginal committer on Eclipse/Equinox I receive all kinds of mail about Eclipse projects. Today an interesting project proposal drew my attention: Corona. Ok, the name is a bad start. The Apache model of names without a cause is becoming a trend. The full project name is almost less intelligible: Tools Services Framework. However, when you look beyond these words, you can see the interesting bits. In this case this is the corona core, which is described as:

Corona Core - A set of OSGi-based plug-ins that implement the Corona framework. These plug-ins define the extension points for shared Repositories, Projects, Tasks and Collaboration spaces. Additionally, we will deliver an implementation of a Link concept and the existing Marker concept. Finally, we will provide a Manageability abstraction within the Core that can be mapped onto a Web Services Distributed Management (WSDM) interface.

Now there is a lot of inevitable jargon in this text. Extension points are an Eclipse concept that is similar to services. Extension points have a type that is defined in XML files; plugins/bundles can indicate they provide certain extension points. They, however, lack the dynamic aspects of services. Extension points used to have the advantage of lazy initialization, that is, no class loader of the provider was created until the provider was used. Originally extension points were a pure Eclipse feature but the Equinox team has ported this to a bundle so all OSGi Service Platforms can use this mechanism. However, declarative services provide a better solution today, extension point are an Eclipse 2.0 legacy.

The Corona core plans a distributed computing environment. We have been discussing distributed versions of the OSGi Framework for beginning. The OSGi service registry is a mouth-watering abstraction for a distributed architecture. The dynamic nature of distributed systems is a perfect match for the service registry. The reflective capabilities of the services make it straightforward to map services from one platform to another platform. This mechanism does not work for all services because the calls of some services are not serializable, however, many specially designed services can work fine.

Overall the Corona project looks like a great opportunity for the OSGi Service Platform to obtain distributed capabilities. However, the project is described as having a very high number of dependencies on large subsystems. The complicated part of this project is to keep the corona core as small and independent as possible.  It will be tempting to bind the core to all kinds of subsystems but this will make the system overly complex and less useful for other applications.

The current success of the OSGi specifications is the fact that we kept things simple and as uncoupled as possible. Now we are maturing and more and more people are building the whole construction is becoming more complex, this is true for all evolution. When I was first using Java in 1995 I told the software veteran Ralph Johnson that I liked Java over Smalltalk because it was so small, he sighed, and told me to wait and see … A wise man.
We took a great deal of effort with the OSGi Service Platform to allow systems to be build from small components. The OSGi service model was designed from ground up to beat the coupling problem that is so pervasive and pestering in larger object oriented systems. The Corona project is going to be a very interesting test case to see if it is possible to develop a set of independent components or just a new blob.

     Peter Kriens
     OSGi Evangelist