Mirko Jahn

Subscribe to Mirko Jahn: eMailAlertsEmail Alerts
Get Mirko Jahn: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Blog Feed Post

Some thought on the OSGi R4.2 early draft

Last week the OSGi website[1] published the early draft of the OSGi R4.2 specification[2]. Reason enough to have a short look at what is covered in the upcoming release.

First of all one has to notice that this is not a minor release as the version number may suggest. Release 4.2 is actually way more significant than the R4.1 release last year. At some points I would even say it is more important than the R4 release, because with that one usage becomes way more easier, especially for none OSGi experts. But first things first. What is actually in the new draft?

Core design changes/ enhancements:
RFC 120 - Security Enhancements
RFC 121 - Bundle Tracker
RFC 125 - Bundle License
RFC 126 - Service Registry Hooks
RFC 128 - Accessing Exit Values from Applications
RFC 129 - Initial Provisioning Update
RFC 132 - Command Line Interface and Launching
RFC 134 - Declarative Services Update

Enterprise design changes:
RFC 98   - Transactions in OSGi
RFC 119 - Distributed OSGi
RFC 124 - A Component Model for OSGi

Covering all of these RFCs in this post won’t be possible, but I want to pick some of them and go a little bit into the details.

RFC 120 - Security Enhancements (P. 5)
The major change here is the introduction of the concept of a black list. Now, you are able to say something like everyone is allowed to do such and such, unless… and here comes the clause. Before, only white lists were possible. Although, this is a tremendous improvements in terms of simplicity, there is a reason why black lists are not as secure as white lists and why certain systems don’t implement black list approaches. I think this feature should be treated with extreme caution and I hope this won’t hunt back the OSGi, when security flaws based on this are surfacing, which will most certainly will.

RFC 125 - Bundle License (P. 62)
Licenses are always a problem in Software development. Especially when a lot of 3rd party libraries are involved. The OSGi now addresses these issues by defining a header for the manifest, which conforms to a distinct syntax, which subsequently allows vendors to not only express the kind of license a certain bundle is published, but also which portion of the code is associated with what license within a bundle. In my opinion, this is a really cool feature. Conceptually certainly not rocket science, but the benefits are many folded. Now, it is possible to display, which licenses are actually contained in your container and even more important, you can define rules for certain Licenses not being deployed in your environment. I am just thinking on the typical viral problem of GPL[3] like licenses.

RFC 126 - Service Registry Hooks (P. 71)
This is going to be a mechanism, mainly used for framework related services and not applications in general. The idea is to allow hooks, to tweak the service registry behavior. One very likely use case are remote services, as discussed for quite a while in the OSGi community. Although very useful and powerful, I can see the problem that you get indirect dependencies with this one and eventually have similar problems like with plain java jar files. A bundle doesn’t express which tweaked service manipulation it needs (similar to the “which jar also needs to be at what pssition in your class path” problem). Of course, this is not the aim of the spec, but as soon as it is possible, people start using it, even if it is not intended by the designers. Fragments are the most famous example for this pattern.

RFC 129 - Initial Provisioning Update (P. 97)
The initial provisioning specification as published in the R4.1 spec has a major drawback. It assumes, that the created jar can be manipulated in terms of setting properties to the zipped content (information about the MIME type). Although, this can easily be done in Java, all major build tools I know of are lacking this feature, so custom implementations had to be used instead. A reason, why I once chose not to go with this solution. This is now addressed in the RFC. A very useful update, if you ask me.

RFC 132 - Command Line Interface and Launching (P. 103)
Till now, all OSGi implementations differed in the way they were started and one could extend the console. This will change with this new RFC. For me this is the right direction. We really need clear interfaces to instrument the container, so that exchanging the container becomes easier. Of course, every framework provider will still have it’s own “enhanced” features, which is a good thing, but you easier avoid the typical lock in. This should boost transparency between frameworks.

RFC 134 - Declarative Services Update (P. 144)
I haven’t looked very close into that, because Spring (as well as iPOJO[4] or SAT[5]) are way superior and wider used than DS, but in general, the reliability of obtaining a service was increased. Some oddities have also been removed/solved.

