All the small things

The ones of you who know me, know that I believe in software reuse and I am trying to evangelize about it for quiet some time. Methods, Classes, Aspects, Components, Modules, Software Product Lines, you name it – everything is focused on reuse to some extend. With OSGi for the first time we are able to create true reusable software artifacts and theoretically mix and match them on an as needed basis. Great new opportunities are coming and with the recently held OSGi Tool Summit chances are good that we’ll soon see more and better integrated tooling support in our daily work with OSGi. So, we all should be happy bees right?

Well, what we are producing right now is a massive amount of bundles, no question about this. Virtually everyone is now shipping with at least some basic OSGi headers. Several projects are trying to provide bundle repositories for the not (yet) converted projects (like [spring-repo], [orbit-repo], [osgi-repo]) and some go even further and try to wrap incompatible APIs in a compatibility layer (see [DynamicJava] for instance). Great work and very much appreciated, but this is not the point. What we got so far are “just” explicit software artifacts. We only know what is behind bundle X in version Y, a subjectively taken SNAPSHOT somewhere in the infinity of time. It doesn’t answer the question on how this code can and will evolve or how future versions will fit into my universe.

The problem domain

Too abstract? Let’s examine an arbitrary example. Assuming you are trying to create a web application similar to flickr but on some sort of an embedded device to use at home. Taking the state of the art tools, you might choose to develop your app with Spring DM or any other frameworks you like, take your pick. For now, we stick to this one. As a starter we use the following assets: Spring DM 1.1.3, Spring 2.5.6 and Maven 2 as a built system. So far so good. Once you start developing you realize that you also need a file upload feature for your pictures. Of course someone already developed something to upload files and we are trying to reuse that stuff of course, so you look around. Soon, you’ll find commons-fileupload. The spring guys are putting a lot of work into building up a repository of reusable osgi bundles in their bundle repository and we can just use the OSGi-ified version of it from here: [spring comFileUpload], which is really great! But then you soon realize that you can’t use that version. Take a look at it’s (simplified) header:

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Apache Commons File Upload
Bundle-Version: 1.2.0
Bundle-SymbolicName: com.springsource.org.apache.commons.fileupload
Bundle-Vendor: SpringSource
Export-Package: org.apache.commons.fileupload;version="1.2.0";
  uses:="javax.servlet.http",
 org.apache.commons.fileupload.disk;version="1.2.0";
  uses:="org.apache.commons.fileupload",
 org.apache.commons.fileupload.portlet;version="1.2.0";
  uses:="javax.portlet,org.apache.commons.fileupload",
 org.apache.commons.fileupload.servlet;version="1.2.0";
  uses:="javax.servlet,javax.servlet.http,org.apache.commons.fileupload",
 org.apache.commons.fileupload.util;version="1.2.0"
Import-Package: javax.servlet;version="[2.5.0, 3.0.0)",
 javax.servlet.http;version="[2.5.0, 3.0.0)",
 javax.portlet;version="[1.0.0, 2.0.0)";resolution:=optional,
 org.apache.commons.i;version="[1.4.0, 2.0.0)",
 
 org.apache.commons.io.outpu;version="[1.4.0, 2.0.0)"

As you can see, it requires to have the Servlet API in version 2.5, which is not available in our case on the embedded device. What now? Well, if you know the bundle, you also know, that in fact it doesn’t require 2.5! You can re-bundle it and give the bundle another version and here is the problem. The Spring guys did a great work bundling this artifact for us, but they created it based on THEIR environment and not on the minimal requirements of that specific bundle. Even worse, there is not even a real specification stating what version to take and how to version changes correctly. Forward compatibility is just a beautiful dream rather than an actual fact. If you look at well known companies adapting OSGi like LinkedIn, you’ll see what I mean. Where are we heading to when one is forced to define dependencies like this:

Import-Package:
 com.linkedin.colorado.helloworld.api;version=”[1.0.0,1.0.1)”,
��,
 com.linkedin.colorado.helloworld.cl;version=”[1.0.0,1.0.1)”,
.1)”,
 org.osgi.f;version=”[1.4.0,1.4.1)”

