Blog

Les moteurs de règles ont traditionnellement un positionnement haut de gamme. De fait, ils sont doublement intimidants : d’abord ils sont plutôt chers, ensuite, pour justifier leur prix, ils sont présentés comme une solution à des besoins complexes, finalement pas si répandus que cela.

D’un point de vue académique, celui de l’intelligence artificielle, le principe des moteurs de règles est simple. On décrit d’une part un ensemble de règles, et d’autre part, un ensemble de faits. En appliquant ces règles sur ces faits, on déduit (‘on infère’ dans le jargon de l’IA) de nouveau faits, et ainsi de suite. L’inférence des faits est assurée par un algorithme classique baptisé Rete ou par l’une de ses nombreuses variantes, plus ou moins brevetées.

Bon, tout cela ne nous dit pas trop ce que nous pouvons en faire pour les applications d’entreprise et le système d’informations. Pour cela, essayons de ne pas mettre la charrue avant les bœufs et revenons aux … besoins.

Classiquement, dans une architecture fonctionnelle, on identifie un certains nombres de règles fonctionnelles durables et relativement faciles à formaliser. Il existe aussi souvent un certains nombre de micro règles, que l’on peine à décrire exhaustivement, et qui ne cessent de changer dans le temps. Ces micro règles correspondent en fait fréquemment à des besoins en flexibilité qui découle de la nature même du métier : adaptation fine des politiques tarifaires, traitement particuliers de certaines catégories de clients, individualisation du service à la clientèle …

Deux dangers nous guettent alors. Le premier danger consiste à exclure les cas particuliers et donc à refuser la flexibilité au métier. Le second consiste à construire une architecture fonctionnelle centrée sur les cas particuliers, rapidement minée par la complexité, et finalement peu flexible.

Il existe diverses approches pour maîtriser le foisonnement des variantes de comportement, dont les moteurs de règles. Malheureusement, leur coût les confine aux cas complexes, alors qu’ils sont déjà intéressant pour les cas plus simples.

Le moteur de règles open source Drools (ou JBoss Rules) se présente dans ces conditions comme une possibilité intéressante. Tout d’abord, il a tous les atours des moteurs de règles établis. Ensuite, il offre deux possibilités dignes d’intérêt. Drools propose ainsi une interface web relativement simple pour décrire des règles. D’autre part, il est possible de définir des règles sous une forme beaucoup plus proche du langage naturel. Dans les deux cas, bien sûr, les règles finissent exprimées dans le langage de définition de règle de Drools. En évitant les discours lénifiants, on peut dire que Drools rapproche ainsi le technique du fonctionnel.

Les moteurs de règles offrent un choix supplémentaire dans la palette de l’architecte. Alors, pourquoi ne pas en profiter ?

Il existe une pléthore de framework web, c'est un fait.

Mais, il faut bien avouer que, pour la plupart, ces frameworks sont finalement très proches, et se contentent de "refaire en mieux", sans véritablement innover, ni offrir d'avancées décisives pour les applications d'entreprise.

JBoss Seam choisit lui une approche innovante avec une forte valeur ajoutée pour les applications d'entreprise ; le tout entièrement en open source. D’un point de vue conceptuel, Seam est l’un des premiers framework à supporter non seulement les architectures sans état, mais aussi les architectures avec état, grâce à la notion de conversation. Cette approche permet la mise en œuvre d’applications web présentant des navigations complexes, et assure une forte séparation des couches quelque soit le niveau de complexité de cette navigation.

Seam intègre de multiples technologies, mais contrairement à d’autre frameworks, il ne cherche pas à encapsuler (donc à brider) ces technologies. Au contraire, il se concentre sur une intégration cohérente et unifiée entre les technologies, ainsi que sur les fonctionnalités supplémentaires à valeur ajoutée. En cela, Seam partage philosophiquement certains points communs avec Spring.

Les technologies intégrées par Seam sont principalement les suivantes :

• le standard JavaServer Faces pour la présentation, et son approche composant,
• JBoss RichFaces avec un ensemble de composants graphiques JSF (supportant AJAX),
• JBoss Ajax4JSF avec un ensemble de composants JSF facilitant le support d’AJAX,
• une extension de JSF pour la description de navigation avec état,
• le standard EJB session stateless d’EJB 3 pour les composants non conversationnels (sans état),
• le standard EJB session stateful d’EJB 3 pour les composants conversationnels (avec état),
• le standard Java Persistence API et les entités d'EJB 3 pour la persistance,
• JBoss Drools pour la sécurité déclarative par règles, et plus généralement les règles fonctionnelles,
• JBoss jBPM pour les processus fonctionnels (business process) et les workflows, mais également pour les navigations complexes dans le site web.

Seam s'appuie majoritairement sur des standards, avec notablement Java EE 5 ou bien encore l’approche POJO (Plain Old Java Objects). Il utilise notamment les mécanismes standard d’extensibilité de Java EE 5 pour intégrer diverses extensions d’origine JBoss. En pratique, cela signifie que Seam n’est pas particulièrement lié à JBoss Application Server et peut fonctionner dans la plupart des serveurs d’application.

En guise de conclusion, remarquons que Seam intègre des technologies JBoss, tels que JBoss Drools et JBoss jBPM, particulièrement bien placées sur leur marché respectif.