Thursday, March 15, 2012

Requirements and Capabilities

Last night late I finally finished the final documents for Release 5. Brand new Core and Enterprise specifications will await you. Well, after the Expert Group members have voted (one week) and the board has approved it (not sure) and the lawyers have had it long enough on/in their desk (another 60 days). However, we will be able to show you a draft that is almost identical during OSGi Devcon/EclipseCon if all goes well. You will be there, aren't you?

So what is the most important thing in this release? For me it is clear that the OSGi Requirement-Capability model is the winner of this release.

Late 2005 Richard S. Hall and I wrote RFC 112 OSGi Bundle Repository (OBR). In this RFC we developed a generic model for dependencies. This work was driven by my frustration. Though the Java language uses static typing, almost every other software safety aspect is more or less left to the deployer. Running an application that happens to have a Java 7 class will crash somewhere in the future when that class gets executed. Code that requires a certain library happily churns along until that moment the library is accessed. Code written for a high resolution display happily churns along on a small display while looking awful. We seem to be fanatic about types but completely blind for other dependencies!

Our industry did not have a way to describe these myriad of dependencies so the solution was a proliferation of profiles. Instead of having 100 dependencies you only had one. Unfortunately, that single dependency aggregated a thousand dependencies, 900 of which you could not care less about. Oh yeah, and it lacked one dependency you actually really, really, required. Profiles are the siren song of software, they lure us with a simple solution that is surprisingly wrong.

A much better solution is to only depend on what you really depend on and assemble what you need when you need it. If you only use package com.foo, why should you depend on an aggregation foobar that also contains so many other things you have no use for and drags in the kitchen sink (excuse me for mixing metaphors)?

Unfortunately, this model is severely hindered by our human frailties. We humans much prefer foobar over 25 package names even if it hurts (others?)  in the long run. However, that is only an argument if you actually have to handle these packages. Since you're already having the package names in your classes, why not use computers to handle these details? Obviously bndtools and other bnd users like maven show how easy this can be. However, there are many other types of dependencies that until now we could not express in a computer readable way.

This is where OBR comes into the picture. Richard and I developed a language to express capabilities and requirements. Capabilities have attributes and a requirement is a filter on the capability's attributes.

  Cap: osgi.extender=foo.bar; vendor=ACME
  Req: (osgi.extender=foo.bar)


A requirement and a capability can only match when they are in the same namespace. The syntax for requirements and capabilities is fixed by the OSGi, however, the namespace defines the semantics, what it really means to provide such a capability.  OSGi has always been about describing dependencies, think Import-Package and Require-Bundle. All these dependencies have now their own namespace that define the attributes, directives, and the runtime class loading rules.

Capabilities and requirements are declared by a resource. The resource is the artifact that needs to be installed in an environment and then resolved. A resource is resolved if all its mandatory requirements are satisfied by some capability in the environment. This looks remarkably close to a bundle, and that is not a coincidence. However, resources can be anything, from a certificate to a piece of hardware.

The generic model is quite useful in a wide variety of scenarios. A good example is the extender model. An extender reads some content of an active bundle and uses the information to provide a function on top of that bundle. Blueprint, Declarative Services (DS), the Service Loader Mediator, etc. are all extenders. Though the model works extremely well it has one great disadvantage: there is no managed dependency between the extendee (e.g. the bundle using DS) and extender (e.g. the bundle implementing DS).

For example, installing a DS bundle without installing a DS extender results in a very soothing but rather undesired level of inactivity: nothing happens. With the Require-Capability model we now have the possibility to prevent this peaceful state with the extender namespace.  The contract is that the extendee (the bundle that uses DS) requires the osgi.component extender capability and that any implementation of DS provides the osgi.component extender capability. If the DS extendee is installed it cannot resolve until there is also a matching implementation of the DS bundle installed.

It gets even better. Each bundle becomes completely self-describing with the Requirement-Capability model. This enables the holy grail of automatic assembly of components (well, ok, almost). From a resource it is now possible to find the minimum set of transitive dependencies automatically, even taking local capabilities into account.  For me the greatest advantage of this model is that it voids the need for "applications". Any bundle can be an "application" since any dependencies can now automatically be included.

In Release 5 the OSGi added a completely generic API that is used by a Resolver service and a Repository service. The Resolver service provides access to an OSGi aware resolver that can take resources and find the closure of a set of resources. The Repository service provides access to local or external repositories. The Service Loader Mediator and the Subsystems specifications also rely heavily on the generic Requirement-Capability model.

If you're interested in this model, I was asked to do the OBR presentation from David Savage during our OSGi BOF (Tuesday, Reston Suites B 19.00). If that is not sufficient motivation then be aware that you can also win a free OSGi in Action, OSGi in Depth, or  Java Application Architecture  book during the BOF.

After OSGi DevCon/EclipseCon my work for the OSGi Alliance will be over.  This was my last release. Though there is a certain amount of sadness to leave it behind I am happy that the Requirement-Capability model made it in this release since it is for me the most innovative piece since services. Though I will not be active in the Alliance I am pretty sure that my future work will include the Requirement-Capability model. Check it out! (After the lawyers have finished reading it.)

Peter Kriens


P.S. Of course there is also the free OSGi Cloud Workshop on Thurs 09.00 to 13.00 where we are looking for input on the future activities for the OSGi Alliance to work on in this area.  Places are limited, and we are nearly full, so if you want to join us for this be sure to sign up quickly.

2 comments:

  1. Peter, do you by chance have the presentation you mentioned online? Andrei.

    ReplyDelete
  2. I think the slides you are looking for are at http://www.osgi.org/DevCon2012/Bofreview

    ReplyDelete

Blog Archive