Doesn’t this feel totally odd and just plain wrong? Shouldn’t we be able to trust the authors or “something else” to take care of compatibility issues? Someone who knows the code, its changes and its backwards compatibility better than we do? I don’t want to change all of my 200 bundles just because we have a new OSGi framework version that now provides a new final static property for instance, I am not using anyway! I want to express that I don’t care what changed in the provided bundle as long as my code still works as expected and I want to be sure that the provider has the exact same concept about “compatible code changes”.  The Eclipse community already realized this and created an API for baselining components and a version schema to apply versions. Along with several detailed instructions on what to consider a change and how this change should be treated in terms of its version (eclipse-vers1, eclipse-vers2, eclipse-vers3), they have created the first usable guide on defining version numbers for bundles. However, this is just a small step towards reusable artifacts. We also need to agree on such rules and be able to enforce them. Unfortunately a lot of questions remain unanswered yet. For instance, what about semantical changes? How to treat them and more importantly, how to identify those? Code analysis won’t always help here.

So what do we learn from this? Basically that we can’t trust any bundle provided by a third party just yet. It doesn’t matter how good the providers intentions are on providing the perfect bundle. Right now, we are basically left alone. Every time we update to a new version it is like a game. You never know what you’ll be facing.

Ok, we are screwed. Who to blame?

Now you might ask yourself who’s fault is it? It is certainly not the Spring guys fault who provide us in this example with the software, but who to blame instead? The tools? Most people either use BND, Eclipse or the newly created bundlor from Spring. All of these are pretty dumb. They can’t possibly know, which version to take (although they are trying hard to guess). There is no baseline, no knowledge about the domain or infrastructure). Too many questions are unanswered and the tool authors are left alone, so I think the tools are the last ones to blame. OK, so what about the OSGi specification? It is so vaguely written, when it comes to versioning your bundles – you can’t possibly draw any universal conclusion what version to apply. Everyone can have their own interpretation of “compatible” changes, which is not compatible among each other. All true, but I don’t think that a simple specification will be enough nor is the OSGi suitable for that. The issue is too big to be solved by only one company or organization all by themselves. Sun might be the only one fitting, but after all the problems with JSR 277 and project JigSaw, I have no convidence in their ability and willingness anymore. To be fair, one have to admit that the Java Language Specification does provide a chapter about binary compatibility, but it is not much of a help, because not all cases are covered and there is of course no notion of a bundle (I would love to rant about not treating packages as 1st class citizen in Java, but that’s an entirely different post). Sun also has a sigtest tool to check for API breaks, but with the given functionality it is pretty much worthless for what we need.

What next?

Is it the job of an external organization to define rules everyone has to apply while developing reusable artifacts for a specific language? I don’t think so. I think this should be the job of all of us. Maybe as a joint project, maybe umbrella’d by the JCP, I don’t no, but definitely as a open and community driven effort. I don’t wonna lock myself to any vendor or proprietary standard I might get stuck with. I dream of a central repository (maybe based on RFP 122, maybe something completely different), where I have a one stop shop for all the 3rd party artifacts I need. At the same time being able to do in-house development with the same reliable system not having to expose anything to the outside world. Open, reliable and trustworthy software with a healthy community of open source artifacts – does it have to be a dream or can we make it real? I already have ideas how this can come true, but I would be very much interested if you’re feeling the same or even having concrete projects concerning something similar I haven’t reference here? Is there a potential for collaboration? What do you think?

My 2 cents,
Mirko

References (in chronological order):

