01net Pro Entreprise informatique
Actualités gestion et logiciel informatique professionnel
Offre et recherche Emploi informatique internet
Salon conférences inofrmatique IT ebusiness 01
Le Cloud Computing
Vidéos reportage entreprise acteur informatique
Retrouvez tous les services 01Net dédiés aux professionnels !
Télécharger logiciels Pro et progiciels
Livres blancs e-commerce informatique et nouvelles technologies
Retrouvez l'ensemble des dossiers de la rédaction 01net Entreprise
Les synthèses des bonnes pratiques sur les sujets IT du moment

La gestion de règles sort de son isolement

Le moteur de règles a désormais pignon sur rue. Les éditeurs de logiciels d'infrastructure tendent à le rapprocher de leurs briques middlewares, notamment la gestion de processus et d'événements.

Et si le moteur de règles (ou BRMS) se propageait subrepticement hors de son périmètre habituel ? Et si d'autres composants que les seules applications venaient à le solliciter ? Par exemple des composants de middleware qui externaliseraient leur mécanique conditionnelle. Tel est le virage que prennent les éditeurs de logiciels d'infrastructure, au premier rang desquels IBM, qui vient de dévoiler la première version de JRules (la Rolls-Royce de la gestion de règles, d'origine Ilog) embarquée dans Websphere. Ou encore Oracle, acquéreur en septembre dernier de l'éditeur Halley, dont le moteur fait désormais partie intégrante de sa suite SOA. Sans oublier JBoss qui, avec sa dernière mouture de Drools, fait de la gestion de règles l'un des piliers de sa “ plate-forme globale d'intégration métier ”.
Globalement, on constate un rapprochement du moteur de règles avec trois éléments du middleware : la gestion d'événements complexes (CEP), la gestion des données de référence (MDM) et la gestion de processus (BPM). Et c'est sans conteste avec ce dernier élément que la complémentarité s'avère la plus évidente.
“ Le moteur de règles devrait apporter au BPM la souplesse qui lui manque, en découplant définitivement la chaîne de processus de la structure changeante de l'information ”, explique Marc Fiammante, Distinguished Engineer chez IBM. Il est en effet fréquent que la création ou la modification d'un attribut lié à un objet métier exige de modifier le service rattaché à cet objet, et rende par conséquent caduque un flux entier de processus. D'où l'intérêt de déporter l'exécution des règles liées à ces métadonnées au niveau du BRMS. “ D'autant que ces outils reposent sur une description des informations à travers des taxonomies. Ils sont donc naturellement mieux armés que le BPM pour exprimer et exécuter des règles relatives à des contenus ”, poursuit Marc Fiammante.
Le BPM se délesterait ainsi de la plupart de ses éléments versatiles, de façon à ne gérer que des objets génériques. Il y gagnerait en stabilité. Et si le BRMS apporte une aide précieuse au sein même d'une séquence BPM, il s'avérera également très utile pour relier plusieurs séquences entre elles. “ Avec le temps, nous nous rendons compte qu'il est impératif d'isoler les séquences BPM par domaine métier. Précisément pour limiter les répercussions d'une modification sur toute la chaîne ”, ajoute Marc Fiammante. Dans ce contexte, le moteur de règles sélectionnera et assemblera les séquences en fonction de l'avancement et des résultats de chacune d'elles.

Découpler infrastructure et métier

Dernier argument en faveur du couple BPM-BRMS : la gestion des exceptions. “ Dans une séquence BPEL, plutôt que de coder des exceptions au niveau de chaque nœud, au risque de faire exploser la modélisation, il est préférable d'exprimer cette exception dans une règle ”, assure Mark Proctor, en charge de JBoss Rules chez Red Hat. En cas d'anomalie détectée, le BRMS court-circuite alors le BPM.
Le rapprochement envisagé entre BRMS et MDM procède de la même volonté de découpler infrastructure et métier. “ Dans une optique d'urbanisation, nous dissocions idéalement trois aspects : les données, d'une part, lesquelles gagnent à être centralisées dans un MDM ; les règles, d'autre part, externalisées au maximum depuis les applications vers le BRMS ; et enfin, les interfaces utilisateurs ”, avance Rosario Soundron, responsable conseil dans la refonte de SI chez Micropole-Univers. Et dans la configuration qu'il préconise, MDM et BRMS s'enrichissent mutuellement. Le premier garantit au second qu'il exploite des données fiables, dont le périmètre est correctement défini. Le BRMS, quant à lui, renforce les procédures de contrôle de données, aujourd'hui trop basiques, du MDM. Par exemple, avant de saisir la référence d'un nouveau client dans le MDM, le moteur de règles exécutera une série de tests afin de qualifier le statut de ce client, un statut auquel sont associés des types d'opérations commerciales.

Le BRMS, imbattable sur l'exécution

Le CEP constitue le dernier élément de middleware qui gravite autour de la gestion de règles métier. Mais à la différence du BPM et du MDM, il oscille entre complémentarité et concurrence dans sa relation avec le BRMS. Concurrence, car tous deux reposent sur le même principe : récupérer des informations, les corréler selon une mécanique conditionnelle, puis générer en retour une information (une alerte, un statut, une valeur, un courriel, un autre événement…). Complémentarité, car chacun dispose d'atouts propres qui devraient, à terme, être combinés. “ Dans la récolte d'informations, le CEP va plus loin que le BRMS, avance Christophe Heubès, consultant chez Xebia. Il sait détecter une répétition ou une absence d'événements dans une plage temporelle. Le BRMS, lui, ne manipule que des messages unitaires. ” De son côté, le moteur de règles reste imbattable sur l'exécution. Il gère une multitude de paramètres en entrée, ainsi que des cinématiques très complexes dans le déroulement des règles.

Offrir un maximum d'autonomie aux utilisateurs

Imbattable, il l'est également dans sa capacité à s'adresser directement aux utilisateurs métier. Les moteurs de règles ont beau se rapprocher des briques middlewares, les éditeurs – principalement IBM/Ilog et JBoss – s'appliquent à garantir aux utilisateurs non informaticiens une certaine indépendance dans la conception et la maintenance de leurs règles. Dernière avancée après les couches sémantiques et la gestion du cycle de vie des règles : la bureautique en tant que frontal. Poussé par Ilog et Microsoft (à travers des partenaires), le concept consiste à connecter le référentiel du moteur avec la suite Office. “ Au travers d'un plug in, l'utilisateur dispose dans Word ou Excel d'un environnement pour manipuler ses objets métier, édicter ses règles et les maintenir. Et celles-ci se synchronisent avec le BRMS ”, détaille Jean-Baptiste Dezard, directeur marketing Europe chez Ilog.
BPM, CEP, gestion de règles et, dans une moindre mesure, MDM gagneraient à partager le même socle technique, les mêmes instances et les mêmes outils d'administration. Tous les éditeurs en conviennent. Mais pour l'heure, seul JBoss/Red Hat a concrétisé cette vue avec la nouvelle version – communautaire – de Drools.

Glossaire

Sollicité sous forme de service, il renvoie le résultat d'un calcul faisant intervenir une multitude de paramètres. Ce calcul résulte d'une modélisation de règles, exprimée dans des langages naturels ou structurés.

C'est tout ce qui enrobe le moteur de règles : gestion des versions, cycle de vie, couches sémantiques pour modéliser des objets métier dissociés des couches techniques sous-jacentes… Ce concept a été popularisé par Ilog.

Le moteur CEP récupère dans des trames temporelles des événements issus de multiples sources, les analyse, les corrèle puis génère en réaction d'autres événements.

2 questions à… : Mariano Boni, directeur marketing et innovation chez Solucom

La gestion des règles connaîtra-t-elle les mêmes difficultés que le BPM ?

“ Une certitude : il est plus facile d'identifier des responsables de règles dans les entreprises que des responsables de processus transverses. Toute la difficulté du BPM réside dans cette transversalité, souvent complexe à formuler. Nombre de processus restent en effet cantonnés dans une application ou dans un seul domaine métier. En revanche, les responsables de traitements unitaires sont légion. Tel celui, par exemple, en charge de la solvabilité client. Pour valider et mesurer son information, un moteur de règles peut lui être fort utile. ”

Qu'en est-il de son adoption ?

“ Aux prémices. Le BPM a contribué à dégrossir les architectures orientées services, mais il ne traite qu'une granularité relativement élevée. Le BRMS, lui, permet d'aller plus en détail. Les deux technologies se complètent donc. Par ailleurs, jusque-là, on ne comptait qu'un nombre réduit d'éditeurs de telles solutions – Ilog et Fair Isaac. Aujourd'hui, Microsoft et JBoss, avec Drools, sont de plus en plus présents. ”

envoyer
par mail
imprimer
l'article