InfoQ interview about work in the EEG

A little while ago I did an interview with Alex Blewitt from InfoQ about current activities in the OSGi Enterprise Expert Group. The interview is now available from here: http://www.infoq.com/interviews/Bosschaert-changes-OSGi-Enterprise-Specification

New OSGi EEG Early Access Draft available

A new Early Access Draft has been published at OSGi that contains 3 RFCs that are currently being discussed in the Enterprise Expert Group.

Blueprint Transactions (RFC 164)
This RFC focuses on how to add declarative transaction support to the OSGi Blueprint standard.

Portable Java Contracts (RFC 180)
OSGi has always been very outspoken about versioning Java packages (for more info see the Semantic Versioning white paper: http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf) however, what version to use for APIs defined by JavaEE has been unclear. While many people have been talking about these APIs in terms of the JavaEE versions (e.g. Servlet 2.5, Servlet 3.0) these version numbers don't always match with the Semantic Versioning ideas that OSGi promotes. For example, with Semantic Versioning you would only increase the major version if you are breaking backward compatibility. When Servlet 3.0 came out of the JCP it did actually not break compatibility with 2.5, but still the major version was increased. In the end the various OSGi-enabled application server implementors used different versioning schemes for JavaEE packages, which made it unclear how to use these in a portable way from OSGi. This RFC aims at addressing this issue in a way that is both natural to people familiar with the JavaEE version numbers as well as being able to cope with the various package version numbers used in the OSGi capable Application Servers.

REST Management Interface (RFC 182)
In the context of Cloud Computing, REST is becoming the dominant way of accessing and controlling remote applications running in the cloud. This RFC defines a remote management interface for OSGi bundles over REST and defines both JSON as well as XML data bindings.

