BRMS Moteur de règles : mais que fait IBM ?
En tant qu'urbaniste, j'ai été amenée à travailler avec les BRMS ou moteurs de règles.
Mon premier contact a tout d'abord été avec jRules de l'éditeur français ILOG, puis avec l'open source DROOLS de Red Hat jBoss et enfin avec IBM ODM (Operational Decision Manager), anciennement IBM WebSphere ILOG Rules for COBOL, IBM ayant racheté il y a quelques années ILOG pour absorbé son produit phare jRules et le renommer.
Alors que peut-on dire de ce mastodonte ?
En premier lieu il faut signaler que IBM ODM = ILOG JRules (stateless) + IBM Business Event (stateful). Une des grandes nouveauté est l'intégration de la corrélation d'évènements comme le fait d'ailleurs son concurrent open source DROOLS.
Le moteur de règle d’ODM 8.5 est le même quelque soit l’environnement (zOS, Linux, Windows) et est écrit en Java. C’est le moteur d’origine ILOG JRules.
Des optimisations ont été faites :
- L’introspection a été remplacé par un compilateur natif Java qui compile les classes en code natif
- Le moteur s’auto tune (factorisation, principe de la compilation just in time)
Le moteur (full Java) et les règles (Java) s’exécutent dans une JVM, 3 solutions possibles :
- Stand alone zRES, solution la plus performante
- Celle de WAS z/OS avec le framework WOLA, solution la plus confortable, offrant le plus de fonctionnalités
- Celle de CICS
Remarque : la solution 2 (WAS z/OS WOLA) est la solution retenue pour intégrer Drools à CICS/COBOL
Avec ODM, il n’y a plus de COBOL généré (le produit JRules for COBOL a été complètement abandonné !) car il fallait recompiler le COBOL généré ! Il n’y plus qu’un seul produit ODM. Les 2 produits « IBM ILOG JRules for COBOL » et « for Java » ont donc fusionné. Le moteur est un JAR avec du byte code standard. Le code compilé des règles par ODM est factorisé et optimisé.
Ce qui m'a "scotché", c'est l'intégration dans IBM ODM du module Rules for Office permettant d’écrire les règles avec Excel ou Word en proposant un ensemble de macros.
Le Decision Center Repository permet entre autre la synchronisation des versions. La modification d’une règle par l’expert métier stockée dans le Repository sera répercutée au développeur au moment ou il se synchronisera. Ceci est Identique à Drools (IBM Decision Center Repository = JBoss Guvnor).
ODM possède un outil de vérification de cohérence de règles (règles qui ne peut pas s’exécuter, inclusion d’une règle dans une autre, …).
Mon avis sur IBM ODM zRES est que le coût de la licence reste chère, on est dépendant vis-à-vis d’IBM et pour le mainframe avec l'intégration de COBOL, il faut acheter un processeur spécifique zAAP, donc encore des coûts supplémentaires.
Par contre IBM a tout misé sur les outils pour la MOA permettant vraiment de rédiger les règles avec le vocabulaire métier. Evidemment c'est la meilleure solution d’intégration pour les batchs COBOL et les programmes CICS.
Se lancer avec un outil propriétaire présente toujours les inconvénients de devenir esclave de l'éditeur et de mettre la main au porte monnaie régulièrement mais pour ceux qui n'aiment pas mettre les mains dans le cambouis, les risques techniques seront mieux maîtrisés.
"Il est extrêmement rare que la montagne soit abrupte de tous côtés."
André Gide
Voir aussi :
http://urbanisation-si.wix.com/blog
http://urbanisme-si.wix.com/blog
http://urbanisation-si.wix.com/urbanisation-si
http://urbanisation-si.over-blog.com/
http://rhonamaxwel.over-blog.com/
http://urbanisation-des-si.blogspot.fr/
A découvrir aussi
- Knowledge Is Everything (La connaissance est tout ?)
- Les étapes d’un projet avec un moteur de règles
- Quand faut il utiliser un moteur de règles ?
Inscrivez-vous au site
Soyez prévenu par email des prochaines mises à jour
Rejoignez les 799 autres membres