JBoss.orgCommunity Documentation

Chapter 18. Integration with Maven, OSGi, Spring, etc.

18.1. Maven
18.2. OSGi

jBPM can be integrated with a lot of other technologies. This chapter gives an overview of a few of those that are supported out-of-the-box. Most of these modules are developed as part of the droolsjbpm-integration module, so they work not only for your business processes but also for business rules and complex event processing.

18.1. Maven

By using a Maven pom.xml to define your project dependencies, you can let maven get your dependencies for you. The following pom.xml is an example that could for example be used to create a new Maven project that is capable of executing a BPMN2 process:




<?xml version="1.0" encoding="utf-8"?>

<project xmlns="http://maven.apache.org/POM/4.0.0" 

         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">



  <modelVersion>4.0.0</modelVersion>

  <groupId>org.jbpm</groupId>

  <artifactId>jbpm-maven-example</artifactId>

  <name>jBPM Maven Project</name>

  <version>1.0-SNAPSHOT</version>

  

  <repositories>

    <!--  use this repository for stable releases -->

    <repository>

      <id>jboss-public-repository-group</id>

      <name>JBoss Public Maven Repository Group</name>

      <url>https://repository.jboss.org/nexus/content/groups/public/</url>

      <layout>default</layout>

      <releases>

        <enabled>true</enabled>

        <updatePolicy>never</updatePolicy>

      </releases>

      <snapshots>

        <enabled>false</enabled>

      </snapshots>

    </repository>

    <!-- use this repository for snapshot releases -->

    <repository>

      <id>jboss-snapshot-repository-group</id>

      <name>JBoss SNAPSHOT Maven Repository Group</name>

      <url>https://repository.jboss.org/nexus/content/repositories/snapshots/</url>

      <layout>default</layout>

      <releases>

        <enabled>false</enabled>

      </releases>

      <snapshots>

        <enabled>true</enabled>

        <updatePolicy>never</updatePolicy>

      </snapshots>

    </repository>

    

  </repositories>

    

  <dependencies>

    <dependency>

      <groupId>org.jbpm</groupId>

      <artifactId>jbpm-bpmn2</artifactId>

      <version>5.0.0</version>

    </dependency>

  </dependencies>

  

</project>

To use this as the basis for your project in Eclipse, either use M2Eclipse or use "mvn eclipse:eclipse" to generate eclipse .project and .classpath files based on this pom.

18.2. OSGi

All core jbpm jars (and core dependencies) are OSGi-enabled. That means that they contain MANIFEST.MF files (in the META-INF directory) that describe their dependencies etc. These manifest files are automatically generated by the build. You can plug these jars directly into an OSGi environment.

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.

The following jBPM jars are OGSi-enabled:

For example, the following code example shows how you can look up the necessary services in an OSGi environment using the service registry and create a session that can then be used to start processes, signal events, etc.

ServiceReference serviceRef = bundleContext.getServiceReference( ServiceRegistry.class.getName() );
ServiceRegistry registry = (ServiceRegistry) bundleContext.getService( serviceRef );

KnowledgeBuilderFactoryService knowledgeBuilderFactoryService = registry.get( KnowledgeBuilderFactoryService.class );
KnowledgeBaseFactoryService knowledgeBaseFactoryService = registry.get( KnowledgeBaseFactoryService.class );
ResourceFactoryService resourceFactoryService = registry.get( ResourceFactoryService.class );

KnowledgeBaseConfiguration kbaseConf = knowledgeBaseFactoryService.newKnowledgeBaseConfiguration( null, getClass().getClassLoader() );

KnowledgeBuilderConfiguration kbConf = knowledgeBuilderFactoryService.newKnowledgeBuilderConfiguration( null, getClass().getClassLoader() );
KnowledgeBuilder kbuilder = knowledgeBuilderFactoryService.newKnowledgeBuilder( kbConf );
kbuilder.add( resourceFactoryService.newClassPathResource( "MyProcess.bpmn", Dummy.class ), ResourceType.BPMN2 );

kbaseConf = knowledgeBaseFactoryService.newKnowledgeBaseConfiguration( null, getClass().getClassLoader() );
KnowledgeBase kbase = knowledgeBaseFactoryService.newKnowledgeBase( kbaseConf );
kbase.addKnowledgePackages( kbuilder.getKnowledgePackages() );

StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession();