Besoins d’adaptation structurelle pour la distribution

C HAPITRE 2 Adaptation structurelle

2.6 Cas d’étude : un support de communication dans un projet collabo ratif

2.6.3 Besoin de l’adaptation structurelle dans l’application Com-In-Project

2.6.3.2 Besoins d’adaptation structurelle pour la distribution

Étant donné que nous disposons d’une infrastructure distribuée (c’est-à-dire, d’autres machines sont disponibles à travers le réseau), une solution consisterait à déployer certains services sur d’autres nœuds de l’infrastructure (i.e. répartition des tâches sur plusieurs sites) en fonction du contexte ; ce dernier fai- sant référence en premier lieu aux caractéristiques techniques de l’infrastructure de déploiement (i.e. adéquation à l’architecture matérielle) mais aussi aux propriétés des utilisateurs et aux conditions d’uti- lisations (par exemple, les services susceptibles d’être les plus utilisés doivent être déployés en priorité sur la machine de l’utilisateur).

Cependant, les composants logiciels constituant l’application de support de communication ne per- mettent pas de distribuer les services qu’ils proposent tel que le souhaite l’administrateur. En effet, la majorité des composants a été conçue comme des entités monolithiques. De ce fait, l’ensemble des ser- vices qu’ils proposent ne peuvent pas subir de déploiement distribué (i.e. un composant monolithique doit être déployé sur un seul nœud de l’infrastructure). De ce fait, deux solutions peuvent être envisagées pour obtenir la configuration souhaitée par l’administrateur : soit, développer à nouveau les composants incapables de distribuer certains des services qu’ils fournissent (tels que les composants monolithiques), en fonction des nouveaux besoins. Cette solution ne peut pas être envisagée pour des raisons de coût ; soit adapter la structure de ses composants de manière à la rendre conforme à la configuration souhaitée. Par exemple, considérons le composant Agenda-partagé. Ce composant a été implémenté comme un composant monolithique fournissant les services suivants :

• gérer un agenda personnel (authentification, consultation d’évènements, recherche de contacts ou d’évènements, etc.).

Ce service est offert au travers de l’interface Agenda ;

• organiser des réunions (confirmer la possibilité d’organiser une réunion dont la date et la liste des personnes concernées sont données comme paramètres, proposer des dates possibles pour la programmation de réunions entre un ensemble d’individus, etc.).

Ce service est offert au travers de l’interface Réunion ;

• gérer les jours d’absences (consulter les dates d’absences pour un individu dont le nom est donné en paramètre, etc.).

Ce service est offert au travers de l’interface Absence ;

• gérer les droits (modifier les droits de consultation, modification et suppression d’un agenda, pa- ramétrer un agenda en attribuant des droits d’absences à un individu, etc.).

Ce service est offert au travers de l’interface Droit ;

• mettre à jour un agenda personnel, les dates de réunions, les dates d’absences et les droits d’absences d’une personne.

Ces services sont offerts, respectivement, au travers des interfaces MiseAjourAgenda, MiseAjour-

Réunion, MiseAjourAbsence et MiseAjourDroit.

Ce composant requiert également un service permettant d’envoyer des courriels aux personnes concer- nées par l’organisation d’une réunion. Ce service est fourni par l’interface Mail_sender du composant

Serveur Mail.

Le composant Agenda-partagé a été implémenté en utilisant la plate-forme Julia [38] qui est l’im- plémentation Java du modèle de composants Fractal [39] (voir Chapitre 5). Ainsi, le composant Agenda-

partagé est défini sur deux niveaux :

1. le niveau architectural qui contient la description de la structure du composant réalisée en utilisant le langage FractalADL (voir Section 5.2) :

1 <? xml v e r s i o n = " 1 . 0 " e n c o d i n g = " ISO−8859−1 " ?>

2 < !DOCTYPE d e f i n i t i o n PUBLIC "−// o b j e c t w e b . o r g / / DTD F r a c t a l ADL 2 . 0 / / EN"

3 " c l a s s p a t h : / / o r g / o b j e c t w e b / f r a c t a l / a d l / xml / s t a n d a r d . d t d " > 4

5 < com ponent name= " A g e n d a P a r t a g é " >