You can find the Early Access Draft here: http://www.osgi.org/News/20121011
Remember that these drafts are not final - if you have any feedback, let us know either via bugzilla (http://www.osgi.org/bugzilla) or via the osgi-dev mailing list: http://www.osgi.org/MailLists

Feedback requested for OSGi RFPs

Now that the summer holidays are drawing to a close for most, it would be a good time to look at some of the new work that is happening at OSGi.
In OSGi new specification efforts are kicked off by creating an RFP, a document that lists the uses-cases and requirements that the ultimate specification must implement. Once an RFP is agreed on the actual technical design and spec-work starts through the creation of a follow-up RFC.

Recently 4 new RFPs have been made public via OSGi bugzilla to see if people have further input or requirements, a process that has worked really well for the OSGi/CDI RFP and a little longer ago for the OSGi Cloud RFP.

RFP 143 OSGi Connect

The people at PojoSR have done some great work in showing how you can use OSGi Services in cases where you may not want to take on OSGi modularity (yet). RFP 143 captures requirements for creating a specification around this. The RFP can be found here: RFP 143.

RFP 150 HTTP Service Updates

The OSGi HTTP Service is widely used and it provides a very nice programming model for sevlets in an OSGi environment. However the specification is in need for an update to modernize it in relation to the Servlet spec itself. Additionally, the whiteboard pattern is introduced for servlet. You can find the RFP here: RFP 150.

RFP 151 Declarative Service Updates

A variety of updates are proposed to the Declarative Services specification. They can be found in RFP 151.

RFP 152 EJB Integration

EJB integration with OSGi has been done at Apache Aries, Glassfish and ObjectWeb (EasyBeans / JOnAS). Other appservers such as JBoss and others also provide some form of interaction between EJBs and OSGi. This RFP aims a writing a specification for this integration to make OSGi-enabled EJBs portable. You can find the RFP here: RFP 152.

So if you have any thoughts about these topics, do chime in and leave your comments or ideas on the associated bugs!

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

OSGi Enterprise Specification Early Access Draft available!

An early access draft for the upcoming OSGi Enterprise Specifications has just been made available. This is really interesting stuff and it shows what we've been working on in the Enterprise Expert Group over the last year or so. Although still work in progress, some of these specifications will be included in the next OSGi Enterprise Release which is currently planned to be released during the first half of 2012.

The main theme for the Enterprise Release is around Subsystem/Application support and OBR (the OSGi Bundle Repository). These are covered in RFC's 152 and 112. Together they greatly improve the way you can define and distribute, assemble and install OSGi applications and I'm really looking forward to the moment that these specs are finished and broadly implemented.

Additionally you can find in the draft: RFC 146 JCA support, two new Blueprint specifications and an update to the JMX specification (chapter 124 in the Enterprise Release 4.2).

Finally there is RFC 167. This is a new RFC that I've been working on. It intends to fix a small but quite annoying issue: the fact that java.util.ServiceLoader() and META-INF/services use generally don't work in OSGi. You can work around it, as I've blogged about in 2008, but it's ugly. Using RFC 167 this issue can be addressed so that any non-OSGi code that uses this pattern can work in OSGi without too much hassle. I've been working on an implementation of this in Apache Aries, if you're interested in trying it out.

Note that the specifications are not yet final so significant changes might still occur. Also, feedback is welcomed! You can leave comments here on my blog or write an email to the osgi-dev mailing list.

You can find the EA draft here: http://www.osgi.org/download/osgi-early-draft-2011-05.pdf

OSGi 4.2 Enterprise Interfaces Jar now available in Maven Central

I can only say: apologies that this took so long, but the OSGi Enterprise Jar is now available from maven central:

group ID: org.osgi
artifact ID: org.osgi.enterprise
version: 4.2.0

or directly here:  http://repo1.maven.org/maven2/org/osgi/org.osgi.enterprise/4.2.0/

This should make using Enterprise OSGi from Maven builds a lot easier.

Presentation: What's new in OSGi 4.2 Enterprise

Just as I was setting off to travel to the Jax OSGi day in Mainz earlier this week my plans got disrupted by another plume of volcanic ash. Only hitting Ireland and Scotland this time, but enough to close Irish airspace for the day. So I wasn't able to deliver my presentation about the new specifications in the OSGi 4.2 Enterprise Release. Lucky enough my friend Roman Roelofsen was at the conference. He has given the talk instead at short notice. Thanks Roman!
This is the presentation that I gave at Jax London and Tim Diekmann also used it at EclipseCon 2010. A number of people have asked to get access to it, so here it is!

What's new in the OSGi 4.2 Enterprise Release

View more presentations from David Bosschaert.

The OSGi 4.2 Enterprise Release is out!

Today the OSGi EEG reached a very important milestone. The OSGi 4.2 Enterprise Release is finished and publicly available! You can download it from here: http://www.osgi.org/Download/Release4V42

The specifications in the release address a number of important Enterprise use-cases and greatly enhance the OSGi programming model. Besides bringing a number of JEE technologies to OSGi, there are also a number of specs that nicely enhance the OSGi programming model.

Here's a high-level overview of the specs developed by the EEG in this release:

• The Blueprint specification is a standard based on Spring-DM. It provides an IOC container for OSGi and really makes developing with OSGi services very easy. Spring has many fans and the Spring-DM project has shown that integrating Spring with OSGi is a very elegant combination. The Blueprint standard helps developers by not binding their code to a single implementation. There are already a number of Blueprint implementations available.
  
  
• Remote Services and Remote Services Admin. These specifications started out under the name Distributed OSGi and bring Distributed Computing to the OSGi Service model. The Remote Services spec is for bundle developers. It describes how the OSGi Services Programming model is enhanced with a number of properties that turn your services into Remote Services. It's a very simple spec with big possibilities.
  Remote Service Admin standardizes on a high level the internal components that a typical Remote Services implementation consists of. It defines the API for the Distribution Provider (the thing that makes the remote invocation), a distributed Discovery System (that can make your OSGi framework aware of suitable remote services) and a component called a Topology Manager that provides the decision policy over what services to export and import. RSA provides users with the capability to mix and match these components from various implementations. A user might use the Distribution Provider from CXF while taking the SCA-enabled Topology Manager from Tuscany combining that with maybe a yet another implementation of Discovery that might use a UDDI server.
  
  
• Web Applications - while deploying .war files in an OSGi Framework was already possible with technologies such as PAX-Web the Webapps spec describes a standard way to do this. Besides providing some new standard Manifest headers (like one to describe what context path your webapp lives on) it also describes a standard way for the Web Application to interact with the other bundles in the OSGi Framework. The Servlet Context will contain a new attribute 'osgi-bundlecontext' that gives your Servlet access to other OSGi Bundles and Services and allows the servlet to register OSGi Services of its own. Other OSGi bundles can interact with Servlets as the Servlet Context(s) of a successfully started Web Application is registered in OSGi Service Registry.
  
  
• The JDBC specification nicely solves problems that database users previously had while using OSGi. Obtaining a database driver was typically ugly and most of the time required exporting and importing private database packages. With the new specification JDBC Database drivers simply register themselves under a standardized DataSourceFactory class in the OSGi Service Registry. It has APIs to create a DataSource (variants for Pooled and XA are also provided) or obtain the underlying java.sql.Driver object. No exposure of internal classes any more.
  
  
• JPA is a highly popular Database Persistence framework and the OSGi-JPA specification describes how to use it from within OSGi. While there is a 'traditional' mode of using JPA in OSGi which is identical to using it in JSE, the recommendation is to obtain a JPA EntityManagerFactory from the OSGi Service Registry. This provides additional lifecycle support (you can update your JPA implementation without restarting the container) and it also allows the existence of multiple JPA providers in the system. OSGi-JPA implementations normally work well with the OSGi-JDBC providers described above.
  
  
• The JNDI spec provides a bridge between JNDI and the OSGi service registry. It enables the lookup of an OSGi Service or BundleContext through JNDI. It also describes how you to obtain a JNDI Initial Context from the OSGi Service registry in case your bundle needs to do a JNDI lookup or bind.
  
  
• Like the OSGi-JDBC spec, the OSGi-JTA spec provides access to JTA APIs such as javax.transaction.UserTransaction and javax.transaction.TransactionManager through the OSGi Service Registry. If you have a JTA implementation in your framework they will simply appear there.
  
  
• Finally, the JMX specification provides JMX access to the OSGi Framework. It enables controlling the Bundle Lifecycle (like installing, uninstalling, starting, stopping a bundle) from JMX and also provides Bundle and Service information through JMX. Additionally JMX APIs are defined for a number of standard OSGi Services such as Package Admin and Configuration Admin.

Besides the new specs a number of existing OSGi specs are also included in the document. Specifications like Event Admin, Configuration Admin, Declarative Service and others are also included as they are also relevant to Enterprise use of OSGi.

Oh, and as a side node, I don't expect Enterprise OSGi Frameworks to deploy all of these specs at the same time. Take only what you need, keep your framework nice and lean :)

Implementations for all of the above are available. Good places to look for them are the Apache Aries and Eclipse Gemini projects. And, of course, Apache CXF provides Remote Services and Remote Services Admin implementations in the CXF Distributed OSGi project.

OSGi 4.2 Enterprise Release Early Access Draft 4

In the OSGi Enterprise Expert Group we're working hard to get the Enterprise Release ready some time in Q1 2010. But if you can't wait, we've just released an Early Access Draft of the new specs. As it says, these aren't finished specs yet. Some details are still bound to change, you will see open questions in certain sections and the formatting of the documents is certainly not final yet, but the overall direction of these specs is most likely not going to change.

The OSGi 4.2 Enterprise Release addresses a number of Enterprise use-cases and brings a collection of Enterprise-related Java specs into OSGi. You'll find the following chapters in the Early Access Draft:

• Web Apps - turn your OSGi framework into a web container. This was already possible with components such as pax-web but now there is a standard for it. Besides being able to deploy your WARs as-is you can also make your Web Apps OSGi-aware and interact with the OSGi BundleContext from within a Servlet. Plus every web-application's Servlet Context gets registered in the OSGi Service Registry as a service, so you can interact with it from an OSGi Bundle too.
  

• Transactions - brings JTA to OSGi. You get hold of a Transaction Manager or User Transaction through the OSGi Service Registry. You can also register a Transaction Synchronization callback object with the Transaction Synchronization Service.
  

• Remote Service Admin - this specification adds an extra layer on top of the existing Remote Services spec (chapter 13 in the 4.2 Compendium). Remote Service Admin defines standard interfaces for the Distribution Provider, Discovery System and Topology Manager, making it possible to mix-n-match these from multiple implementations. The Distribution Provider registers a RemoteServiceAdmin service that exports and imports services when asked. The Discovery System API (called the EndpointListener) provides a standard view over any Discovery System, regardless of how it's realized or what protocol it uses. The Topology Manager provides a Policy over these things. It decides what services will be exported and for when to look for services in a Discovery System.
  

• SCA Configuration Type for Remote Services - this chapter provides a standard mechanism to configure Remote Services and provide qualities of service or intents, through SCA configuration metadata and WS-Policy. Remote Service implementations that also implement the SCA config type provide a portable way to configuration.
  

• Database Access (JDBC) - provides a standard way to look up JDBC Database Drivers through the OSGi Service Registry. Using JDBC in OSGi has been tricky before as it typically involved either using Class.forName() or the META-INF/services SPI model both of which are problematic in OSGi. The Database Access specification uses the OSGi Service Registry to provide you with your database drivers without having to expose any of the implementation classes to your client bundles.
  

• JMX - provides a JMX API into the OSGi Framework. It can be used to control the lifecycle of bundles in the framework (including install, start & stop etc...) but also provides standardized JMX access to a number of OSGi Services such as Package Admin Service, Configuration Admin Service, User Admin Service.
  

• JNDI - brings the JNDI and OSGi Service Registry closer together. It provides a way to look up OSGi Service through JNDI and also makes it possible to interact with JNDI through the OSGi Service Registry.
  

• JPA - brings a proper Database Persistence API to OSGi. It allows you to use JPA from within your OSGi Bundles. Combined with the JDBC and JTA support from the other spec chapters JPA provides a nice way to add database support to your OSGi-based applications.
  

The Early Access Draft doesn't contain all of the specs that you'll find in the final Enteprise Release, it only contains the ones changed since the 4.2 Core & Compendium release. For example, you will also the Remote Service and Blueprint specifications in the final Enterprise release, but they are not included in the Early Access draft.

You can download the 4.2 Enterprise Early Access draft from this location: http://www.osgi.org/download/osgi-4.2-enterprise-early-draft4.pdf

Aries: an Apache project for Enterprise OSGi

Some of you may have noticed the Aries incubator project at Apache: http://incubator.apache.org/aries.

Aries is about building a community specifically around enterprise OSGi components and an enterprise OSGi application programming model. It provides a home for bundles and larger chunks of enterprise OSGi technology independent of the OSGi container, so anything found in Aries should work in a compliant OSGi runtime such as Felix or Equinox.

Part of the proposal focuses on the development of an OSGi Application model for assembling multiple bundles into a larger parts which you can think of as an application.

An application model is one of the things that the OSGi Enterprise Expert Group (EEG) is currently defining and working ahead on an implementation will help making this standard better as experience is always better gained by doing.

Initially the project will provide an implementation of the OSGi 4.2 Blueprint specification (RFC 124), an implementation of JPA support for OSGi and JNDI integration for OSGi.

Like with any Apache project, anyone interested in joining the fun is more than welcome to contribute! Many individuals and people working for a large variety of companies have already joined during the proposal stage and I would expect even more people to join once the project is under way.

Exciting stuff!

Co-chairing the Enterprise Expert Group

Last week the OSGi Enterprise Expert group has elected me as their new co-chair after Eric Newcomer is moving on to greener pastures elsewhere. I have to say that I'm thankful for the confidence that the EEG has in me and would like to thank everyone for their support. Obviously I will be taking on the role together with my esteemed co-chair Tim Diekmann, who has been in this role since the EEG started.

Here's a little bit about me. I work for Progress Software in Dublin, Ireland and worked for IONA technologies for about 10 years before they were acquired by Progress. During my time I've worked on a number of products which include Orbix the IONA Corba product, a J2EE Appserver, Mobile Middleware and a Repository product. I've also been involved with the Apache and Eclipse open source projects where I am a committer on CXF and on the STP Policy component respectively. Before I joined IONA, I worked in the Netherlands for a Cap Gemini subsidiary called Bolesian. I've been active in the OSGi EEG since it started in January 2007, and have been one of the drivers behind Distributed OSGi, now called 'Remote Services' which is released in OSGi 4.2.

Looking forward, things will be busy. Within the EEG everybody is working really hard on the 'OSGi 4.2 Enterprise' release, which we're planning to get out at around the end of this year. We're hoping to get a bunch of JavaEE mappings in, things like Webapps, JPA, JTA, JMX, JDBC, JNDI. Being an army of volunteers, its hard to guarantee that they will all make it, but at least I know everyone is doing their very best to get there.

Last but not least, I would like to thank Eric Newcomer, which whom I have worked for many years for the excellent work he has done in OSGi and wishing him the very best for his new job that he is starting soon.