Architecture technique du Service d’Agilité

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.

3. Le Service d’Agilité comprend les outils développés pour réaliser la collecte des données, la mise à jour des modèles, leur comparaison, et la recommandation d’adaptation.

F ig u r e VI .3 – Ar ch it ec tu re te ch ni qu e de l’i m pl ém en tat ion du Se rv ic e d’ Agi lit é

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 Beans5_.

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 XML6_{. 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 AdaptationDe- 5. Un Java Bean est un composant Java réutilisable qui permet essentiellement de persister les données et de communiquer au sein d’une application

6. On pourrait envisager un stockage des flux XML dans une base de données dans une deuxième version du prototype.

ductionCrisis.

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 Teleray7_{, 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 MISE- 7. Teleray est le réseau de capteurs de taux de radiation dans l’air ambiant géré par l’IRSN.

Cep 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.