6 7 8 9 10 11 12 13 14 < c o n t e n t c l a s s = " A g e n d a P a r t a g é I m p l " / > 15 < / com ponent >

2. le niveau implémentatoire qui est constitué uniquement de la classe d’implémentation du compo- sant Agenda-partagé (AgendaPartagéImpl.java) car ce dernier est de type primitif :

1 p u b l i c i n t e r f a c e R e u n i o n { 2 v o i d c r e e r _ r e u n i o n ( D a t e j o u r , V e c t o r p e r s o n n e ) ; 3 v o i d c o n s u l t e r _ r e u n i o n ( S t r i n g n ) ; 4 b o o l e a n c o n f i r m e r _ r e u n i o n ( D a t e j o u r , V e c t o r p e r s o n n e ) ; 5 b o o l e a n e s t _ e n _ r e u n i o n ( S t r i n g n , D a t e j o u r ) ; 6 . . . } 7 8 p u b l i c i n t e r f a c e A bs ence { 9 v o i d a j o u t e r _ a b s e n c e ( S t r i n g n , D a t e d ) ; 10 v o i d c o n s u l t e r _ a b s e n c e ( S t r i n g n ) ; 11 b o o l e a n e s t _ a b s e n t ( S t r i n g n , D a t e d ) ; 12 i n t c o n s u l t e r _ n b _ a b s e n c e ( S t r i n g n ) ; 13 . . . } 14 . . . 15

16 p u b l i c c l a s s A g e n d a P a r t a g é I m p l imp lemen ts Reunion , A bs ence , . . . , A g e n d a P a r t a g é A t t r i b u t e s 17 {

18 . . . 19 }

Comme nous pouvons le constater, le composant Agenda-partagé est doté d’une structure mono- lithique et celle-ci ne correspond pas aux besoins liés à son utilisation dans le cadre de l’application

Com-In-Project. En effet, certains services fournis par ce composant doivent être déployés sur d’autres

nœuds de l’infrastructure : tout d’abord, la machine de l’utilisateur ne dispose pas des ressources néces- saires pour déployer le composant Agenda-partagé en intégralité. De plus, il ne peut être envisagé que le composant soit déployé dans son intégralité sur une machine distante car certains services comme la gestion des agendas personnels doivent rester en permanence accessibles à l’utilisateur malgré les décon- nexions éventuelles ; contrairement aux services de gestion de réunions qui nécessitent une connexion pour fonctionner, donc ces services peuvent être distribués dans l’infrastructure disponible. Donc, le composant Agenda-partagé doit être déployé de manière distribuée. Cette opération passe obligatoi- rement par l’adaptation de sa structure. Ainsi, grâce à l’adaptation structurelle par la ré-ingénierie de composants existants (voir Chapitre 3), de nouveaux sous-composants fournissant des sous-ensembles de services fournis par le composant initial (issus de la fragmentation du composant initial) doivent être créés. Chaque sous-composant pourra alors être distribué sur les différents nœuds de l’infrastructure concernés. Par exemple, les services qui concernent respectivement la gestion des agendas personnels, la gestion des réunions et la gestion des absences peuvent être spécifiés de manière à être installés sur diffé- rents sites. Ainsi, nous définissons trois nouveaux sous-composants pour le composant Agenda-partagé :

1. GestionnaireDAgenda, fournissant les interfaces Agenda et MiseAjourAgenda ;

2. GestionnaireDeReunion, fournissant les interfaces Réunion et MiseAjourReunion. Ce composant devra être redéployé sur un nouveau site dont l’adresse IP est la suivante : 10.1.10.157 ;

3. GestionnaireDAbsence, fournissant les interfaces Absence, MiseAjourAbsence, Droit et MiseA-

jourDroit. Ce composant devra être redéployé sur un nouveau site dont l’adresse IP est la suivante :

Figure 2.6 – Adaptation structurelle du composant Agenda-partagé

Ainsi, grâce à l’adaptation structurelle par la ré-ingénierie, le composant Agenda-partagé peut être déployé conformément aux besoins de l’administrateur de l’application Com-In-Project.

Dans le document Scorpio : une Approche d'Adaptation Structurelle de Composants Logiciels - Application aux Environnements Ubiquitaires (Page 89-92)