Soirée Paris JUG – Moteurs de règles

La 38e soirée du Paris JUG a eu lieu Mardi 09 Novembre 2010 à l’ISEP.

FastConnect y était représentée par Xavier Degenne et moi-même dans le cadre du sponsoring du Paris JUG par FastConnect.

Le thème de cette soirée était les moteurs de règles.
4 experts se sont succédés au micro lors de cette soirée :

  • Emmanuel Bonnet (Genigraph) a présenté les concepts de moteurs de règles et de BRMS.
  • Laurent Magnin (In Fine) a donné des exemples concrets d’utilisation, au travers des projets sur lesquels il est intervenu, des solutions JBoss BRMS/Drools et ILOG Websphere JRules.
  • Daniel Selman (IBM) a expliqué l’intéret et l’impact des moteurs de règles dans le cycle de vie d’une application, pourquoi externaliser certaines règles, quel gain cela peut apporter et quelles limites il faut cependant maintenir afin de conserver une qualité de service. Il a également présenté les outils IBM Websphere JRules Rule Studio et Rule Team Server.
  • Geoffrey De Smet (Red Hat) a présenté son produit, Drools Planner, qui permet de résoudre des problèmes complexes via les moteurs de règles et des algorithmes heuristiques.

Limitées en durée (30 minutes chacunes), ces présentations faisaient office d’introduction au monde des BRMS. Il n’était pas question ici d’aborder le fonctionnement du moteur de règles ou sur les optimisations à apporter. On a tout de même pu voir quelques exemples de règles, notamment les différentes manières de les exprimer (tableaux, règles SI/ALORS, arbres, flows, …).

Concernant l’intérêt des BRMS, il est clair : elle permet de redonner de la visibilité et même la main au métier sur des applications qui tendent le plus souvent vers une « boite noire ». Deux avantages à cela : le fonctionnement de l’application est partiellement démystifié pour le métier, et le métier peut intervenir directement pour implémenter des règles trop complexes ou qui demandent des compétences qui sortent du périmètre du développeur.

Un autre avantage est que les outils d’édition de règles permettent de documenter les règles et de les présenter d’une manière la plus lisible possible. Cela permet de réduire la perte de connaissances liée au turn-over sur le projet.

L’utilisation de BRMS permet aussi de faciliter l’audit : on peut tracer les différentes règles appliquées, ainsi que les versions de packages de règles. Cela permet de comprendre pourquoi le résultat n’est pas celui que l’on a obtenu.

Malgré tous ces avantages, il y a tout de même certaines limites à l’utilisation d’un BRMS. Les règles suivent un cycle de développement similaire à du code classique : il faut les saisir dans un éditeur de règles, les packager, les tester, etc … Il est également nécessaire de les versionner. Les utilisateurs métiers doivent donc être sensibilisés à ces problématiques de gestion de version, avec potentiellement des conflits et des branch/merge à réaliser.

La phase de test est également nécessaire, si les BRMS répondent bien au besoin de rendre les règles lisibles, ils nécessitent malgré tout de structurer les règles afin de rendre les effets de bord plus faciles à identifier. Cependant les dernières versions de ces outils proposent également des outils de test. L’absence d’un développeur dans la mise en place de la règle ne signifie pas pour autant que les cas aux bords se résolvent seuls, et eux aussi nécessitent d’être testés avant déploiement.

Un autre mythe des BRMS a été cassé d’entrée de jeu : les BRMS ne scallent pas tous seuls. L’intégration d’un BRMS à une application est simple, mais faire en sorte que celui-ci supporte une montée en charge est plus complexe et nécessite une réelle connaissance de l’outils.

Ayant pu utiliser ILOG Jrules (d’avant le rachat d’ILOG par IBM et l’intégration de JRules dans la suite Websphere), je ne peux que confirmer : l’utilisation de JRules a permis de remonter une partie du travail des développeurs vers les analystes fonctionnels, de faire un reporting des règles vers les utilisateurs, …

Cependant un certains nombres de limites se sont imposées :

  • nombre de règles très important, en partie dû à un historique de plusieurs années
  • modèle objet complexe qui multiplie les conditions
  • absence de test exhaustifs.

Ces 3 points ont provoqués un certains nombres de régression lors de déploiements en production non-maitrisés.
De plus certains problèmes se sont posés, notament la gestion des versions, lorsque plusieurs versions peuvent entrer en conflit. Ainsi que l’utilisation de fonctions de manipulation de données, qui nécessitent tout simplement d’être codées en Java.

Malgré tout cela, la migration vers JRules de ce projet s’était révélée positive car les performances (débit et temps de réponse) ont été améliorées, ainsi que la souplesse et la visibilité sur la manipulation des données.

Globalement cette session du Paris JUG est restée très ciblée vers les personnes n’ayant jamais eu affaire à un moteur de règles et constituait une bonne introduction. Cependant elle ne présentait pas un réel intéret pour tous ceux qui ont déjà utilisés un de ces produits, même très rapidement.

Vous trouverez plus de détails et les slides des présentations sur la page du meeting : http://parisjug.org/xwiki/bin/view/Meeting/20101109