Cool! Planet OSGi aggregator!

Just wanted to share that as of today there is a new OSGi-focused feed aggregator: Planet OSGi. You can find it here: http://www.osgi.org/Planet

So if you have a blog that is interesting to the OSGi community at large, get listed!

OSGi Community Wiki now open for contributions

The OSGi Community Wiki is now open to everyone for contributions. Sign up here:

http://wiki.osgi.org/SiteLicensing/Contributor

OSGi DevCon 2011 Call for Participation now open

OSGi DevCon 2011 will be held at EclipseCon in Santa Clara as it has been over the past few years. You can now submit talks and tutorials. For more information see: http://www.osgi.org/DevCon2011/HomePage

Public OSGi Wiki being set up

During the OSGi Community Event last week in London the suggestion was made to create a public OSGi Wiki. BJ Hargrave has acted quickly and just set up a mailing list to discuss this further. This is an open mailing list so subscribe if you want to join the discussion: https://mail.osgi.org/mailman/listinfo/osgi-wiki

OSGi 4.3 core/compendium EA draft 2

The OSGi Alliance has published the second Early Access draft of the upcoming OSGi 4.3 core/compendium specifications. The draft contains the following RFCs (in this order):

• RFC 138 - Framework Hooks (this is the current approach to providing protected scopes for things like applications in the framework).
• RFC 151 - Framework Update 
• RFC 154 - Generic Requirements and Capabilities
• RFC 147 - Command Line Interface
• RFC 157 - Event Admin Update
• RFC 160 - Coordinator Service
• RFC 165 - Combined Configuration Admin enhancements

You can find it here: http://www.osgi.org/Download/File?url=/download/osgi-4.3-early-draft2.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.

CXF Distributed OSGi 1.2 is out!

I'm really excited to be able to say that the CXF Distributed OSGi subproject has done its 1.2 release.

With this release it now also provides the Reference Implementation of the Remote Service Admin specification (chapter 122 of the OSGi Enterprise Specification) in addition to being the Reference Implementation of the Remote Services specification (chapter 13 in the OSGi Enterprise Spec). Together with the Apache ZooKeeper-based discovery implementation it provides all you need to do Distributed OSGi.

A lot of work as gone into this release, which is a major refactoring from the previous code base. This was necessary to support the RSA specification which provides a standard API for the internal building blocks that constitute a Remote Services implementation. This provides a number of benefits:

• You can mix & match components from various implementations, for instance you could use the Web-Services based OSGi Service Remoting provided by CXF together with a Discovery System from another project.
• You could replace the default Topology Manager with a custom built one to control more explicitly which services should be exported or imported and how.
• You could make some interesting mash-ups. I think that the Tuscany project provides a implementation of the Topology Manager for SCA, so in theory you could replace the default one with the Tuscany one and control you CXF-based Remote Services through SCA. I haven't tried this out yet, but it should be possible :)

Besides the real spec text (which is quite readable) you can find a some more information on the components described by the RSA spec on slides 6-8 of my Enterprise OSGi presentation.

You can find the CXF-DOSGi 1.2 release here: http://cxf.apache.org/distributed-osgi.html

Wikipedia page listing all available OSGi implementations

With the release of the OSGi 4.2 Enterprise Specifications, the number of OSGi specs has improved dramatically. This is a good thing because many more use cases are now covered. Is it getting bloated? Not at all, as with OSGi you only take what you need. The basis is always something that implements the OSGi Core specification, and these implementations are often very small. Apache Felix is 383kb and Eclipse Equinox is only just over 1MB. If you need to use any of the other specifications you can add them to your framework runtime to just provide you what you need. Nothing more, nothing less.

To my surprise it was sometimes fairly hard to find where a certain OSGi spec implementation could be obtained. Most people know where to find a number of core frameworks, but where to I find a compliant OSGi Web Applications implementation? Or a Remote Services one? Or maybe you're not happy with a particular implementation, where do you find an alternative?

So I started putting together a list of OSGi spec implementations on Wikipedia, both for core frameworks as well as for other OSGi specifications such as the Enterprise ones.

The wikipedia page is here: http://en.wikipedia.org/wiki/OSGi_Specification_Implementations

I'm sure the list is not complete and there may be some mistakes in it, so I would invite anyone who has more information to add it in!

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.

New OSGi spec drafts available!

Recently the OSGi Alliance has published two new drafts that contain the RFC contents for a number of future specifications.

There is a new draft for the OSGi Core 4.3 release: http://www.osgi.org/download/osgi-core-4.3-early-draft1.pdf. This draft contains:

• RFC 138 which describes running multiple frameworks in a single VM. 
• RFC 151 updates the core framework API to include Java 5 generics.
• RFC 154 introduces generic capabilities and requirements to the OSGi resolver.

Also released was a new draft for the OSGi 4.2 Residential release: http://www.osgi.org/download/osgi-residential-4.2-early-draft3.pdf. This draft contains a number of highly specific specs for the residential area with the notable exception of RFC 144, which has a general impact on OSGi:

• RFC 144 Configuration Admin Extension. The extensions described in the RFP are twofold. The Configuration Permissions are extended. Additionally, with RFC 144 it is now possible for multiple bundles to consume a single Configuration Object. So it means that with that it's possible to share a common Configuration Object across many bundles! This is one thing that I've been looking for a long time, and it will benefit many OSGi Core and Enterprise users as well...

As with previous early draft releases. These specs aren't finished yet, but this should give people a good idea of where things are going and also allow opensource projects to start implementing!

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.