Jrules

Je viens de passer quelques mois à travailler avec le produit Jrules. Le sujet des moteurs de règles me semble intéressant je vous livre donc mes réflexions…

Sur son site web Ilog parle de Jrules ainsi:

“ILOG JRules 5.1 makes it easy for business users to manage rules “

“Grâce à ILOG JRules, les utilisateurs métier des sociétés de placement et de courtage pourront modifier eux-mêmes les règles régissant la conformité.”

Le message est très séduisant et passe très bien en présentation powerpoint auprès des décideurs… Mais en réalité ça donne quoi?

Que faut-il pour pouvoir écrire des règles?

L’exécution des règles dans Jrules repose sur un modèle objet. Avant de pouvoir écrire une règle il faut définir le BOM ou Business Object Model. Le BOM défini une sorte de modèle sémantique qui va permettre d’écrire les règles en langage naturel. Pour chaque objet et méthode on donne une traduction en langage naturel. L’écriture des règles se fait à partir du BOM.

Que faut-il pour pouvoir écrire de bonnes règles?
La qualité des règles dépend donc directement de la qualité du BOM qui lui même dépend du modèle objet.
Définir le BOM c’est fabriquer une sorte de Domain Specific Language: si le langage est trop pauvre: l’utilisateur sera trop limité. Si le langage est trop riche: l’écriture des règles sera trop compliqué. Il faut trouver l’équilibre.

Peut-on arriver à écrire de bonnes règles?
L’un des risques est que les utilisateurs se servent du prétexte Jrules pour ne pas spécifier précisément leur besoin, ça se traduit dans les documents de spécifications par des phrases du type “sera traité par des règles Jrules.” dès que ça devient un peu compliqué. C’est une recette pour une catastrophe.

Je pense qu’il est possible d’atteindre l’objectif initial: “permettre aux utilisateurs de modifier leurs règles sans intervention du service informatique”. Mais uniquement si les utilisateurs maîtrisent extrêmement bien leur domaine fonctionnel. Ils doivent être capable de définir entre quelle borne et quelle borne leurs règles métiers vont varier. C’est à cette seule condition qu’on peut définir un BOM solide qui permettra d’écrire des règles en langage naturel qui seront facilement modifiables.

=> La phase d’analyse et de modélisation est capitale, encore plus que pour un projet traditionnel.
=> La phase de définition du BOM ne l’est pas moins. C’est là ou réside en plus du coût des licences le surcoût d’un projet Jrules.

Peut-on faire des économies avec un moteur de règles?
On peut donc modifier des règles ou en ajouter facilement mais uniquement dans la limite de ce qui a été prévu. Si vous désirez ajouter des données il faut mettre à jour le modèle objet donc le BOM ce qui a parfois tendance à caser les règles existantes. De toute façon vous êtes bon pour repasser par la casse équipe informatique… Adieu les économies.

L’utilisation d’un moteur de règles ne dispense d’aucune des tâches d’un développement classique par contre on trouve en plus la phase de définition du BOM qu’il ne faut pas sous-estimer. La phase de développement initial est donc forcément plus coûteuse avec Jrules que sans. Le ROI ne vient qu’après avoir modifié de nombreuses fois les règles sans faire appel au service informatique.
J’ai pu constater que même après une semaine de formation il est difficile de s’en sortir dès que l’on sort des cas standards sans l’aide des consultants d’Ilog heureusement ceux avec qui j’ai travaillé était très compétent.
Un autre problème est la question du débugguage des règles. Bien que le produit d’Ilog fournisse des outils pour le débugguage ils sont très limités dès qu’il s’agit de travailler avec un modèle un tan soit peu conséquent. Nous avons été obligé de réaliser des développements spécifiques pour pouvoir tester et débuguer les règles dans de bonnes conditions.

Les performances?
C’est l’une des questions qui revient souvent à propos des moteurs de règle, qu’en est-il des performances? En fait il y a rarement de problème de performance provenant directement du moteur de règles. Celui de Jrules implémente l’algorithme Rete qui lui évite d’exécuter toutes les règles à chaque fois. C’est à ce jour la meilleure optimisation connue pour ce type de problème et elle semble donner satisfaction. Et l’on peut toujours aider le moteur en lui indiquant dans quel ordre il doit éxécuter les régles pour éliminer le plus grand nombre de cas dès le départ.

Mais utiliser un moteur de règles ne nous affranchi pas des problèmes de performance classique que l’on rencontre dans toute application. En premier lieu le problème de l’accès aux données. Jrules est très très orienté objet, lors de l’exécution des règles le graphe objet peut être parcouru de manière intense… Comme les données sont souvent stockée dans des bases de données relationnel le problème du mapping objet/relationnel, “l’impedance mismatch” peut devenir très important.

Les alternatives?
En discutant avec d’autres personnes utilisant ou souhaitant utiliser un moteur de règle on constate que bien souvent ce ne seront pas les utilisateurs fonctionnels qui modifieront les règles mais bien les équipes informatiques. Dans ce cas utiliser un langage de script tel que jruby ou jpython apportera les mêmes bénéfices que Jrules en terme de souplesse sans les inconvénients (définition du BOM par exemple). Par contre avec une telle solution on ne bénéficie pas des avantages de l’utilisation de l’algorithme Rete, à moins de le recoder soit même…

Il existe d’ailleurs un produit open source qui fait cela: Drools. Je ne le connais pas, si quelqu’un à un avis?

Conclusions
Les promesses de Jrules ne sont pas impossible à atteindre mais les conditions pour y parvenir me semblent difficiles à réunir. (non non je ne fairais aucun lien vers un dessin de Dilbert!!)

Si vous voulez creuser un peu la question des moteurs de règles je vous recommande ce rapport:

Service Oriented Business Rules Management Systems.

Ainsi que ces animations pour comprendre la magie de l’algorithme Rete.

3 thoughts on “Jrules

  1. Muli K.

    Salut Aurélien,

    Thanks for your interesting post. I hope you won’t mind if I add to your post some (long) reflections I had about the BOM entity while reading your entry:

    Unlike traditional Orchestration tools (Biztalk, Tibco’s BusinessWorks and other BPEL-like tools) which normally and unfortunately interact directly with small-grained APIs (sometimes wrapped as Web Services), I was delighted to find this BOM layer in your description of the Jrules architecture (even though it requires extra development time and the ROI is not clear in the 1st place).

    This BOM, reflecting a Business Entity, is something which is entirely missing from 99.99% of all SOA architecture blueprints. Yet, this Business Entity layer is crucial, as it provides:

    – The foundation for coarse-grained business services.
    As you well explained, Business users, who are using business language, expect to define rules on business entities; and quoting from the reference you mentioned: “Business rules arise from the objects that one encounters in a business and their interrelationships”. Business users [and I claim that programmers just as well] are not supposed to interact with APIs -even if wrapped as web services ?

    – The foundation for Information Caching. This architectural element inside a BOM (not that BOM has it, but it is a reasonable placeholder for it) allows “always-on” business-objects for read purposes, as well as for ultra fast response time. Without BOM, the rule [or the business process] has to interact with [potentially] many underlying APIs, each of which having a different level of availability, reliability and response-time. Using information caching inside a BOM is a tremendous advantage of the BOM entities.

    Regarding the alternatives for building the rule/process, i.e. a rule engine, an orchestration layer or a scripting language like python and ruby: there are obviously good reasons for using each of these depending on the Enterprise/Project context. But the most important thing, imho, is to always go through the intermediary of the BOM and not interacting directly with the distributed APIs of the underlying applications.

    Have a nice week,
    muli

  2. Aurélien Pelletier Post author

    Hello Muli, you are very welcome on my blog,

    What you describe sounds to me like the good old principle of coding to an interface and not an implementation. It is used to build good technical frameworks and it applies just the same to build a “business framework” i.e. a toolkit of services you can reuse to build a process.
    Your comment also reminds me that I believe Jrules could be a nice candidate for the orchestration layer of an SOA. Your point about the BOM confirms it.

  3. Jean-Marc Vanel

    J’ai lu avec beaucoup d’intérêt l’article, car ne sais presque rien sur JRules.

    J’utilise Drools, mais pas directement; je l’utilise comme un moteur d’inférence pour un langage de règles adapté au Web Sémantique : N3 (http://www.w3.org/2000/10/swap/doc/Rules).
    Le language natif de Drools est assez lourd et pas très déclaratif; par contre il a l’avantage de pouvoir insérer insérer n’importe quel code Java dans le conséquent.

    Dans la même chaîne de traitement, il y a aussi ATTEMPTO (http://attempto.ifi.uzh.ch/site/), qui permet d’utiliser de l’anglais formel (“anglais contrôlé”) pour exprimer aussi bien les règles que le modèle. Cela permet de gommer la différence entre les règles et le modèle.

    La semaine prochaine je donne une présentation sur ces sujets:
    http://jmvanel.free.fr/seminaires/seminaires_gratuits.html

Comments are closed.