Guillaume SOLDERA (B SERLI Informatique Bull OW2 Consortium. Comparatif Choco/Drools dans le cadre du projet JASMINe

Transcription

1 Guillaume SOLDERA (B SERLI Informatique Bull OW2 Consortium dans le cadre du projet JASMINe Avril 2008

2 Table des matières 1 Introduction Rappel sur JASMINe Problématique Objectif du document Choco Principe Avantages Inconvénients Drools Principe Avantages Inconvénients Conclusion 9 2

3 1 Introduction 1.1 Rappel sur JASMINe JASMINe est un projet Open-Source, hébergé par le consortium OW2, dont le but est de faciliter le déploiement et l administration de grappes de serveurs distribués. Actuellement les trois principales sociétés motrices du développement de ce projet sont Bull, l INRIA et SERLI Informatique. Plus en détail, JASMINe permet la modélisation, la configuration, le déploiement, l administration et la reconfiguration automatique d architectures distribuées en grappe. Il gère aujourd hui le déploiement de deux solutions de serveurs d applications pour la couche métier : JOnAS et JBoss et permettra bientôt le déploiement de PEtALS, un ESB (Entreprise Service Bus) également hébergé par OW2. Il propose à un architecte de l assister dans la conception et la configuration d un système d informations basé sur une architecture distribuée, et de déployer celui-ci automatiquement à travers une interface de modélisation d architecture. Il permet à un administrateur d obtenir des vues sur le système, de le reconfigurer, de suivre la détection d erreur par un système d alarme et de définir des règles de comportement autonome. Il est construit sur un moteur de déploiement (Jade), un système sondes pour la levée d alarmes, et un moteur de règles pour la configuration de comportements autonomes. Sa manipulation se fait à travers un client lourd RCP (Rich Client PlatForm). 1.2 Problématique Actuellement, lorsque l on utilise la console JASMINe pour définir une infrastructure middleware, on ajoute des briques qui utilisent systématiquement leurs configurations par défaut. Cela oblige donc l utilisateur à configurer à la main chaque middleware. Cette méthode peut conduire à des erreurs et des conflits si par exemple 2 instances du serveurs JOnAS, déployés sur un même serveur, utilise un même port. De plus, cette étape manuelle, fastidieuse si on configure un cluster important, peut apporter son lot d erreurs. L objectif serait donc tout d abord d aider l utilisateur en permettant une configuration automatique, configuration qui serait définie selon certaines règles ou politiques. De plus l outil informerait l utilisateur des éventuels conflits existants dans la configuration à chaque instant. Enfin, l outil devrait également permettre à l utilisateur de définir ses propres politiques de configuration. 1.3 Objectif du document Afin d implémenter l outil décrit ci dessus, une première étude a été faite sur quelques technologies existantes. A la suite de cette étude, des prototypes mettant en oeuvre ces technologies ont été développés. Ces implémentations, ajoutées directement à l application JASMINe existante, ont permis d avoir un avis plus technique sur l utilisation de ces technologies. Le document suivant a pour but de présenter les avantages et les inconvénients des deux technologies testées : le solveur Choco et le moteur de règles Drools. 3

4 2 Choco Choco est une bibliothèque de programmation par contraintes écrite en Java et gratuite. 2.1 Principe La programmation par contraintes a pour but d affecter des valeurs à un ensemble de variables tout en respectant un certain nombre de contraintes. Ces valeurs peuvent ou non être guidées par une fonction objectif (maximisation ou minimisation d une expression faisant intervenir les variables). La programmation par contraintes tente donc de s appliquer à tous les problèmes en offrant une méthode générique de résolution. La programmation par contraintes est déclarative. En effet, il suffit de déclarer les variables, leur domaines, et les contraintes, puis de lancer le processus de résolution, souvent appelé solveur. Le solveur va alors explorer intelligemment l espace de recherche afin de trouver la ou les solutions, si le problème n est pas irréalisable. 2.2 Avantages Le principe et l utilisation basique de Choco est relativement facile et rapide à appréhender. En effet, l utilisateur a juste besoin de créer un problème, d instancier les variables du problème et leur domaine de définition, de poser les contraintes sur ces variables et de demander au problème de se résoudre. De plus, Choco possède déjà de nombreuses contraintes prédéfinies faciles à utiliser. Le principal avantage de Choco est que cette bibliothèque permet de traiter l ensemble des contraintes dans sa globalité, c est à dire qu elle est capable de détecter les éventuels conflits entre les contraintes. Les différentes utilisations ont montré que le processus de résolution des contraintes était rapide et efficace. Ces utilisations ont aussi confirmé la facilité d utilisation des contraintes prédéfinies. 2.3 Inconvénients Un des principaux inconvénients de Choco est que l on ne peut manipuler uniquement des variables entières, réelles ou booléennes. Cela implique donc que lorsque l on veut travailler avec des variables d un autre type, un mapping s impose. Ce mapping entre les variables que l on veut vraiment manipuler et les variables acceptées par Choco doit se faire avant et après le traitement. L utilisation au sein de l application JASMINe a montré qu une application séparée de plusieurs contraintes n était pas très évidente à mettre en place. D une part, il faut pouvoir récupérer toutes les contraintes existantes. D autre part, cela implique qu il faut savoir sur quels objets s appliquent les contraintes pour pouvoir les mapper en variables Choco. De plus, si plusieurs contraintes s appliquent sur les mêmes objets, il faut que ces contraintes traitent les mêmes ensembles de variables Choco. Pour résumer, il faudrait donc tout d abord récupérer tous les objets sur lesquels vont s appliquer les contraintes sélectionnées par l utilisateur. Puis il faudrait regrouper les objets communs à plusieurs contraintes et mapper ces objets en variables Choco. Il faudrait ensuite appliquer les contraintes sur ces variables, résoudre le problème ainsi posé, récupérer les valeurs résultant de la résolution et enfin faire le mapping entre ces résultats et les objets de départ. On s aperçoit ici qu un traitement séquentiel des contraintes, au sein d un même problème, n est pas très évident. Or si l on veut pouvoir détecter les conflits entre contraintes, il faut traiter ces contraintes dans un même problème. Si l on traite les contraintes dans des problèmes différents, il faudrait trouver un système pour voir si les contraintes ne sont pas en conflit, on perdrait alors tout l intérêt de la bibliothèque Choco. 4

5 Les différentes utilisations nous ont montré qu il serait difficile de mettre en place une application dynamique où l utilisateur pourrait ajouter des contraintes. De plus, nous nous sommes rendus compte que l on ne pourrait pas utiliser les contraintes manipulant les expressions régulières, ces contraintes demandant un problème à part. Ces utilisations nous ont également fait apparaître d autres faiblesses de cette bibliothèque. En effet, Choco étant toujours en développement, il existe encore quelques bugs et certaines opérations ne sont pas implémentées. 5

6 3 Drools Drools (ou JBoss Rules) est un moteur de règles open source fourni par JBoss. 3.1 Principe Le principe des moteurs de règles est relativement simple. On décrit tout d abord un ensemble de règles, puis un ensemble de faits. En appliquant ces règles sur ces faits, on déduit de nouveau faits, et ainsi de suite. Cette déduction (ou 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. La définition d une règle est, elle aussi, simple. En effet, il suffit d indiquer une condition (donc une expression booléenne) et les actions à mener si cette condition est vérifiée. Les règles peuvent être éditées au format drl ou xml. Une fois ces fichiers créés, on crée ce qu on appelle une RuleBase dans laquelle on ajoute ces fichiers. A partir de cette RuleBase, on crée ce qu on appelle un WorkingMemory. Puis on passe les objets à analyser par les règles au WorkingMemory. Enfin on exécute les règles. Ces règles seront appliquées à tous les objets passés au WorkingMemory. 3.2 Avantages La structure d une règle implique une écriture assez simple. En effet, pour définir une règle, il faut tout d abord indiquer le nom de la règle, une condition, des actions à mener. On peut noter que dans les actions, on peut mettre du code Java ou appeler des méthodes d objet, on peut donc manipuler directement les variables que l on souhaite modifier. On peut également faire appel à des fonctions propres à Drools comme par la fonction update qui met à jour le nouvel état de l objet passé en paramètre. De plus, il est possible d exécuter uniquement les règles appartenant à un même groupe. Ainsi, l utilisateur a la possibilité d exécuter les règles qu il souhaite et uniquement celles-ci. Il est donc relativement aisé d appliquer les règles séparément. De plus, grâce à l API complète offerte par Drools, il est possible d analyser les fichiers contenant les règles et donc de récupérer facilement les règles existantes. La définition d une règle Drools est relativement simple. Cependant, il existe des outils (fournis par un plugin Eclipse) permettant à l utilisateur de définir encore plus simplement une règle. En effet, cet outil permet aussi d écrire une condition avec une phrase et définir ainsi un DSL (Domain Specific Language) spécifique. Chacune des phrases définies doit alors être mappée avec une expression ayant une syntaxe propre à Drools. L utilisateur doit aussi fournir le scope de l expression, afin de déterminer si cette phrase est une condition ou une action (figure 1). Fig. 1 Mapping expression-règle 6

7 Une fois définies, l utilisateur peut utiliser ces phrases dans ces fichiers de decription de règles. Ainsi, lors de la lecture d un fichier contenant des règles, l utilisateur a une perception beaucoup plus claire et plus rapide de la règle (figure 2). Fig. 2 Exemple d utilisation Un avantage non négligeable de Drools est qu il n est pas nécessaire de connaître la syntaxe pour créer une règle. En effet, les règles peuvent être créées à partir de tables de décision (figure 3), i.e un fichier Excel contenant entre autres les conditions, les actions mais aussi les objets et leurs attributs sur lesquels s exécutent les conditions. Fig. 3 Exemple de table de décisions Un RuleBuilder est également disponible. Il se caractérise par un fichier brl et un fichier.package. Ce dernier contient toutes les importations nécessaires afin d avoir accès aux objets et à leurs attributs, tandis que le fichier brl contient un éditeur de règle (figure 4). Ce fichier génère le code source brl et drl. Fig. 4 Editeur de règle Ces facilités d écriture de règles sont un vrai plus pour permettre à l utilisateur d ajouter des règles. Un autre avantage de Drools est qu il existe déjà un moteur de règles intégré à JASMINe. Ainsi, peut être pourrait on envisager une communication entre le moteur existant et l interface, afin de pouvoir appliquer certaines règles propres à la configuration. 3.3 Inconvénients Un des inconvénients de Drools est que cet outil ne permet pas la génération automatique, dans le sens où c est à l utilisateur d écrire les actions à mener. C est donc à l utilisateur d écrire les classes Java correspondant aux actions à mettre en oeuvre. 7

8 De plus, Drools ne détecte pas automatiquement les éventuels conflits entre les règles, il faut donc mettre en place un mécanisme gérant cela. Cependant, des options sur les règles existent (priorité, groupe...). Comme pour Choco, il faut pouvoir récupérer les objets sur lesquels s appliquent les règles, afin de pouvoir les passer au moteur de règles. Il faudrait aussi s assurer que la communication entre l interface graphique de JASMINe et le moteur de règles déjà présent dans jasmine-control est possible dans les deux sens, afin de pouvoir passer les objets de l UI au moteur de règles et que les actions présentes dans le moteur de règles soient effectives sur ces objets de l UI. Il faudra sinon dédier un moteur de règles pour l interface. 8

9 4 Conclusion Nous avons vu que ces deux technologies permettaient d effectuer des actions en fonction des règles. Cependant, nous avons pu observer que selon les technologies, ces actions pouvaient être automatisées ou non. Ainsi, Choco permet de configurer automatiquement les objets de telle sorte que ces objets respectent l ensemble des contraintes, et ce sans que l utilisateur n ait besoin de dicter l action à suivre pour résoudre une contrainte. Au contraire, Drools oblige l utilisateur à donner explicitement le code à exécuter lorsqu une condition est vérifiée. Mais Drools permet de manipuler directement les objets soumis aux contraintes, alors que pour Choco, un mapping est nécessaire avant et après l appel des contraintes. De plus l application séparée de plusieurs contraintes est plus facilement réalisable avec Drools. Un des objectifs posés dans la problématique était aussi de donner la possibilité à l utilisateur d ajouter lui-même des contraintes. Nous avons pu voir que selon les technologies, cela serait plus ou moins aisé à concevoir. En effet, bien que l API de Choco permette d implémenter simplement des contraintes basiques (égalité, différence,...) en renseignant très peu d informations (variables, domaine de définition pour chaque variable, contrainte entre ces variables), la moindre contrainte un peu plus complexe est tout de suite plus difficile à implémenter et peut nécessiter des connaissances en Choco de la part de l utilisateur. Drools a l avantage d exister sous la forme d un plugin Eclipse, plugin qui pourrait pourquoi pas être intégré à l interface de JASMINe. De plus, Drools possède une syntaxe plus évidente car plus langagière par rapport autres technologies. Tout ceci serait un plus pour Drools pour l ajout de contraintes par l utilisateur. Bien que Choco possède l avantage de gérer les conflits entre les contraintes définies, Drools semble se démarquer de son concurrent. En effet, l ajout de contraintes paraît plus aisé avec Drools, notamment grâce à la facilité d écriture d une règle et pourquoi pas par l utilisation du plugin Eclipse existant. De plus, l application séparée de plusieurs règles est plus facilement réalisable avec Drools. Pour ce qui est de la gestion des conflits avec Drools, nous avons vu qu il existait des options qui pourraient permettre de résoudre ce souci. On peut aussi imaginer un système de simulation de reconfiguration ou bien la mise en place de flag sur les variables reconfigurées, système qui indiquerait si des conflits existent. 9