[OSGi]: http://www.osgi.org/
[OSGi Tool Summit]: http://www.osgi.org/Event/20090327/
[spring-repo]: http://www.springsource.com/repository/app/
[orbit-repo]: http://www.eclipse.org/orbit/
[osgi-repo]: http://www.osgi.org/Repository/HomePage/
[DynamicJava]: http://www.dynamicjava.org/projects/jsr-api/
[Flickr]: http://www.flickr.com/
[Spring DM 1.1.3]: http://www.springsource.org/osgi/
[Spring 2.5.6]: http://www.springsource.org/download/
[Maven 2]: http://maven.apache.org/download.html
[commons-fileupload]: http://commons.apache.org/fileupload/
[spring comFileUpload]: http://www.springsource.com/repository/app/bundle/version/detail?name=com.springsource.org.apache.commons.fileupload&version=1.2.0
[Servlet API]: http://java.sun.com/products/servlet/
[LinkedIn]: http://blog.linkedin.com/2009/02/17/osgi-at-linkedin-bundle-repositories/
[baselining]: http://www.ibm.com/developerworks/opensource/library/os-eclipse-api-tools/index.html
[version schema]: http://wiki.eclipse.org/Version_Numbering
[eclipse-vers1]: http://wiki.eclipse.org/Evolving_Java-based_APIs
[eclipse-vers2]: http://wiki.eclipse.org/Evolving_Java-based_APIs_2
[eclipse-vers3]: http://wiki.eclipse.org/Evolving_Java-based_APIs_3
[BND]: http://www.aqute.biz/Code/Bnd/
[eclipse]: http://www.eclipse.org/
[bundlor]: http://www.springsource.org/bundlor/
[JSR 277]: http://jcp.org/en/jsr/detail?id=277
[jigsaw]: http://osgi.mjahn.net/2008/12/04/componentization-wars-part-ii-guerrilla-tactics/
[Java Language Specification]: http://java.sun.com/docs/books/jls/third_edition/html/j3TOC.html
[binary compatibility]: http://java.sun.com/docs/books/jls/third_edition/html/binaryComp.html
[sigtest tool]: https://sigtest.dev.java.net/
[RFP 122]: http://www.tensegrity.hellblazer.com/2009/03/osgi-rfp-122—the-osgi-bundle-repository.html

It feels like recently extenders became extremely fashionable among the OSGi community. Eclipse is using an extender like pattern to track their plugin.xml configurations and Spring DM introduced the plain osgi extender together with a special web extender. It seems like everyone has one lately, but what is all the buzz about and how should or could you use one – and even more important, when should you use one. As always in software development there is no clear black and white answer to this, but this blog post at least tries to shade some light on this topic to help you making the right decisions.

The buzz, what is it about?

Before the extender hit the light, people were advertising the white board pattern as THE OSGi way of doing things. A way of inverting control, taking the burden of house keeping from the consumer like it is required with the well known listeners. On the OSGi website you can even find a good paper on “why listeners are considered harmful“. Well, things change or better progress and with the extender another problem got addressed. The inconvenient with the white board pattern is that the client still has to take care of some stuff ending up in boilerplate code. Here is where the extender has its strengths. The core idea is to have a designated bundle that scans all already deployed bundles as well as all bundles that are being deployed during runtime for specific features, properties, interfaces, annotations, what ever you want in order to take appropriate actions on behave of this bundle. These actions can be something simple as registering a service for every implementation of a certain interface or as complex as doing some xml transformations of configuration files that will be loaded in your system triggering a whole cascade of events. The key point is that it is completely up to the extender what to do and how during deploy time.

Imagine you have your application extensively using the white board pattern without an extender. All “consumers” of your service have to publish a specific service in the registry in order to get recognized. You have to exactly specify what the signature of this service has to be. This can be any number of interfaces or just properties you register along with the service. All this is just fine, but when it comes to changes of your approach you have to let all you’re clients know about the changes and wait till they have adapted/ migrated or provide a runtime compatibility layer that checks for the old and the new syntax. With the extender, you can still use the white board pattern, but this time you take care of registering the service. Now, everything is defined in your extender, which interfaces are important, what properties to add. As soon as it comes to a change in your design, chances are good that you can just adapt the extender in order to register the client services with new properties, use different interfaces (if possible of course) or even use something advanced as a generic proxy that wraps around the old interface and registers itself with the new API. You can now intercept service calls, if you like or need and transform the transfered data as you please. But the best thing about it, despite the mentioned is that all this happens during deploy time of the bundle so it just happens once without the need for your clients to touch any of their code. This makes the interfaces between service providers and consumers more solid and less likely to break.