RFC 98 - Transactions in OSGi (P. 154)
Transaction are being introduced to provide a true ACID level support. For this the JTA is going to be used. Additionally the Distributed Transaction Processing (XA+ Specification Version 2, The Open Group, ISBN: 1-85912-046-6) protocol will be used, which is specifically tailored to meet OSGi’s needs. I haven’t dug really deep into this, but I hope with this RFC the issues user have reported with libraries like Hibernate will finally be solved. An issue popping up quite often.

RFC 119 - Distributed OSGi (P. 169)
The goal should be clear, but here is a citation taken from the spec:

  • An OSGi bundle deployed in a JVM to invoke a service in another JVM, potentially on a remote computer accessed via a network protocol
  • An OSGi bundle deployed in a JVM to invoke a service (or object, procedure, etc.) in another address space, potentially on a remote computer, in a non OSGi environment )
  • An OSGi service deployed in another JVM, potentially on a remote computer, to find and access afrom remote OSGi bundle service running in the “local” OSGi JVM (i.e. an OSGi deployment can accept service invocations
  • A program deployed in a non OSGi environment to find and access a service running in the “local” OSGi JVM (i.e. an OSGi deployment can accept service invocations from external environments)

[OSGi Spec R4.2 early draft (P.174) - August 22th, 2008]

I really like the idea of being able to use services from other JVM and even other machines, without having to worry about how to implement this. A very compelling idea! Unfortunately I don’t believe in a flat world and so I don’t believe in such a simple solution. Network connections tend to have a latency, drop unexpected or even return corrupted data. If your service consumer is not agnostic of that, I think there will be more and more problems popping up. However, I am open for this and will watch the development closely. Eric Newcomer[6] gave a pretty impressive demo how this works at the OSGi Community Event[7], so I am looking forward to get my hands dirty. Call me idealistic, but I actually want this to work and prove me wrong!

RFC 124 - A Component Model for OSGi (P. 216)
The most important change however is described in RFC 124 in my opinion. Here, the former known Spring DM[8] approach is translated into an OSGi standard. After a first quick look, it seems like it is indeed the Spring DM specification OSGi’ified topped with some additional semantic sugar, but I have to look closer to be sure. The only question which remains for me is, if this RFC will really make it into the final spec, what will happen with DS? In my opinion, RFC 124 is way superior to DS and there are no good reasons to keep DS. If I am wrong, maybe someone can shed some light.

Conclusion
Besides the facts mentioned in the early draft, I find particular interesting, what actually didn’t made it into the early draft. For me the whole EE issue with the mapping of web.xml’s for instance is completely missing. The enterprise features are the things I was eager to read, but instead total silence. Hopefully they are still working on it. Releasing the next version of OSGi without the a convincing Java EE story is like driving a car with the handbreak on. Let’s hope the EEG will manage to finalize theirs EE story in time!

As I final note I want to say, that I think it is a great move from the OSGi alliance to actually grant early access to the things they are working on. This makes it way more transparent for the community, what is going on behind the closed doors of the specification process of the OSGi. Maybe in the furture, we’ll see an open way of interacting with the whole JSR process, so that even Sun will eventually be satisfied. Well, time will tell…

Cheers,
Mirko

References:

[1] OSGi Homepage: http://www.osgi.org/Main/HomePage
[2] OSGi R4.2 early draft: http://www.osgi.org/download/osgi-4.2-early-draft.pdf
[3] GPL License: http://www.opensource.org/licenses/gpl-3.0.html
[4] iPOJO: http://felix.apache.org/site/ipojo.html
[5] SAT: http://www.vanderleiindustries.com/sat/help/topic/org.eclipse.soda.sat.plugin.doc/books/book.html
[6] Eric Newcomer’s blog: http://blogs.iona.com/newcomer
[7] OSGi Community Event: http://www.osgi.org/CommunityEvent2008/HomePage
[8] Spring DM: http://www.springframework.org/osgi

Share/Save/Bookmark

Read the original blog entry...

More Stories By Mirko Jahn

Mirko Jahn worked for several years as an independent software consultant and tutor before joining the Unstructured Information Management Architecture (UIMA) group at IBM Research. At present, his major research areas cover component-based development strategies, component repositories, and migration approaches toward modular applications, along with service-oriented architecture. Mr. Jahn is heavily involved in making use of OSGi component-based developement
standards in UIMA.