A la découverte de JBOSS jBPM

Cet article, loin d’être une référence technique, fait suite à une première expérience sur JBPM que je découvrais en même temps que l’univers du BPM (Business Process Management). C’est un exposé d’une première approche appelée à évoluer avec le temps.

JBPM est un moteur de Workflow et de gestion de processus qui implémente les spécifications du langage BPMN 2.0 (Business Project Modeling Notation). Il est entièrement écrit en Java par la communauté JBOSS et distribué sous la licence Open Source Apache. Il est actuellement dans sa version 5.x qui marque une rupture par rapport aux précédentes. Notamment dans sa fusion avec Drools Flow et l’abandon du langage propriétaire JPDL. Un choix intervenu au moment du départ de deux membres du projet qui sont actuellement auteurs du produit concurrent Activiti.

Dans JBPM le Processus est la représentation logique du Workflow. Le moteur est composé d’un noyau (« Core process engine » ) qui exécute les processus, et des services externes (« Core services » et « User services » ). Les deux composantes communiquent à travers des mécanismes de call back. Le choix des services externes (Service Task ou Work Item) se justifie par un soucis de modularité, dans l’optique de faciliter l’extension des fonctionnalités de JBPM. Une manière de pouvoir adapter l’utilisation d’un processus dans des contextes spécifiques – les appels Web Service par exemple – qui ne sont pas pris en charge par le moteur de processus. Leur utilisation nécessite un peu de codage. Il y a des Services Task prédéfinis comme Log et Email et d’autres qui seront créés par les développeurs.

Le projet JBPM intervient dans les différentes phases de développement d’un WorkFlow. De la modélisation du processus avec un plugin Eclipse (ou une interface web) au déploiement sur un Repository. Il donne également la possibilité d’interfacer d’autres outils comme Seam, Spring et OSGI

On interagit avec un processus en passant par une session (Session). La Session doit avoir une référence de la base de connaissances (« Knowledge Base ») qui contient la définition des processus.

Voici le code java :

// load up the knowledge base
KnowledgeBase kbase = readKnowledgeBase();
ksession.startProcess("com.sample.bpmn.hello");

private static KnowledgeBase readKnowledgeBase() throws Exception {
	KnowledgeBuilder kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder();
	kbuilder.add(ResourceFactory.newClassPathResource("sample.bpmn"), ResourceType.BPMN2);
		return kbuilder.newKnowledgeBase();
}

Un processus JBPM peut être vu comme un graphe orienté, avec des nœuds et des transitions. Certains nœuds s’exécutent dans le noyau du moteur de processus tandis que d’autres, plus complexes, sont managés par les services externes.

Je présente ici quelques concepts techniques parmi lesquels s’appuie le moteur de Workflow JBPM et sur lesquels je suis intervenu, avec parfois un peu de douleurs.

Le Human Task

C’est un nœud particulier qui matérialise une intervention humaine. On peut lui associer un utilisateur, un groupe d’utilisateurs et/ou un swimlane. Les Humans Task s’exécutent dans un service externe (Human Task Service) et leur cycle de vie est géré par le Back End Service.

La Persistance

L’état d’un processus peut être persister dans une base de données pour être restitué plus tard. Seules les informations nécessaires au redémarrage du processus seront stockées. La couche de persistance de JBPM est basée sur les spécifications JPA. Elle est configurée par défaut avec Hibernate et la base de données embarquée H2. On peut spécifier une autre base de données. Dans le choix de la configuration on peut aussi choisir les éléments que nous allons persister :

• Les log des instances du processus : ProcessInstanceLog
• Les logs des nœuds : NodeInstanceLog
• Les infos du processus : ProcessInstanceInfo

Quand le mécanisme de persistance est mis en œuvre le moteur de processus (Process engine) fait des sauvegardes à chaque point de restauration (Safe point). Un point de restauration peut être vu comme un état stable du processus, un état où aucune transition n’est activée.

Les Transactions

JTA est le moteur de transaction par défaut. Dans la configuration par défaut l’exécution de chaque méthode se fait dans une transaction. Il est toutefois possible d’adapter cette configuration et de choisir en même temps un gestionnaire de transaction.

Le Multi-threading

Le moteur de processus n’est pas « Thread-safe », aucun mécanisme de synchronisation n’est implémenté pour prendre en charge les verrous, les interblocage ou les situations de famine, … Le processus est exécuté dans un seul thread, les transactions parallèles, même quand elles sont indépedantes, sont activées de manière séquentielle. Le recours pour faire du Multi-threading est de passer par les services externes, comme le Service task. Et à ce niveau la partie la plus importante du travail reviendra à faire de la synchronisation Java.

Sécurité

Le système d’Authentification fourni actuellement est très limité. La Sécurité est déléguée au conteneur externe (JBOSS , Spring, OSGI, …) qui doit gérer les utilisateurs et les rôles. Par conséquent l’intégration avec des sources externes, base de données, systèmes de fichier, annuaire LDAP, ne peut se faire qu’à travers le code.

Conclusion

Si JBPM occupe à ce jour une position de leader dans les solutions Open Source pour le BPM il est encore loin de gagner le pari du «rapprochement utilisateur et développeur » . Certains points du produit (notamment dans sa version 5.1 ) sont à améliorer dans les futures versions :

• L’interface graphique n’implémente pas encore toutes les spécifications de BPMN 2.0.
• A cause des insuffisances de la documentation de la dernière version qui reste assez limitée, réaliser certaines activités peut exiger une investigation approfondie des Mailing Lists ou du code des exemples fournis par la communautés.