Pros and Cons – abridge

Of course, there is no such thing as free lunch. The extender also has its limitations, you should well be aware of. Here is a short list with the compiled pros and cons. Of course, depending on the scenario you might find more to either ones. If you think I forgot something important or don’t agree, don’t hesitate to comment. Constructive feedback is always appreciated.

disadvantages:

- One of the first things that pops into ones mind is the problem of disabling the extender for a specific bundle. This might be interesting, because you don’t want to start/enable all bundles at start-up or just don’t want to provide all the functionality at once (f.i. to increase start-up speed). There are ways, like white/ black listing bundles, lazy activation triggered by properties or manual selection based user input. Although all this is possible, it is somewhat against the idea of the extender, which is automatically processing and removing repetitive tasks.
- The second difficulty is the customization. Of course you can define a specific format that enables you to customize the way your extender works and what it does, but there are scenarios where you can’t upfront decide what to do. A common way to work around this is defining your own DSL describing your “intent” in an abstract way, like in your own DSL. However, this introduces another layer of complexity and can make your application/design even more complex – depending on your scenario of course. This is not a problem of the extender, but a general problem one usually faces when working in OSGi. Everything is intended to be generic, but at some point you have to be specific on what you actually wonna do. So, I guess it is not a real drawback, but something to consider.
- Last but not least every automatic mechanism requires awareness of developers. Everyone using your bundles should be aware that something is happening behind the curtains. Otherwise chances are high the mechanism will be circumvented or miss used. Again, I think this holds true for many mechanism or patterns, but is well worth mentioning here.

advantages (assuming done right):

- First of all an extender means less burden for the developer. The overall goal is to remove boilerplate code, typical copy & paste use cases and deterministic, error prone tasks. For most developers this is not only boring, but also a major pain point when fixing a bug or misconfiguration. By eliminating or at least minimizing such repeating tasks, you’re doing the average Joe and ultimately yourself a big favor.
- You might have guessed it. Eliminating c&p from your code base also makes your application more robust to changes. I mentioned that already above, but just let me emphasize that the ability to express the intend, rather then the actual how is one of the greatest advantages.
- Inversion of Control. Yes, I know it is a buzz word and it is usually used grasp attention, but here it really makes sense. Like the whiteboard pattern one does remove the burden of the consumer. What kind of burden this is, depends on the extender. In many cases it will be registering the services the right way, indicating a specific functionality or setting a configuration. The beauty about this is similar to the white board pattern. Less burden for the “extendee” (the one being extended by an extender) and a centralized management logic, which can be updated, improved by the “extender”. I think it is important to note here that the extender can provide or consume, depending on your design, unlike the white board pattern.
- Of course, one advantage generates others like less source code for instance. Unless you’re getting paid by lines of code you’re producing (just a joke -I honestly hope no one is evaluated on that one!), having a smaller code base is always a good thing. Other advantages would be less complex extendee bundles or simpler adaption to new requirements.

Conclusion and outlook

As you could see, extenders are the next evolutional step in the OSGi world. There are great new ways of designing your applications that can make your application even more robust and simpler to use. However, there also comes the responsibility to use the technology wisely and not just for the sake of it. As seen with Eclipse and now Spring, more and more advanced extender concepts are popping up and we certainly haven’t seen everything possible yet. In a future blog post, I am going to look deeper in how to create an actual extender, what to keep in mind, how the up-coming OSGi R4.2 spec will help us here, what kind of extenders are there already and of course common pitfalls one may face implementing your own. Stay tuned and have fun experimenting with extenders.

Cheers
Mirko

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

–

