La mise en place de l’agilité

Avant de développer le paramétrage du Service d’Agilité dans le but de jouer l’exemple extrait des cas d’études réalisés dans les projets de recherche PLAY [PLAY, 2010] et So-cEDA [SocEDA, 2010], nous allons nous intéresser à l’architecture logicielle du Service d’Agilité : présentation des outils et services utilisés, agencement avec l’existant (héri-tage du projet MISE). Nous examinerons également le type de licence dont bénéficiera le prototype, compte tenu de ses dépendances avec des librairies et des composants tiers.

Dans cette section, nous allons d’abord nous intéresser aux outils utilisés pour déve-lopper le code de notre prototype (langages, serveurs, outils de génération automatique, etc.). Puis nous présenterons les différents Web Services que nous utilisons, à savoir ceux du Design Time du SIM et celui développé afin d’assurer la partie de Complex Event Processing de notre Service d’Agilité.

WSDL Pour les raisons exposées dans le Chapitre I, nous avons dû simuler les systèmes d’information (SI) des partenaires et les capteurs disséminés dans l’environnement. A cette fin, nous avons développé des Web Services qui simulent ces SI et ces capteurs. La réalisation des différents Web Services a été facilitée par l’utilisation d’un outil de génération de Web Service WSDL (développé au sein du Centre de Génie Industriel de Mines Albi), et de la librairie EasyWSDL développée par Petals Link/Linagora qui gère les descriptions de WSDL.

Cette librairie EasyWSDL implémente la norme WS-Notification contrairement à l’outil de génération de Web Services. Ce dernier impose donc une modification manuelle des données du WSDL généré afin d’ajouter le port d’émission et/ou le port d’abonne-ment aux événements (ainsi que les dépendances aux fichiers liés comme la description des sujets via lesquels les événements sont émis/collectés). L’outil de génération de Web Service (Figure VI.1) propose à l’utilisateur une interface minimaliste, lui permettant d’entrer le nom du service, les opérations et les paramètres typés de ces opérations.

La Figure VI.1 montre la création d’un Web Service du SDIS 81, qui comporte deux opérations eteindreFeu et secourir. Dans eteindreFeu, les informations d’entrée sont la localisation et la nature de l’incendie. Cette opération attend ensuite une réponse indi-quant que l’opération a été exécutée. Nous avons ainsi doté une opération « humaine » (i.e. un traitement non logiciel) d’une interface de Web Service. C’est ce que nous appe-lons un Web Service d’Interface Humaine, qui permet d’intégrer toute activité humaine dans un workflow. La nature particulière de ce Web Service est mentionnée en cochant la case human WS sur l’interface de création. Dans le cadre de cette création de Web Service, nous choisissons de ne générer que le WSDL.

Maven Une fois les informations nécessaires à la prise en charge de l’émission/abonne-ment aux événements manuellement ajoutées au WSDL, nous générerons le squelette du code source Java du Web Service à l’aide du plugin Apache Maven 1 WSOUI (réalisé par Petals Link/Linagora). Ensuite, charge à nous d’implémenter la logique métier propre à chaque Web Service i.e. la mécanique de chaque méthode, mais aussi l’alimentation en données des événements émis et/ou le traitement des événements reçus.

Bus de services (Petals ESB) Les Web Services des partenaires mais également ceux du Design Time ou celui assurant le CEP sont déployés sur le bus de services Petals ESB. La Figure VI.3 détaillée dans la section suivante montre l’intégration de ce bus dans l’architecture globale du prototype permettant la mise en œuvre du Service d’Agilité.

Langages Durant le développement de notre prototype, nous avons utilisé principa-lement les langages Java (1.6), XML (et ses dérivés XSD, XSL et XPath), WSDL ainsi que l’EQL (le langage de requête d’Esper).

Moteur CEP (Esper) Le moteur de CEP utilisé est Esper 4.6.0 (dans sa version gratuite). Il propose une API Java : cela nous a permis de l’encapsuler dans un Web Service et de le doter d’une interface d’abonnement et de réception des événements au format WS-Notification. Nous avons à nouveau utilisé la librairie EasyWSDL pour ce faire. Ce WebService baptisé MISECep est embarqué (comme les autres Web Services) sur le bus de services Petals ESB.

Le code de l’encapsulation d’Esper dans un Web Service capable de produire et de recevoir des événements au format WS-Notification et de les faire traiter par Esper est disponible sur la forge du projet MISE, à l’adresse : https://svn.mines-albi.fr/ mise/documents/ambarthe/MISECEP/ 2 .

