Drools et les moteurs de règles
Lorsque l’on entend parler de moteur de règles, on a souvent tendance à y associer le mot « Drools ».
Pourquoi ce réflexe :
- Par habitude ?
- Parce que Drools est l’unique solution du marché Open Source ?
Mais avant j’aimerais répondre à plusieurs questions :
- Qu’est ce qu’un moteur de règles ?
- Quand en a-t-on besoin ?
- Pourquoi en a-t-on besoin ?
Ensuite on pourra présenter Drools !
Qu’est ce qu’un moteur de règles, et pourquoi ?
Vu de l’extérieur, un moteur de règles est un système capable de définir des règles et de les appliquer à des faits. En vulgarisant, un fait est une donnée.
Un moteur de règles est la solution idéale pour les programmes contenant une logique nécessitant un nombre important de « if » (i.e. potentiellement détectable avec un outil d’analyse de la qualité du code, dans la rubrique complexité cyclomatique).
En regardant sous le capot, un moteur de règles est plus complexe. Les règles et les faits sont injectées à un moteur d’inférence. Ce moteur d’inférence cherche les règles applicables aux faits (pattern matching). Tout se passe en mémoire. C’est à dire que la règle a le même cycle de vie qu’une donnée. Une règle peut être chargée, déchargée ou modifiée en mémoire sans réinitialisation du moteur de règles. Ensuite, le moteur de règles optimise l’exécution de règles en les agençant de la manière la plus efficace possible (agenda).
Un moteur de règles permet donc d’isoler le traitement (règles), des données (faits). De plus il permet par exemple de gérer des algorithmes avec de nombreuses micros règles qui changent souvent. Idéal, donc pour des algorithmes implémentant une logique commerciale, très variable suivant les demandes des équipes marketing. Voici un cas d’utilisation possible pour un site d’ecommerce de vente de fruits et légumes : un algorithme métier qui calcule le prix total d’une commande, applique des promotions suivant de nombreuses conditions sur le panier et la fiche client.
La présentation
Chez Xebia, tous les premiers jeudis de chaque mois, il y a un XKE (Xebia Knowledge Exchange). C’est l’occasion pour tous les consultants de Xebia de se retrouver tous ensemble afin de partager sur divers sujets techniques ou d’architecture qui nous tiennent à coeur.
Lors du XKE de décembre, j’ai présenté une session sur les moteurs de règles et le framework Drools (JBoss).
Cette présentation aborde plusieurs points :
- Qu’est-ce qu’un moteur de règles ?
- Drools, les alternatives et son historique.
- Résumé d’un comparatif de moteur de règles.
- Première règle, une règle simple !
- Règles lisibles pour un humain (DSL et Table de décision).
- Drools Guvnor (BRMS/BPMS, système de gestion de régles métiers).
- Drools Flow (Flow/WorkFlow).
- Drools Fusion (Event Processing).
- Performance : Algorithme de Rete
La présentation fut dense. En effet, le focus a été mis sur la dernière version de Drools, la version 5, qui propose énormément de fonctionnalités. De plus, c’est un framework complexe qui demande une immersion longue – plusieurs mois – afin d’être autonome sur le produit. Certes, il propose de résoudre des problèmes non communs dans le monde du développement d’applications de gestion mais le choix d’une telle solution demande une étude approfondie en tenant compte de différents aspects :
- Besoin d’un moteur de règles, une solution de gestion de règles plus simple peut suffire comme par exemple le pattern Specification,
- Coût et temps :
- de formation des développeurs
- pour la réalisation d’un prototype,
- Performance,
- Processus de gestion des règles (qui va administrer et configurer les règles).
Selon moi, les avantages de Drools sont :
- La résolution de manière efficace d’algorithmes non classiques.
- La table de décision via un fichier Excel qui est très proche d’une spécification et ainsi évite une translation vers du code pas souvent agréable à maintenir.
- Drools Guvnor, une application Web afin d’administrer et modifier à chaud les règles via une interface graphique.
- L’intégration de Drools peut se faire seulement sur un point particulier de l’application, pour un algorithme par exemple. Cela aura pas d’impact sur le reste de l’appplication.
Drools permet de gérer les règles via une IHM grâce au composant Guvnor.
Création d’une règle avec Guvnor
Le 21 janvier à Lille au Ch’ti JUG nous avons l’honneur de recevoir Mark Proctor et Geoffrey De Smeet de JBoss. Mark est le projet leader du projet drools. Il vient d’être nommé directeur de RuleML. Geoffrey est le créateur de drools planner.
Plus d’informations : http://chtijug.org/rendez-vous-le-21-janvier-drools-avec-cylande-et-luniversite-de-lille-1/
Une JVM met en oeuvre une notion de binding, entre les appels de méthodes en Java et les implémentations cibles, en manageant les classes utilisées (notamment leur chargement).
En lisant le présent post, il m’est venu à l’idée qu’un moteur de règles met lui aussi en oeuvre, somme toute, une notion de binding. Il associe les méthodes à appeler aux données courantes… Pas sûr que l’on puisse tirer qque chose de plus de cette perspective ‘binding’, mais cela me donne à réfléchir sur cet angle de vue. Du coup, un moteur de règles ressemble à une sorte de machine virtuelle (pour langage dynamique si l’on considère que les règles peuvent être rechargées à chaud).
Outre le binding, les autres notions, comme les tables de décision, relèvent d’autre chose : en l’occurence, une table de décision relève de l’implémentation et non du binding.
[...] Tenez moi informé des nouveaux commentaires par e-mail « Drools et les moteurs de règles [...]
Bonjour,
Est ce que quelqu’un peut me donner plus d’infos sur la solution « Drools Guvnor »?
[...] Le première partie nous as donc parlé de Drools version 5, en commençant par une explication de ce qu’est un moteur de règle et des spécificité de Drools. La conférence été d’un niveau technique très élevé, je ne vais pas ici tout vous rapporter. Si vous désirez savoir ce qu’est un moteur de règle et comment marche Drools je vous conseil de lire l’excellent article du blog de Xebia: Drools et les moteurs de règles [...]