I’ve spent some time getting Drools OSGi ready, which was harder than I expected, especially as OSGi is new to me. Last night I finally got OSGi Declarative Services working with Drools. When you combine this with our Spring work, http://blog.athico.com/2009/12/drools-spring-improvements.html, it’s great timing for the recent Spring DM announcement, http://blog.springsource.com/2010/01/12/dm-server-project-moves-to-eclipse-org.

For those that don’t know. OSGi is a dynamic module system for declarative services. So what does that mean? Each jar in OSGi is called a bundle and has it’s own Classloader. Each bundle specifies the packages it exports (makes publicly available) and which packages it imports (external dependencies). OSGi will use this information to wire the classloaders of different bundles together; the key distinction is you don’t specify what bundle you depend on, or have a single monolithic classpath, instead you specify your package import and version and OSGi attempts to satisfy this from available bundles.

It also supports side by side versioning, so you can have multiple versions of a bundle installed and it’ll wire up the correct one. Further to this Bundles can register services for other bundles to use. These services need initialisation, which can cause ordering problems – how do you make sure you don’t consume a service before its registered?

OSGi has a number of features to help with service composition and ordering. The two main ones are the programmatic ServiceTracker and the xml based Declarative Services. There are also other projects that help with this; Spring DM, iPOJO, Gravity.

Each of the Drools factories is now also available as a FactoryService interface. You can either have OSGi inject those into a pojo, or retrieve them yourself from OSGi. I’ll cover injection here. The below example injects the KnowledgeBuilderFacotryService, KnowledgeBaseFactoryService and ResourecFactoryService into the TestComponent pojo.

<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0"><implementation class="testosgi.TestComponent"/><reference bind="setKnowledgeBaseFactoryService"           unbind="unsetKnowledgeBaseFactoryService"           interface="org.drools.KnowledgeBaseFactoryService"           />         <reference bind="setResourceFactoryService"           unbind="unsetResourceFactoryService"           interface="org.drools.io.ResourceFactoryService"           />                    <reference bind="setKnowledgeBuilderFactoryService"           unbind="unsetKnowledgeBuilderFactoryService"           interface="org.drools.builder.KnowledgeBuilderFactoryService"           target="(org.drools.compiler.DecisionTableProvider=true)"  />           </scr:component>

The TestComponent will only be activated when all of the referenced services are available and injected into the pojo. You’ll also notice the “target” attribute for the KnowledgeBuilderFactoryService. The reason for this is that OSGi DS has no built in way to declaratively say which optional services must be present to satisfy your component. As a work around I made any Drools service that has optional services set a property if/when the optional service is available. Filters can then be applied, via the target attribute, to make sure the Service is in a desired state before consuming it. And that is pretty much it 🙂

<configuration>   <manifestLocation>META-INF</manifestLocation>   <instructions>       <_removeheaders>Ignore-Package</_removeheaders>                          <Require-Bundle>org.drools.api;visibility:=reexport;bundle-version="\${pom.version}"</Require-Bundle>       <Import-Package>!org.drools.*, *</Import-Package>       <Export-Package>org.drools.*</Export-Package>           <DynamicImport-Package>*</DynamicImport-Package>       <Bundle-Activator>org.drools.osgi.core.Activator</Bundle-Activator>   </instructions></configuration>