ModelsUpdate Nous avons développé un autre Web Service (qui ne se base sur aucun applicatif tiers), nommé ModelsUpdate, qui est en charge de la collecte et de l’interpré-tation des événements filtrés et générés par MISECep. Une fois les données portées par ces événements analysées, ModelsUpdate va s’en servir pour mettre à jour les modèles terrain et attendu de la situation collaborative.

Desgin-Time MISE Dans le cadre de ces travaux, nous allons appeler les services de Design Time du Système d’Information de Médiation (SIM) qui implémentent les trois niveaux d’adaptation présentés dans le Chapitre V. Ces services du Design Time sont le fruit des travaux de thèse de [Mu, 2012] et [Boissel-Dallier, 2012] qui se sont intéressés la partie conception (Design Time) et déploiement (Runtime) du SIM, dans le cadre du projet MISE.

De même que les services des partenaires appelés par l’orchestrateur lors de l’exécu-tion des workflows), ces trois services servant à la conception des workflows sont hébergés sur le bus de services Petals ESB (Figure VI.2).

L’intérêt majeur d’une telle infrastructure réside dans la facilité avec laquelle il est possible de rappeler les services de Design Time, même si l’on se trouve en phase d’exécu-tion des workflows (i.e. en phase de Runtime). Cette caractéristique est particulièrement appréciée lorsqu’on se place dans un contexte d’adaptation des workflows, où la capacité de rebouclage vers les outils de

Comme nous avons pu le voir dans les précédents chapitres, l’architecture du Service d’Agilité 3 et son intégration dans la chaîne collaborative s’appuie à la fois sur une archi-tecture orientée services (SOA) et une architecture dirigée par les événements (EDA).

L’architecture du Service d’Agilité est schématisée dans la Figure VI.3.

Elle suit également une logique architecturale 5-tiers composée d’un navigateur In-ternet (client léger), de JSP/Servlets (logique de représentation) 4 , d’un serveur Apache Tomcat (serveur d’applications), d’un bus de services (autre serveur d’applications) et d’un serveur stockant les données (sous forme de fichiers XML actuellement). Les échanges se font via le protocole HTTP.

Notre Service d’Agilité peut être scindé en deux parties logicielles :

    • La première partie s’occupe de collecter les événements émis par le terrain et la supervision des workflows et de les analyser grâce au Web Service MISECep qui encapsule Esper. Puis, sur la base des événements traités et émis par le CEP, le Web Service ModelsUpdate va réaliser la mise à jour des modèles terrain et attendu (qui sont stockés dans un serveur de fichier) Les Web Services MISECep et ModelsUpdate sont hébergés sur le bus de services Petals ESB,

    • La seconde partie s’attache à exploiter les modèles mis à jour et à proposer à l’uti-lisateur une visualisation des résultats obtenus, via une interface d’application web accessible grâce à un navigateur Internet. Les logiques métier et de représen-tation sont portées par l’application web AgilityService.war qui est déployée sur le serveur d’applications Apache Tomcat. AgilityService.war est composée d’un ensemble de librairies que nous avons développées et qui assurent les fonction de détection (XMLCompare.jar ) et de recommandation d’adaptation (Adaptation-DeductionCrisis), ainsi que d’une servlet qui gère les échanges (requête/réponse) avec le client léger. Cette servlet va communiquer avec la JSP AgilityService et les Java Beans 5 .

L’utilisateur accède au Service d’Agilité via une interface web qui lui propose :

    • La visualisation des représentations graphiques des modèles terrain et attendu,

    • La présentation du résultat de la détection d’une divergence entre les modèles et du détail de cette divergence,

    • La visualisation des recommandations d’adaptation déduites sur la base de la divergence calculée,

    • La possibilité de choisir une recommandation parmi celles proposées (suivant le choix effectué, l’utilisateur sera redirigé vers l’un des trois services de conception du SIM : modeleur de la crise, déduction des processus ou réconciliation syntaxo-sémantique).

Ces deux librairies s’appuient sur les données contenues dans les modèles terrain et attendu, ainsi que dans les paramètres (params). A l’heure actuelle, ces données sont stockées sous forme de fichier XML 6 . Remarquons que ces données sont mises à jour en temps réel par le Web Service ModelsUpdate. Nous allons revenir dans la suite de cette section sur la provenance des informations utilisées par ce service pour mettre à jour ces modèles.

L’utilisateur sollicite d’abord une détection de la divergence entre les modèles terrain et attendu (appel aux fonctionnalités de XMLCompare). Si une divergence (supérieure ou égale au seuil défini dans le fichier params.xml) est détectée, alors l’utilisateur peut solliciter un conseil d’adaptation des processus collaboratifs en appelant AdaptationDeductionCrisis.