[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

I was actually planing on writing something about this topic for months now, but I never found time to do so. Now that Peter Kriens picked up the topic in his current post [1], I just felt the need to write about my thoughts on this issue.

What is it all about?

When working on computer programs for a while, you pretty soon realize that you don’t want to invent the wheel all over again. So, people came up with concepts driving software reuse further and further. Starting from functional programming, finding its way to the fine world of objects and in our days driving more and more towards component based programming. Nothing surprising – though. With the help of OSGi I’d like to say Java has a pretty good standing among its competitors and could already be considered component ready.

However, there is one problem, at least as far as I am concerned. Looking at software product lines (I know, I know, they are more considered a fancy dream than a real world solution, but please hang in there for a moment and let me explain) the core concept – as I would call it – is the idea of divide and conquer. In a complex domain as computer science, it is not feasible to believe one can manage everything down to the finest granularity. So what you end up doing is creating the big picture and drill down on a “as needed” basis – a typical top down approach. Of course, this assumes you already have your main building blocks to work with. OSGi by its nature in general supports you in doing so. You only pick your functionality in terms of simple bundles and throw them into an OSGi container and everything just works – well, almost.

Unfortunately, that’s just the simplest scenario when things like this are working. Peter is saying in his blog that applications (bundles belonging to one domain and providing a certain functionality with their collective interaction, as I would define it) are simple to manage, because they express their dependencies. Tools like the OBR[2] make installation issues disappear and all the remaining requirements for an “application” concept to solve their problems are actually derived f.i. from the use of Class.forName() in legacy code to extend their applications and the sharing of implementation classes rather than interfaces. Here I have to disagree. Of course, the whole Class.forName() ideology is a problem within OSGi, but I don’t think this is the major reason for the demand for an application model.

Why is the concept of an application worth while?

Let’s assume you’re building a pretty complex application with … 400+ different bundles or so. Referring to software product line design you’re no longer managing all of these bundles, but you’re managing some sort of an application stack. If your interested in (see figure 1) creating a new application with “Domain Logic 1″ and “Domain Logic 3″, you just pick those and all the underlying plumbing should be taken as well. Of course (and here it becomes tricky) this involves loose coupling, which doesn’t include dependencies on a specific implementation or even worse implementer on the domain logic stack. Everything is abstracted from the implementation and everything just depends on interfaces and services.

One of my core problem here is that there is no distinct bundle representing an application. There is no syntax, convention, anything. I need to know which bundle in the application is my “core” (and I am not even talking about finding out, what my applications are, I can choose from). Having figured out which one to use, we are still not in a safe harbor. The problem continues with the separation of API and implementation. Ones both are separated by design (as shown in figure 2), I can happily resolve all my bundles, but nothing works, when solely relying on Package-Import statement scoping (which I – again! – highly recommend). Automatic tools dependency discovery tools just can’t find a path to the implementation. In figure 2 you can see the problem show by the arrow. Starting from the “Core Bundle”, I only have a dependency on the API. The API doesn’t have any dependency on the implementation. The Implementation bundle does have a dependency on the API, but for the dependency resolution tool, it is not clear, if the bundle is just using the API or implementing it.

As you now see, there is a certain problem and I wasn’t actually surprised when I heard about Springs approach to this problem. Although Springs way is a fast solution for the immanent problem, it introduces dependencies one might not want. Bundling components together in the Spring way ties the interface to the implementation, limiting the flexibility of the whole design.

So, basically we are doomed, right?

Well, the question is, what do we REALLY need. As I mentioned before, in my opinion, it is a set of just a few features:

1. an application identifier (this is great to figure out what functionality I actually have)
2. a way to express simple dependencies (with Import-Package, I think we pretty much have that)
3. some way to express dependencies on our environment, like the existence of a certain service implementation.

Looking closely at the core spec, we can actually find almost everything we need. Unfortunately, we can’t use this right away. Feature number one for instance can very easily be achieved by just introducing a new property in the Manifest.mf file – even a version can be introduced, although I am not sure this is a good idea yet.

The tricky part comes with feature number 3. Looking at the latest official OSGi core spec version 4.1, there is no meta data concept reflecting services*. Fortunately, there are still the old specs available for download [3] and here we can find in version 3 the “Export-Service” and “Import-Service” headers removed from the current specification. Assuming all bundles are correctly tagged with the right meta data, tools like the OBR can easily create a dependency tree and figure out which bundles to pick. Even better, such tools are now able to pick the best implementation based on their other dependencies and potential version conflicts on the imports of each implementation bundle. I think such a dynamic solution is way better fitting the OSGi way of doing things than any static one.

Ok, I know R3 is so “old school” and we are living in a brave new world. Swimming back is not an option in a buzz, hype and in general fast pace driven world. Fortunately, we don’t have to. With Spring DM [4], there is a way to express dependencies on services in a declarative way. Here you can define which services you are consuming and which ones you are providing, thus giving 3rd party tools the ability to analyze the dependencies way more subtle. If the Spring DM approach is used widely – as a new “official” standard, tools like OBR can now work again. They are able to assemble the right product configuration and deploy a runnable application based on the additional meta data from the Spring DM configuration. The only drawback so far, only if everyone is using this configuration, we will get the best results. If partially used, the results may not be providing any significant improvement based on the very bundle constellation.

Something I intentionally left out till now is the new idea of providing nested frameworks. I haven’t thought that entirely through though, I have to admit. In general I like the idea, but for other reasons. The main reason, why I don’t like it for this particular problem of the lack of the notion of applications is that when looking at figure 1, you might end up with several layers of applications, which would then ultimately end-up in requiring multiple layer nesting of frameworks. And speaking about complexity I am not sure, if a framework in a framework in a framework in a …. makes life so much easier. Besides, this still doesn’t solve the problem with discovering the necessary dependencies for an application – not counting manually configuration of such a sub framework of course.

Conclusion

For me there is a clear need for an application like notion in OSGi. As shown above, there are valid use cases even now, which make the use of OSGi kind of limited in the long run. However, I actually don’t see the need for an entirely new concept, above or beyond a bundle. The only thing we really need is a clear statement, how to provide and obtain the required information to do the described extended dependency analysis. With these information at hand, tools by 3rd parties can be developed and make us all equally happy. At the end, we should keep in mind that OSGi is (currently) about defining a component standard, which should be open and not enforcing any lock in. This is in contrast to most of the adapters wishes of having a simple technology, solving their immanent problems. I think, now there is time for great tools to support working with OSGi more easily, helping developer to adapt and embrase the functionality and freedom offered by OSGi.

Cheers,
Mirko

*) actually I was cheating a little bit here. OSGi R4 compendium contains the Declarative Service (DS) definition, which in fact defines valuable meta data. The reason, why I didn’t mention it here is basically related to the fact that Spring DM is superior to DS in many ways and DS is not part of the core specification, so I favored Spring DM for the sake of functionality.
–

