Wow! If you want to see what is happening with OSGi technology, you should have visited the EclipseCon 2006 conference in Santa Clara! OSGi is mentioned in an awful lot of presentations! There are so many people excited about what you can do with OSGi that it was heartwarming. Despite the fact that the OSGi is only the plumbing of Eclipse, many people realize that the OSGi component model is applicable in a wide range of applications. For many, it is a genuine discovery when they realize that the IDE plug-in model can also be used on a tiny embedded device like the Slug (which was very nicely demonstrated by Thomas Watson) or on the server side, which was discussed in Corona Project from Compuware, Wolfgang Gehner with his RSP proposal, and many others. An impressive number of people want to start deploying OSGi applications that (partly) replace J2EE application servers. More about that later.
On Monday Thomas Watson and I gave a tutorial about OSGi Component Programming. This went very well (though we could only finish half of our 100 slides). The feedback we got during the rest of the conference was nice; people loved the modularity and especially the service model. This was a bit of a surprise to me; I had not realized that most people know about the OSGi modularity layer but know little about the service layer. The service model is new for many people because Eclipse mainly uses extension points where the OSGi model uses services.
The difference between extension points is subtle, though important. An extension point allows a bundle to find, and work with, implementers of its own extension points. That is, the bundle owns the extension point contract and allows other to implement it. A service is more generic because it provides an interaction point between any number of bundles; there is no bundle that owns the service, any bundle can both register (implement) and get (use) a service. This distinction nicely reflects the perspective of Eclipse community and the OSGi Alliance. Extension points allow an implementation to find implementers. For example the Eclipse UI code uses extension points to find its menu entries in different plug-ins. The extension point model is not intended for another bundle to find these menu entries. In contrast, OSGi services are usable by any bundle that has the proper permissions. The OSGi model allows substitutability of the user of a service as well as the implementer of a service. There are some more differences like dynamics, versioning (extension points mandate only a single version resident at any moment in time), and life cycle, but the ownership of the contract is the most crucial.
Anyway, lots of people are using extension points that would have been nicer (ok, in my biased opinion) with services. This difference/overlap, and when to use one or the other was a big part of the talk by Jeff McAffer and BJ Hargrave. They did a joint presentation that did an excellent job of highlighting the similarities and differences. The format of 2 very knowledgeable guys taking their turns explaining the differences worked very well. There were an impressive number of people ready to listen to the Best Practices of OSGi and Eclipse.
So what is the number one aspect that signifies this conference to me? I think that it has become clear to me why there is a need for an OSGi Alliance. There is an impressive amount of projects underway. However, all these projects are about implementations. The people you meet here are very interested in collaborating on developing implementations. This approach is orthogonal to specifying service interfaces so that different implementations can collaborate. There is a clear distinction between an extension point that is unilaterally decided by a programmer and a service that is defined by a standards body or consortium. Using well specified service interfaces will allow commercial companies to compete with Eclipse, or other, implementations; something that the Eclipse community, commercial companies, other communities like Apache, but most of all the users can benefit from in the long run. Will the different communities have the patience and motivation to go through standardization processes?
The answer to this question is opportune for what will happen on the server side. The Eclipse model has made many people realize how well the component model works and they want the same benefits for the server side. There are a large number of initiatives to standardize Eclipse for the server. However, the danger is that different parties create implementations without proper regard for how all these different parts could interact. Obviously many implementations will work but properly designing a component architecture for Enterprise applications will enable substitutability, a very desirable property in my opinion. Maybe organizing a workshop about Enterprise Component Architecture could be held. Some key people in the industry could to outline such a component architecture. Good idea?
Peter Kriens
No comments:
Post a Comment