OSGi Enterprise R5 specifications released

While the Early Access draft was already available for a couple of months, the OSGi R5 Core and Enterprise specifications are now officially released. The Enterprise release contains a couple of significant new specifications. While the blog post on the OSGi website gives general information about this release, I'm spending a few more words on the new specs that are part of the Enterprise release here.

The Repository specification
Repository is a very interesting new spec that provides an API based on generic capabilities and requirements to access (possible remote) repositories. With this API you can do things like: 'I need a bundle that exports package javax.servlet version 2.5' or you can say 'I need a bundle that provides a Declarative Services implementation version 1.2' without having to know what the name of the bundle is. The Repository can be used with any kind of resource (it doesn't have to be an OSGi bundle) and it works with any type of capability. So you can also make your own capabilities and express requirements in terms of those to find your resources.
Besides the API it also defines an XML interchange format that can be used to export and import repository information across repositories. Note that the resources known to the repository don't actually need to reside inside it, they can live anywhere as long as its accessible via a URL.
The Reference Implementation of the Repository is currently being worked on in the JBoss OSGi project.

The Resolver Specification
OSGi Frameworks have contained resolvers for a long time. This specification allows other entities to use this resolver as a standalone entity as well. The Resolver can obviously be used to resolve OSGi type of requirements, which can be used to evaluate what-if scenarios. The Resolver is stateless, and doesn't need to perform its operations in relation to the local framework, so it can be used to see whether a bundle or set of bundles would resolve in another framework. Additionally, the Resolver can be used on any type of constraint that can be expressed as generic capabilities and requirements, and, as with the Repository, it doesn't need to operate on bundles per se. It can resolve requirements over a set of capabilities provided by any type of resource. While I haven't tried it (yet) you should be able to use it in completely different domains. The RI of the Resolver is in a well-advanced stage at the Apache Felix project.

Subsystems
The Subsystems specification can be described in many different ways. One of the things it allows you to do is to create an archive (an .esa file) which contains a number of bundles which together provide a piece of functionality. For example, take the CXF-DOSGi project which implements the Remote Services specification. To deploy CXF-DOSGi you previously had to deploy a large number of bundles. Composite systems like this can now be bundled in a subsystem, where you only need to deploy a single subsystem to get all these bundles in your framework. There are many other aspects to subsystems too. Instead of bundeling up all the bundles in the .esa file you can also describe the subsystem purely in a declarative sense, by only having a descriptor that says 'my subsystem is defined by bundle1, bundle2 and bundle3'. The subsystem implementation can then use the Repository and Resolver to locate these bundles, pull in their transitive dependencies and deploy the whole lot in your OSGi framework.
Additionally, Subsystems provides a feature for QA teams. It allows you to add an additional Deployment manifest which can lock down the actual versions of the bundles that the subsystem is to be used with. QA teams can use this to lock down the versions to the ones they tested.
Besides all this, Subsystems provides isolation features which are aimed at allowing multiple subsystems to run within the same framework without interference. The Subsystems RI is being implemented in Apache Aries.

ServiceLoader Mediator Specification
This specification deals with getting java.lang.ServiceLoader to work in an OSGi framework. ServiceLoader has been in JavaSE since version 6 and there are lots of problems with it, the main ones being that its non-modular and non-dynamic by design. However there is code out there that uses ServiceLoader and this code needs to work in an OSGi framework as well. That's what this specification enables. The reference implementation is being done in the Apache Aries SPI-Fly component.

Common Namespaces Specification
Namespaces in this context describe various types of information that can be expressed as generic capabilities and requirements. This specification describes a number of these namespaces. They can be used during the resolution process but also as part of the metadata in a Repository so that they can be found using Repository queries. The following namespaces are defined in this spec (note that the Core spec also defines a number of different namespaces):

• osgi.extender: this allows a bundle to express that it needs an particular extender (e.g. I need Blueprint in order to function). The extenders themselves provide this capability.
• osgi.contract: can be used as a convenient way to import a number of packages that together provide a certain contract. For example you could say: give me all the packages that are part of the Servlet 3.0 spec. This namespace is intended for tools to allow developers to specify a contract rather than the individual imports. Under the covers this contract can automatically be expanded into the appropriate import-package statements.
• osgi.service: allows a bundle to express that it needs a given service and similarly allows a bundle to express that it can provide a certain service.

Also included is a new Coordinator specification (which was first released in the Compendium 4.3 release) and significant updates to the JMX specification. The Configuration Admin specification got some new features (among which are 'targeted pids') and some minor changes were made to a number of other specs.

You can download the OSGi Enterprise R5 specification from here: http://www.osgi.org/Release5

Java 8: extensible module definitions with JSON

While the Java Modularity JSR [1] is still AWOL (come on, Oracle, I thought that this JSR was planned to be launched by September 2011!), I did some work in OpenJDK Penrose around changing the Java SE 8 module metadata from the .java/.class format into JSON.

JSON is quite nice because

• it's a simple text format
• easy to read by humans
• easy to parse for computers
• its highly extensible

with JSON, the SE 8 Quick Start module org.astro module definition looks like this:

{
  "module" :
  {
    "name" : "org.astro",
    "version" : "1.2",
    "exports" : [ {"name" : "org.astro"} ]
  }
}

and the same module info file can be expanded to contain OSGi metadata, for example to add a version to the exported package like this:

{
  "module" :
  {
    "name" : "org.astro",
    "version" : "1.2",
    "exports" : 
    [
      { 
        "name" : "org.astro", 
        "org.osgi.version" : "1.2.3"
      }
    ]
  }
}

Any OSGi metadata can be added to the JSON module descriptor. I've added a simple test to the Penrose codebase to give an idea what this looks like: hello-json-custom.sh.

This works today in OpenJDK project Penrose. The codebase still supports module-info.java, to allow a gradual migration to JSON-based metadata, however I'd like to see the module-info.java/.class support go away ultimately.

While Jigsaw/Penrose are two variants on a module system for Java SE, other ones are clearly possible. Once the modularity JSR is up in action, it should seriously consider OSGi as a module system for Java SE 8. Apache Harmony has clearly demonstrated in the past that modularizing the Java platform using OSGi metadata works quite well. OSGi has proven to be an excellent module system for Java for the last 12 or so years, so it would be foolish not to take that experience on board...

On the lack of Modularity JSR, I think at that at this stage we can expect that it will delay the release of Java 8, given that modularity is such an important building block for Java, and is certainly not something that can be rushed through.

[1] 'Java Platform Module System' JSR as mentioned in the Java SE 8 umbrella JSR.

Presentation on new specs in OSGi 5.0 Enterprise release (EclipseCon/OSGi DevCon 2012)

Last week Tim Diekmann and I presented an overview of the new specifications that are part of the OSGi 5.0 Enterprise Release. You can find this presentation online at this link.

Draft releases of the OSGi R5 specs can be downloaded from here:

• Core http://www.osgi.org/download/osgi.core-5.0.0-pfd.pdf
• Enterprise http://www.osgi.org/download/osgi.enterprise-5.0.0-pfd.pdf

The actual final specifications will be made available not too long from now. They are currently in the voting process at the OSGi Alliance. Except for some typos and minor formatting issues the final specs are identical to the above EA drafts.

OSGi Cloud Workshop at EclipseCon/OSGiDevCon 2012

Many people are seeing how well OSGi fits conceptually with Cloud Computing. Its modularity is frugal on memory, and provides isolation. Additionally it focuses components on a particular task, which makes them better maintainable too. Furthermore, OSGi dynamicity makes it possible to create Cloud components that react to changes in the cloud environment in a natural way. They can be dynamically configured, reconfigured and an OSGi Framework can be dynamically provisioned and re-provisioned as well!

Over the past while the OSGi Cloud Working Group has been looking at how OSGi can be enhanced to provide additional support for Cloud Computing. This has resulted in a requirements document called RFP 133.

At this point in time we need to discuss which of these requirements should be tackled first? Is it Discovery in the Cloud? Or Metadata? Or Management or maybe something else?
At the same time we should embrace any existing standards in this area and certainly not attempt to reinvent the wheel!

This discussion is the topic of the Second OSGi Cloud Workshop which is held this year at the EclipsCon/OSGiDevCon venue on Thursday March 29 at 9am.

It is set to be a morning with some presentations (the lineup currently is: Paremus, JClouds, eBay and RedHat/JBoss), a demo, and a lot of time for discussion. Entrance is free - you don't need an EclipseCon pass, but you do need to register as numbers are limited (see here also for details on the location of the venue): http://osgi-cloudworkshop-2012.eventbrite.co.uk

Oh, and just to be sure: EclipseCon/OSGiDevCon 2012 has moved and is in Washington/Reston this year!

JavaSE 8 Modularity, Project Jigsaw and OSGi

One of the requirements for the JavaSE 8 module system is to provide support for and be able to integrate with OSGi. I am therefore very happy to see that a new OpenJDK project is being proposed to focus on precisely this: Project Penrose. Tim Ellison posted the proposal here: http://mail.openjdk.java.net/pipermail/discuss/2012-January/002320.html

They're still looking for initial supporters, authors and committers, so if you're interested in helping out just sign up!

BTW I posted before on this topic, see here: http://osgithoughts.blogspot.com/2011/05/java-se-8-modularity-requirements.html

New OSGi Alliance membership stucture

The OSGi Alliance is where all the OSGi specs are developed as a collaboration effort of a number of companies (and sometimes invited researchers). To be able to contribute to specs you need to be a member. There are a number of reasons for this but probably the most important one is proper handling of IP flow.

In the past a number of people have told me that they would be interested in taking part in the specification work at OSGi but they simply could not afford the membership. Well for those people there is good news today. The OSGi Alliance has moved to a new membership structure where much cheaper options to become a member are available. Also the size of a company is taken into account at certain levels where smaller companies (under 250 employees) pay less.

There is also an entirely new type of 'low-fee' membership: Contributing Associate (which replaces the old Adopter Associate). Being an Contributing Associate is much more useful than Adopter Associate was as Contributing Associates can send up to 2 delegates to Expert Group meetings (such as the Enterprise Expert Group) where they can fully participate in the development of RFPs and RFCs, which ultimately can become OSGi specifications.
Any existing Adopter Associates are automatically moved to Contributing Associate, so they can start contributing right now! (well, you need to sign some docs, but that's all).

Ideally you want stuff like this to be free, but as any Standards Development Organization, the OSGi Alliance (which is a non-profit organization) has operating costs and the membership fees are used for that. As a representative on the Board of Directors I will always make sure that any money in the organization is used appropriately.

I'm personally very happy to see the OSGi restructuring finally taking place. I expect that it will open the door to more participation, especially from the large number of smaller companies who are successfully using OSGi in the field. The OSGi technology is great, but great things can always be improved. Doing this in the OSGi Alliance means that those improvements will be embodied in specifications and specifications ultimately lead to choice as multiple implementations can co-exist so that users will be free from vendor lock-in.

For all the details of the new membership structure see here: http://www.osgi.org/About/Join and here: http://www.osgi.org/About/Benefits#compare
Alternatively, feel free to contact me at david.bosschaert@gmail.com if you have questions, I may not be able to answer all of them but I can always point you at the person who does.

For a list of current OSGi specifications and their implementations see here: en.wikipedia.org/wiki/OSGi_Specification_Implementations

OSGi Enterprise Specification Early Access Draft

A new Early Access Draft containing RFCs aimed at the upcoming OSGi Enterprise Specifications has been made public. The following RFCs are expected to be part of the OSGi Enterprise Release next year:

• RFC 112 OBR
• RFC 152 Subsystems
• RFC 167 java.util.ServiceLoader support
• RFC 169 JMX updates

In addition, the EA draft contains a number of RFCs related to the Core and Compendium specifications.
You can find this draft on the OSGi website here: http://www.osgi.org/download/osgi-early-draft-2011-09.pdf