[1] OSGi Blog: http://www.osgi.org/blog/2008/07/osgi-application-grouping.html
[2] OBR: www.osgi.org/Repository
[3] OSGi Spec Download Site: http://www.osgi.org/Specifications/HomePage
[4] Spring DM: http://www.springframework.org/osgi

At the beginning of this month[1], SpringSource published the first beta release of their so called SpringSource Application Platform[2], an (as I would call it) extension of the existing OSGi platform. The move came pretty surprising to me, I have to admit. No announcements prior to the release, no actual hints – nothing. Pretty impressive I have to admit. A company grown that popular being able to work on something from this magnitude without even seeding the glimpse of a rumor. Good job.

Well, I guess eventually the guys behind Spring are trying to make money. A very natural thing for a company, of course. After having provided the community with a great framework for so many “supposed to be” JEE applications for free, it is time to gain some revenue. I think they deserve it after all they have done for the community. Actually I find it in particular interesting how the strategic move, choosing GPL[3] as the license of choice, will work out. On the one hand, I can totally understand the point of view, choosing a license, which forces competitors to play with open cards and actually contribute to the community. On the other hand, I have to say, I am thinking twice before putting me in the hassle of dealing with a viral license. For instance, when I lately was involved in the decision between LOGBack[4] and Log4j[5] as a logging back end, the decision was not only based on features, but mostly licenses. In some scenarios, licenses are just a show stopper, so I honestly hope this will not be the case for my fellow colleagues from SpringSource.

Enough philosophizing… Spring released a very interesting extension to the existing OSGi specification. Summarizing all the new features they provide would certainly go beyond the scope of this blog, besides I am by far not as knowledgeable as the developers themselves, so I will just refer to their great introductions [6],[7] and [8]. Instead I want to point out some things I consider worth mentioning.

