6.3 Le serveur CMSPEM
Le serveur CMSPEM expose une simple API de manipulation de modèle de processus via HTTP. Le serveur a été développé en Java, en utilisant le framework Play, les librairies de manipulation de modèles d’Eclipse EMF, et la librairie EMFJSON4 pour la conversion entre les formats EMF et JSON5.
4. ❤tt♣s✿✴✴❣✐t❤✉❜✳❝♦♠✴❣❤✐❧❧❛✐r❡t✴❡♠❢❥s♦♥
6.3.1 Fonctionnalités
La finalité principale du développement du serveur CMSPEM est de permettre à des outils tiers d’exploiter les données et évènements de processus, en utilisant des liens profonds et des crochets. Pour ce faire, le serveur implante les fonctionnalités suivantes, classées selon les éléments du modèle conceptuel de la section3.3.
Le serveur de processus sert d’éditeur natif (section3.3.7) pour les modèles de processus CMSPEM. Pour ce faire, il :
– Permet de créer des modèles de processus CMSPEM, en envoyant au serveur une requête contenant le contenu initial du modèle.
– Stocke les modèles de processus CMSPEM, et toute donnée utile associée (date de créa-tion, de dernière modificacréa-tion, etc.)
– Permet de mettre à jour des modèles de processus CMSPEM. La mise à jour doit pouvoir être chirurgicale, dans le sens où l’on doit pouvoir, en une requête modifier la valeur d’un attribut précis sur un élément de modèle précis. Par exemple, il doit être possible de mettre à jour le nom d’une tâche, sans avoir à envoyer au serveur une copie complète du modèle de processus modifié.
Le serveur met à disposition des outils tiers un langage de requête (sections3.3.4et3.3.6) sur le modèle de processus, en permettant de :
– Exporter le modèle de processus pour consommation par des outils tiers, sous divers formats.
– Lire une partie du modèle de processus, suite à une requête suivant des conventions bien définies pour spécifier l’élément recherché. Il doit donc être possible, par exemple, de demander des informations sur une tâche particulière, sans pour autant devoir obtenir et traiter l’ensemble du modèle de processus.
– Représenter une requête de lecture sous un format facile à partager, et réutilisable. Dans le cadre de la gestion des événements de processus (section 3.3.5), le serveur a la capacité de :
– Recevoir et enregistrer les abonnements d’outils tiers à des évènements de processus. Les évènements de processus (la modification d’une tâche par exemple) ont chacun des types préalablement définis, qui sont précisés lors de la souscription (voir section5.6. – Envoyer des notifications d’événement de processus à des outils tiers, suite à leur
occur-rence. Les événements sont générés par le serveur suite à une modification du processus, et les outils ayant des souscriptions correspondantes sont notifiés.
Le serveur garde aussi la trace des participants au projet (acteurs) responsables de chaque action sur le serveur de processus. Ceci demande de mettre en place des comptes utilisateur, et que chaque requête soit associée à un compte existant. Les utilisateurs pouvant envoyer des requêtes au serveur CMSPEM peuvent être rangés en deux grandes catégories :
– Les développeurs, qui sont des participants normaux à un projet.
– Les chefs de projet ou ingénieurs qualité, qui supervisent le projet et ont des droits étendus sur le modèle de processus.
Suivant le type d’utilisateur et les besoins, on distingue divers scénarios d’utilisation. Ces scénarios sont décrits dans l’annexe10.4, en utilisant les conventions de description de fonc-tionnalités des méthodes de développement agiles.
6.3.2 Conception
Chaque agent logiciel qui fait une requête sur le serveur CMSPEM le fait avec une clé d’API, qui est envoyée avec chaque requête, pour l’authentifier. Une clé d’API spéciale est utilisée par l’administrateur du serveur, qui seul peut faire des requêtes de gestion d’utilisateur (ajouter et supprimer des clés d’API). L’architecture interne du serveur (voir figure6.10) est présentée ci-après.
FIGURE6.10 – Architecture interne du serveur CMSPEM
6.3.2.1 Stockage de données
Les modèles manipulés par le serveur sont sauvegardés sur disque comme des fichiers XMI. Une base de données conserve les métadonnées associées aux projets (créateur du pro-jet, dates de création et de dernière modification, etc.), les données sur les utilisateurs, les
souscriptions d’événements, et toute autre donnée relative au modèle comme l’historique de modifications.
6.3.2.2 Manipulation de données
Une couche d’abstraction au dessus des API EMF permet de réaliser les opérations cou-rantes comme ajouter un acteur à un modèle, ou masquer une relation existante dans un modèle de processus. Cette couche manipule aussi les données hors du modèle comme les métadonnées sur les utilisateurs.
Un utilisateur peut modifier les métadonnées qui lui sont associés, les modèles qu’il a créés, et les souscriptions dont il est l’auteur.
6.3.2.3 API HTTP
L’API HTTP reçoit les requêtes sur le serveur, et les traduit en appels à la couche de mani-pulation de données. Cette couche valide aussi les paramètres en entrée, et fait les contrôles d’authentification et d’autorisation nécessaires.
6.3.2.4 Outils tiers
Tout outil capable de faire des requêtes HTTP peut communiquer avec le serveur CMSPEM. Typiquement, il s’agit des autres outils de collaboration comme les gestionnaires de versions ou les solutions d’intégration continue.
Les outils de modélisation sont une catégorie spéciale d’outil tiers. Les opérations qu’ils réalisent sur le serveur se limitent à la création et à la mise à jour de modèles de processus.
6.3.3 Implémentation
Le serveur de processus (voir figure6.10) a été implémenté comme une application web, en Java, avec le framework Play6. Play est un framework Java/Scala pour la création d’ap-plications web, avec le modèle MVC. Le modèle MVC (Modèle-Vue-Contrôleur) permet de séparer méthodiquement, dans une application, les aspects métier (modèle), des aspects de présentation (vue), et des liens entre les actions utilisateurs et les traitements métier (contrô-leur).
Un ensemble de modèles Play ont été créés pour représenter les trois concepts clés mis à disposition par l’API, et conservés sur le serveur : les utilisateurs, les projets (modèles de processus), et les souscriptions. Les souscriptions et utilisateurs sont stockés dans une base de données PostgreSQL. Les métadonnées de projet (créateur, date de création et de modifica-tion, etc.) sont conservées dans la base de données, et les modèles de processus eux-mêmes sont conservés avec des fichiers contenant une représentation XMI. Des contrôleurs Play ont été créés pour chacun des concepts CMSPEM, et correspondent aux URLs décrites dans la documentation de l’API (voir l’annexe10.5).
L’API HTTP mise à disposition par le serveur CMSPEM est conçue selon l’architecture REST [Fiel 00] (REpresentational State Transfer). REST est un style d’architecture pour les systèmes hypermédia distribués comme le web. Son choix se justifie d’une part par le fait qu’il impose à chaque ressource exposée par le serveur d’avoir sa propre URL, ce qui correspond exactement au besoin de liens profonds exprimés dans la section3.3.4. D’autre part, l’interface uniforme REST formée par les méthodes HTTP (voir l’annexe10.5) permet de définir une simple inter-face d’accès au serveur par les outils tiers.
Le serveur communique avec les outils tiers au format JSON, afin de s’intégrer facile-ment avec un grand nombre de systèmes tiers, surtout ceux qui possèdent une interface HTTP comme la plupart des outils de développement modernes. En effet, JSON (JavaScript Object Notation) reprend la notation d’objet du langage Javascript, et possède des librairies dans la plupart des langages de programmation. La conversion entre les données de processus au format XMI et la représentation JSON est faite avec la librairie EMFJSON7.
Les souscriptions sont reçues via les URLs prévues dans l’API (voir l’annexe 10.5). Afin d’être contactées par le serveur lors d’une occurrence d’événement, les outils tiers qui enre-gistrent des souscriptions spécifient une adresse web, sur laquelle une requête HTTP de type POST est envoyée, pour signaler une occurrence d’événement.
L’API CMSPEM possède un ensemble de tests écrits en Scala8, qui garantissent que le serveur renvoie les codes de retour HTTP prévus, selon la requête reçue. Le serveur CMSPEM a été déployé en ligne sur la plate-forme Heroku9, est disponible à l’adresse❤tt♣s✿✴✴❝♠s♣❡♠✳ ❤❡r♦❦✉❛♣♣✳❝♦♠✴.