Implantation

L’architecture de la figure 3.13 a été développée directement en JAVA 1.2, pour bénéficier des avantages de ce langage en terme de portabilité et de comptabilité avec les navigateurs. A cause de l’évolution technologique, nous n’avons pas utilisé la plate-forme Charis Actor Portfolio car elle n’est plus maintenue et parce qu’elle n’est pas compatible avec JAVA 1.2. Cette nouvelle réalisation, faite par Mme Rodriguez-Peralta, forme la version V3 du service de gestion de session initial. La partie décisionnelle, proposée sous forme de vote, pour modérer les changements de session, n’a cependant été implantée que partiellement, l’accent ayant été mis sur l’aspect architectural.

Le prototype décrit figure 3.14 est composé des paquetages suivants, organisés par niveaux.

Au niveau Communication, nous trouvons deux paquetages principaux :

¾ Jsdt : Le paquetage Java Shared Data Toolkit 2.0 (JSDT) est un service de notification pour des applets et des applications JAVA [JSDT99]. Il autorise la diffusion multipoint et fiable de messages quelconques, au travers d’un canal, auxquels s’abonnent les applications émettrices et réceptrices au travers de l’interface sockets. ¾ Notification_Service : Ce paquetage réalise la diffusion mutipoint et fiable des

Le niveau Diagrammes de Coordination se compose de trois paquetages :

¾ Crd_analyser : Ce paquetage contient l’analyseur de diagrammes de coordination qui a été implanté en Xerces Java Parser 1.4.4 [XERC00]. Ce dernier contient deux types d’analyseurs, l’analyseur Document Object Model (DOM) pour récupérer la structure du document et l’analyseur Simple API for XML (SAX), pour récupérer les attributs du document XML. Ces analyseurs sont modulaires et configurables.

¾ Transformation : Ce paquetage contient l’ensemble des règles de transformation qui sont activées lors de l’arrivé d’un événement et qui, en réponse, réalisent les changements sur les diagrammes de coordination.

¾ Crd_engine : Ce paquetage implante le moteur de diagrammes de coordination. Il fournit les fonctions élémentaires pour la génération et la manipulation des diagrammes de coordination.

Figure 3.14. Paquetages pour l’implantation

Au niveau Gestion de Sessions, nous trouvons deux paquetages :

¾ EventXML : Ce paquetage code les événements reçus dans un format XML. Il procède à l’analyse et à la validation des événements manipulés. L’analyseur syntaxique des Evénements XML est aussi implanté avec Xerces Java Parser 1.4.4.

¾ Toolscontrol : Ce paquetage contient deux fonctions principales. (1) Pour chaque participant, il extrait du diagramme de coordination courant l’ensemble des outils actifs. (2) Il manipule les outils, c’est-à-dire qu’il ouvre et ferme les applications chez chaque utilisateur. Grâce aux relations de flux de données, les outils peuvent être configurés localement en mode producteur ou consommateur d’information, pour chaque participant. visualizatorWeb crd_analyser crd_engine toolsControl transformation jsdt eventXML applet Niveau Application Niveau Gestion de Session Niveau Diagrammes De Relation de Coordination Niveau Communication notification_ Service visualizatorWeb crd_analyser crd_engine toolsControl transformation jsdt jsdt eventXML applet Niveau Application Niveau Gestion de Session Niveau Diagrammes de Coordination Niveau Communication notification_ Service

Le niveau Application nous sert à bâtir les applications finales et les interfaces d’accès au service de Gestion de Session. Il se compose des deux paquetages suivants :

¾ Applet : Ce paquetage standard Java nous sert à afficher les résultats de l’exécution de code Java dans un navigateur Web.

¾ Visualizatorweb : Ce paquetage contient le code du visualisateur de session. Pour cette implantation, nous avons utilisé des applets Java, le langage XSL et le navigateur Internet explorer.

L’implantation réalisée est organisée en 35 classes. Elle a nécessité la production de 5000 lignes de code.

Cette réalisation a été valorisée dans le cadre du projet Européen Distributed System Engineering (DSE) [DSE02]. DSE avait pour objectif de réaliser un support logiciel pour l’ingénierie distribuée dans le domaine de l’espace. Il cherchait à promouvoir l’utilisation à grande échelle de plates-formes de technologie collaborative dans l’industrie européenne, qui supportent le cycle de vie complet de l’ingénierie des systèmes [DRIR01].

5.4 Bilan

Le développement d’un service de modèle dynamique (service de coordination), indépendant de son utilisation, constitue la principale caractéristique de cette contribution.

Le premier gain de cette approche architecturale est de maintenir l’indépendance entre une couche de coordination générique et son domaine d’utilisation. Il est ainsi possible de définir des styles de coordination (linéaires, hiérarchiques) réutilisables pour divers domaines, comme proposé par K. Drira [DRIR99], [ROBL02].

Un autre avantage de notre proposition est de faciliter l’évolutivité de notre système. En effet, du fait de notre approche en couches qui fournit clairement une séparation entre la coordination et son utilisation, il est possible de faire évoluer le service utilisateur (ici la gestion de session) sans modifier la couche coordination.

La séparation entre ces deux éléments : diagrammes de coordination et gestion de session, garantit la modularité de notre architecture ainsi que son adaptation potentielle à d'autres domaines qui seront associés à d'autres services de niveau supérieur. Dans ce cas, le service de coordination basé sur des diagrammes de coordination reste le même. Il suffit d’ajouter une nouvelle couche logicielle qui donnera une autre sémantique à la couche de diagrammes de coordination. D’autres services ont été conçus selon cette approche : un service de coordination d’objets distribués au dessus d’une plate-forme middleware CORBA [DRIR99] et un service d’édition partagée [ROBL02].

Cette démarche architecturale peut finalement s’inscrire dans une problématique plus vaste de proposition de services à haut niveau au-dessus d’un service basé sur des graphes dynamiques, au sein d’une méthodologie associée.

6. Synthèse

La table 3.6 résume de façon synthétique nos trois contributions.

Contribution Gestionnaire

de session

Support technologique

Cadre contractuel

Implantation formelle Version V1 Estelle et C National : projet TOPASE

Méthodologie de conception

Version V2 Statechart et JAVA

National : Appel d’offre

Télécommunications du CNRS Support architectural

orienté service de modèle

Version V3 JAVA Européen : projet DSE

Table 3.6. Synthèse de nos contributions

Chacune de ces contributions a porté sur un aspect lié à la conception et/ou à l’implantation de services et de protocoles de session et de coordination. Chacun de ces aspects a été illustré par la réalisation d’une version du service de gestion de session. Chaque version a fait appel à des supports technologiques différents et chacune a été valorisée dans un cadre contractuel qui lui est propre.

L’évolution de nos trois réalisations a été dirigée par une amélioration de la généricité de l’architecture. Nous sommes ainsi passés de modules de coordination pour les versions V1 et V2 à la réalisation d’un service de coordination générique pour la version V3.

De façon parallèle, sur le plan technologique, l’utilisation de langages et d’environnements de plus en plus portables et interopérables, associée à l’utilisation, la plupart du temps, de méthodes formelles, nous a permis un gain en termes de facilité et de qualité de conception des différentes versions.

Conclusion et perspectives

En conclusion, nous récapitulons les principales contributions et les principaux résultats auxquels nous sommes arrivés ces dix dernières années.