First of all, the repository[9] is just great. With the experiences I’ve made by migrating existing applications into modular, OSGi based bundles, I can tell this can be pretty time consuming and frustrating, if done accurately (not just adding some headers to the manifest.mf, but also changing the existing code to work within OSGi where necessary).

The second thing I’d like to mention is two sided… On the one side, OSGi is missing another abstraction layer, I think. Defining full functional, domain modules to help people jump start in OSGi is needed – no getting lost in dozens of bundles, versions and services. I think all of you, working with OSGi for a while, have been faced with the problem, where you resolved and started every bundle appropriately, but your program will just not work, because you forgot to deploy the actual implementation of a service. Knowing your system, it won’t be a big thing finding the problem, but in a unfamiliar application with hundreds of bundles deployed and more potentially ready to be deployed from a repository, just waiting to be picked… which one is the one to choose? An abstraction – bundling those, as Spring has done it with its PAR – might help.

But, there is also another side to this story. Maybe all we need is some sort of indicator, a meta data to indicate, that a specific bundle provides/ consumes a distinct service? This will remove the provider lock-in problem caused by solutions like “Require-Bundle” for instance. All we actually need is a (in some way) abstract concept of a working entity (or application or domain module as you might prefer calling it), which is more abstract than usual bundles. This can just be the aggregation of certain packages and service consumers as well as providers. Only APIs, no actual implementation dependencies and for sure no Bundle-SymbolicName dependencies. An ideal application now would only consist of a couple of domain modules, which have to be deployed in the OSGi container. The container (with the help of the repository) now just picks the required bundles and assembles the application. No need to define a specific vendor, everything will be resolved by the framework. That would be my dream…

Anyway, I think this is something, which should be discussed in more detail in official sources. The approach Spring choose is certainly a way to go and test drive, but honestly, I doubt that it’ll turn out to be the right fit in the long run. All solutions I can think of, which were created to solve a certain pain are a serious burden and actual blocker in the long run, like Eclipse Buddy Class Loading, the OSGi Require-Bundle* header or the (unlimited) backwards compatibility required by the jar specification.

The last thing to mention is the introduction of the new headers. In general, I am all in favor of doing so and I am not surprised about the chosen names. Of course, they might clash with later headers, potentially introduced by the OSGi Consortium, but this is nothing new in Java. If you take a look around, developers as it seams, consider the reverse domain nomenclature as a burden and just ignore it. Even if it is now better established on a package level (although there are still rather well known exceptions like the IAIK[10] or even Peter Kriens FileInstall[11] bundle for instance). On a Manifest level however most of us (including myself) can pledge guilty of silently ignoring Java best practices. Unfortunately the magnitude of such a decision hunts you down later. The recent discussion about the name space issues of the OSGi headers, was the perfect reminder for me to give these small things more thorough thought, as we usually tend to liberately ignore them most of the time in favor of fast development. Well, at least I pledge betterment and hopefully so does every responsible developer, too

Cheers,
Mirko

*) Sorry, but I just can’t help it. In my opinion this header is not only a hurdle, but a real drawback from a componentization point of view. From a migration strategy approach, I guess the opposite applies, but what lasts longer – migration or maintenance?

–

[1] http://www.springsource.com/web/guest/2008/applicationservermarket
[2] http://www.springsource.com/web/guest/products/suite/applicationplatform
[3] http://www.gnu.org/licenses/gpl.html
[4] http://logback.qos.ch
[5] http://logging.apache.org/log4j
[6] http://underlap.blogspot.com/2008/04/springsource-application-platform-ships.html
[7] http://blog.springsource.com/main/2008/04/30/introducing-the-springsource-
application-platform
[8] http://blog.springsource.com/main/2008/05/01/completing-the-picture-spring-
osgi-and-the-springsource-application-platform
[9] http://www.springsource.com/repository
[10] http://jce.iaik.tugraz.at
[11] http://www.aqute.biz/Code/FileInstall