Sur le bus de services Petals ESB, on retrouve différents types de Web Services (en plus de ceux qui appartiennent au Service d’Agilité) :

    • Ceux dédiés à la conception du SIM : Modeleur crise, Déduction processus, Ré-conciliation,

    • Celui dédié à l’exécution du SIM : Orchestrateur,

    • Ceux simulant les SI des partenaires de la cellule de crise (dont les services sont sollicités par le SIM) : SDIS 81, SDIS 31, SAMU 31, DIRSO, Gendarmerie,

    • Ceux simulant les capteurs disséminés sur le théâtre de la crise (bâtiments, sta-tions météo, stations Teleray 7 , capteurs embarqués, etc.) : Radiation, Météo, Température. Pour ces derniers, nous n’avons représenté qu’un Web Service de chaque type sur le schéma d’architecture. Dans le prototype nous en avons im-plémentés plusieurs afin de simuler l’existence de plusieurs capteurs de radiation, de météo et de température.

Hormis les Web Services dédiés à la conception du SIM, tous implémentent la norme WS-Notification (toujours grâce à la librairie EasyWSDL développée par Petals/Lina-gora) de façon à pouvoir émettre des événements sur le réseau et à s’abonner à des sujets d’événements.

Les Web Services émettent leurs événements sur le réseau. Le Web Service MISE-Cep va s’abonner à tous les sujets d’événements potentiellement intéressants. Les choix d’abonnement sont des actions de paramétrage qui sont effectuées manuellement par l’utilisateur (pour l’instant). Il serait possible de créer des tables de correspondance entre des choix d’abonnements et des domaines particuliers (crise nucléaire, crise rou-tière, sous-traitance aéronautique, etc.) qui seront utilisées avec des outils de correspon-dance syntaxique/sémantique afin d’automatiser cette étape. Grâce à ces abonnements, MISECep collecte des flux d’événements provenant tant de la supervision de l’exécution des processus (événements émis par les activités des processus exécutés par l’Orches-trateur) que ceux provenant du théâtre de la collaboration (événements émis par les capteurs, etc.). MISECep met ses flux à disposition du moteur de CEP qui va filtrer et/ou déduire des événements en fonctions des règles métier qui ont été paramétrées par la cellule de crise.

MISECep va ainsi créer de nouveaux événements qui retranscrivent l’état de la si-tuation collaborative (émis sur le sujet eventField) et l’état d’avancement des processus collaboratifs (émis sur le sujet eventExpected). Le Web Service ModelsUpdate va s’abon-ner aux sujets eventField et eventExpected afin de collecter les informations nécessaires à la mise à jour des modèles terrain et attendu.

Cette mise à jour se produit en temps réel : tout nouvel événement généré par MISECep est pris en compte par ModelsUpdate qui enrichit le modèle concerné. Il n’y a donc pas besoin d’une intervention utilisateur pour que cette dernière se déclenche, contrai-rement aux actions de détection et d’adaptation.

Dans nos diverses briques logicielles, nous utilisons des librairies et des moteurs tiers. La licence de notre prototype est donc conditionnée par la licence la plus contaminante et la plus restrictive des librairies utilisées. Le tableau suivant liste les différentes librairies utilisées en dépendance et leur licence.

Élément logiciel Licence Mix code Contamination

propriétaire

XMLUnit 1.4 BSD Oui Non

Esper 4.6.0 GPL v2 Non Oui

Petals ESB LGPL Non Non

EasyWSDL BSD Oui Non

XMLCompare LGPL Oui Non

AdaptationDeductionCrisis LGPL Oui Non

TABLE VI.1 – Licences des composants tiers utilisés dans l’implémentation du Service d’Agilité Nous pouvons constater que nous avons affaire à trois types de licence : BSD (Berke-ley Software Distribution), GPL v2 (General Public License v2) et LGPL (Lesser General Public License) (cf. Table VI.1).

Un code source publié sous licence BSD peut être incorporé dans tout type de licence, y compris dans des solutions propriétaires (les modifications apportées à un code BSD peuvent être propriétaires). La licence BSD est extrêmement permissive : il est possible de reproduire, utiliser, modifier et redistribuer le code. Cependant, elle permet à l’auteur du code source d’en conserver la paternité. Elle n’est pas contaminante et demande sim-plement à joindre une reproduction de la licence BSD dans le code source et l’exécutable.

La licence GPL autorise l’utilisation, la copie et la reproduction du code source ainsi que sa modification sous conditions. Elle permet de conserver la paternité du code dans la mesure où toute modification doit être tracée. Cette licence est contaminante et le code source ne peut être réutilisé que dans une solution également sous licence GPL.

Enfin, la licence LGPL est une version allégée de la licence GPL. Sa caractéristique essentielle est la suppression de la contamination induite par la licence GPL.