urbanisation-si

urbanisation-si

BRMS Moteur de règles : mais que fait IBM ?

BRMS-moteur-de-règles-IBM-ODM-1.jpg

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 :

  1. Stand alone zRES, solution la plus performante
  2. Celle de WAS z/OS avec le framework WOLA, solution la plus confortable, offrant le plus de fonctionnalités
  3. 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/

http://bonnes-pratiques-si.eklablog.com/

http://urbanisation-si.eklablog.com/



27/05/2015
0 Poster un commentaire

A découvrir aussi


Inscrivez-vous au blog

Soyez prévenu par email des prochaines mises à jour

Rejoignez les 94 autres membres