LEICA : Un Environnement Faiblement Couplé pour l Intégration d Applications Coopératives

Transcription

1 LEICA : Un Environnement Faiblement Couplé pour l Intégration d s Coopératives Roberta L. Gomes +, Guillermo de J. Hoyos Rivera, Jean Pierre Courtiat, LAAS CNRS [rgomes, ghoyos, courtiat]@laas.fr Résumé Les activités collaboratives impliquent plusieurs personnes qui expriment souvent des besoins différents de travail en groupe. En conséquence, la collaboration ne peut que rarement être supportée par une seule technologie CSCW. Différentes applications collaboratives doivent en général être mises en oeuvre pour réaliser de manière effective un travail en groupe. Bien qu elles soient utilisées pour accomplir une tâche collaborative commune, ces applications sont exécutées de manière indépendante, sans profiter réellement les unes des autres. L intégration de telles applications permettrait de les faire interagir de manière dynamique tout en combinant de manière contrôlée leurs fonctionnalités. Dans le but de réaliser une telle intégration, nous proposons LEICA, un environnement d intégration faiblement couplé qui permet à des applications collaboratives d interagir sans pour autant perdre leur autonomie. LEICA s appuie sur la technologie des services Web, sur un système de notification d événements et sur des politiques de collaboration dans le but de contrôler les interactions entre applications intégrées. I. INTRODUCTION Etant donné que les organisations et communautés de toute nature sont de plus en plus réparties, leur demande en technologies collaboratives est de plus en plus importante. Dans le but de supporter ces activités collaboratives, de nombreuses applications collaboratives, ou systèmes CSCW (Computer Supported Cooperative Work) ont été développés. Etant donné que les activités collaboratives expriment en général des besoins de nature différente, elles ne peuvent que rarement être supportées par une seule technologie. Certains systèmes CSCW essayent alors de combiner différentes fonctionnalités pour assurer la collaboration au sein d un environnement unique. Le point faible de cette approche est le défi qui consiste à anticiper tous les besoins exprimés par les situations coopératives envisagées. Un système CSCW peut * Cette recherché a été partiellement financée par le projet européen IST Lab@Future, Laboratoire d Analyse et d Architecture des Systèmes. 7, Avenue du Colonel Roche, 31077, Toulouse, France. + Chercheur financé par une bourse d étude du CNPq, Brésil Chercheur financé par la bourse d étude du CONACyT et PROMEP, Mexique. ainsi difficilement supporter n importe quel type d activité collaborative. Dans la pratique, les environnements collaboratifs actuels comprennent plusieurs applications qui travaillent côte à côte mais indépendamment et sans profiter les unes des autres. L intégration de ces applications collaboratives pourrait être très bénéfique aux utilisateurs : différentes fonctionnalités pourraient être combinées et contrôlées de manière dynamique, améliorant ainsi la flexibilité du système. Dans le but de réaliser l intégration de systèmes CSCW existants tout en évitant de considérer des détails internes à ces systèmes, nous proposons LEICA : Loosely-coupled Environment for Integrating s. En s appuyant sur la technologie des services Web [1] et sur un système de notification d événements, différentes applications collaboratives peuvent interagir en s échangeant des informations dans le contexte d une session globale, appelée Super. En pratique, les applications intégrées interagissent par des notifications d événements. Leurs interactions sont contrôlées par la politique de collaboration spécifiée pour une Super définissant comment l activité collaborative supportée par une application est affectée par l information reçue d une ou plusieurs autres applications. L article est organisé de la manière suivante. La section 2 décrit un ensemble de travaux concernant l intégration de systèmes CSCW. La section 3 présente une vue d ensemble du cadre d intégration proposé par LEICA. La section 4 décrit comment configurer une Super et explique comment spécifier les politiques de collaboration. La section 5 explique l architecture de LEICA et traite quelques problèmes d implémentation. La section 6 tire quelques conclusions et présente quelques perspectives.

2 II. POSITIONNEMENT Le travail présenté en [2] s intéresse aux problèmes de base relatifs à l interopérabilité de systèmes CSCW hétérogènes qui manipulent de manière concurrente les mêmes artefacts (comme des documents textuels). Il ne s intéresse par contre pas à l interopérabilité de systèmes CSCW qui, bien qu impliqués dans les mêmes tâches collaboratives, ne manipulent pas les mêmes artefacts (par exemple, une vidéoconférence et un tableau blanc partagé). Dans [3] les auteurs proposent un cadre général d intégration s appuyant sur un modèle à trois niveaux : ontologie, coordination et interface utilisateur. Une connaissance interne de l application collaborative est nécessaire pour mettre en correspondance ses fonctionnalités avec le modèle à trois niveaux de manière à réaliser l intégration. En conséquence, l intégration d applications développées par des tiers devient une tâche très complexe (voire impossible) à réaliser. CVW [4] est un prototype d environnement collaboratif définissant des espaces de travail partagé et intégrant des outils de gestion de réunions. Quelques applications collaboratives gratuites (freeware) ont déjà été intégrées et de nouveaux outils spécifiques à un domaine d application particulier peuvent être intégrés. Leur intégration n est cependant pas évidente étant donné que les outils doivent être conçus en fonction des APIs définies par CVW. Afin d éviter de devoir tenir compte des détails internes d implémentation des applications intégrées (permettant ainsi d intégrer des applications existantes), certains environnements ont proposé une approche d intégration faiblement couplée. Un couplage faible permet de résoudre deux problèmes relatifs aux environnements d intégration : (i) il ne nécessite pas de vraie sémantique d intégration des applications collaboratives ; (ii) une fois intégrées à l environnement, les applications collaboratives peuvent préserver leur autonomie. AREA [5] et NESSIE [6] ont proposé une intégration faiblement couplée pour mettre en place une notion de présence inter-applications (cross-application awareness). Comme pour LEICA, ces systèmes s appuient sur l échange d événements pertinents à l activité collaborative globale. Cependant ces environnements, bien qu ils offrent cette notion de présence, ne proposent aucun mécanisme permettant de définir comment une application devrait réagir à des événements notifiés par d autres applications. Une autre solution d intégration, s appuyant également sur une approche faiblement couplée, est présentée en [7]. Les auteurs y définissent un cadre général où des services Web sont utilisés pour empaqueter (wrap) des applications collaboratives afin de les intégrer. Etant donné qu ils s appuient sur des standards Internet ouverts, les services Web résolvent les problèmes d intégration que l on retrouve en général pour des solutions d intégration plus générales comme CORBA [8], DCOM [9] et EJB [10]. Par ailleurs, ils sont plus simples à concevoir et à développer. Une intégration s appuyant sur des services Web est beaucoup plus flexible car elle établit un couplage faible entre les applications. Un des inconvénients de cette approche (qui est en particulier lié à l utilisation du protocole [1]) est qu elle conduit à la définition d une couche supplémentaire qui peut ralentir le traitement des messages échangés [11]. Par ailleurs, selon l architecture des applications collaboratives existantes, le wrapping complet de ces applications en tant que services Web peut conduire à des efforts de développement importants. Par conséquent, contrairement à l approche utilisée en [7], et conformément aux recommandations de [11], nous avons décidé de restreindre l utilisation des services Web. Ainsi, LEICA utilise des services Web pour (i) enregistrer des applications nouvellement intégrées, (ii) créer et (iii) lancer des sessions collaboratives intégrées (ou Supers). Ensuite, une infrastructure différente est utilisée pour mettre en oeuvre le système de notification d événements en charge d interconnecter les applications collaboratives durant l exécution d une Super. III. VUE GENERALE DE LEICA LEICA est un environnement d intégration où des applications collaboratives peuvent interagir par l échange de notifications d événement. En fonction d un ensemble de politiques de collaboration prédéfinies, ces notifications d événement peuvent conduire à l'exécution d actions spécifiques dans ces applications. Le niveau d interaction entre les applications intégrées dépend évidemment de la nature des événements que les applications sont capables d échanger et des actions qu elles sont capables d exécuter. Nous pouvons considérer trois cas principaux lors de l intégration d applications : a) les applications sont open source, b) les applications disposent d APIs, et c) les applications ne disposent d aucune API. L intégration d applications open source permet de réaliser le niveau d intégration le plus élaboré, étant donné que tout événement (et toute action) peut être exporté (et exécutée), ce qui peut également conduire à des efforts de développement importants. L intégration d applications disposant d APIs est directe et le niveau d intégration dépend directement de l API disponible. Les applications ne disposant pas d APIs sont contraintes à interagir uniquement via des actions start et stop de ces applications. L approche d intégration définie par LEICA a pour cible le cas (b). Nous sommes convaincus que

3 les développeurs sont intéressés à créer des outils de collaboration qui puissent être utilisés soit comme des outils indépendants soit comme des outils intégrés à d autres applications (par l intermédiaire d une API la plus flexible possible), ceci afin de conquérir des parts de marché plus importantes. A titre d exemple, nous pouvons citer le logiciel Skype [12], un outil de communication sur l Internet très populaire aujourd hui et qui vient de publier son API. Pour intégrer des applications collaboratives à LEICA, nous devons leur attacher des wrappers. Les wrappers sont attachés aux serveurs des applications client/serveur (ou multi-serveur), et aux pairs des applications (peer-to-peer). Chaque wrapper comprend une interface à des services Web permettant à l application collaborative de s enregistrer auprès de LEICA en tant qu application intégrée (les applications utilisent un Proxy pour s enregistrer). Par l intermédiaire de ses interfaces de services Web, l application intégrée peut interagir avec le service de configuration de session (le illustré dans la Fig. 1). Super Collaboration Policies Web s Master Proxy Fig. 1. Approche d intégration de LEICA Integrated s Le service de configuration de session est un service Web utilisé pour créer et démarrer de nouvelles Supers. Une Super est une session collaborative intégrée gérant l activité collaborative globale. Différentes sessions spécifiques peuvent exister au sein d une Super. Une session spécifique est une session collaborative conventionnelle définie dans le cadre d une application collaborative (par exemple, une session de vidéoconférence ou de tableau blanc partagé). Durant le processus de configuration d une Super, le service de configuration de session contacte dynamiquement chaque application intégrée pour lui demander: (i) les données spécifiques nécessaires à la création de sessions spécifiques (par exemple, un outil de vidéoconférence peut avoir besoin d une adresse multicast IP) ; (ii) les types d événement que l application peut notifier et les types de requêtes d action qu elle peut recevoir (API événements/actions) ; cette information sera utilisée pour spécifier la politique de collaboration de la Notification System Super. La politique de collaboration est spécifiée par un ensemble de règles exprimées sous la forme d un modèle conditions/actions. Ces règles définissent comment chaque application collaborative de la Super doit réagir lorsque des événements en provenance des autres applications collaboratives de la Super sont notifiés. En d autres termes, les règles déterminent les actions que les applications intégrées doivent exécuter en réponse à des notifications d événements. Les politiques de collaboration spécifient ainsi le couplage souhaité entre les applications intégrées et par conséquent le comportement dynamique de la Super. Une fois qu une Super a été créée et configurée, le service de configuration de session peut la démarrer. Les applications intégrées qui sont utilisées dans la Super sont alors interconnectées par un service de notification d événements, et nous n utiliserons donc plus de services Web à partir de ce moment, pour les raisons que nous avons indiquées auparavant. Au cours de l exécution des applications collaboratives, les wrappers échangent des notifications d événement en mode pair à pair. Les wrappers sont également responsables de la gestion des politiques de collaboration. Ainsi, lorsqu un wrapper reçoit une notification d événement, il vérifie si cet événement sensibilise une règle politique concernant l application collaborative à laquelle il est attaché. Dans l affirmative, il envoie la (les) requête(s) d action associée(s) à l application. Remarquons que LEICA n a pas du tout pour objectif de prendre en compte des événements physiques de bas niveau (comme par exemple, des clics ou des déplacements de souris) ni des événements de synchronisation à fréquence élevée (comme par exemple la position courante d objets qui se déplacent). LEICA a au contraire pour objectif de prendre en compte des événements significatifs qui véhiculent une sémantique applicative. Considérons par exemple l intégration d un environnement virtuel collaboratif (CVE), définissant un monde 3D partagé, et d un outil de navigation Web coopérative. Faisons l hypothèse que nous souhaitons représenter dans le monde 3D ce qui se produit au sein d une session de navigation Web coopérative. Ainsi, par exemple, chaque fois que le groupe accèdera à une nouvelle page Web, on notifiera un événement de type "NEW_URL". Une règle politique pourra ensuite associer la notification de l événement "NEW_URL" à une action demandant au CVE d ajouter un objet 3D (représentant cet URL) dans la scène virtuelle. IV. DEFINITION D UNE SUPERSESSION Dans cette section, nous détaillons le processus de configuration d une Super, en expliquant comment

4 définir une Super et comment spécifier ses règles politiques. La configuration d une Super s effectue donc en deux étapes : (i) la configuration de la gestion de session et (ii) la configuration des politiques de collaboration. A. de la gestion de session Le créateur d'une Super doit configurer deux ensembles d information : GSMinfo (General Management information) qui caractérise la planification de la Super (début et fin en particulier), ses participants et les rôle qu ils jouent. IAinfo (Integrated s information) qui définit la liste des applications intégrées qui seront utilisées au sein de la Super. Pour chaque application, nous définissons une liste de sessions spécifiques, contenant les données spécifiques nécessaires à la création de ces sessions (par exemple, nous définissons l adresse IP multicast d une application de vidéoconférence). B. des politiques de collaboration La politique de collaboration d une Super est responsable de la synchronisation des activités collaboratives réalisées dans les sessions spécifiques des différentes applications collaboratives intégrées au sein de cette Super. Cette politique de collaboration est exprimée au moyen de règles qui mettent en relation, sous certaines conditions, n notifications d événements et m requêtes d exécution d actions. Ces règles sont représentées graphiquement en composant des éléments appelés des policy widgets. Une fois que les règles de collaboration ont été définies, une spécification XML de ces règles est engendrée et attachée au fichier de configuration de la Super. La sémantique des règles de collaboration est définie par traduction dans la technique de description formelle RT-Lotos [13]. Cette sémantique est mise en œuvre par un module spécifique du wrapper. From Type Parameters Predicate Latest Earliest Fig. 2. Illustration des widgets connection points Action To Type Action Parameters La Fig. 2 illustre les cinq widgets utilisés pour créer ces règles politiques. Le widget représente une notification d événement. Le widget Action représente une requête d exécution d action. Chaque événement et chaque action sont associés à une application collaborative et sont typés 1. Le widget Predicate permet de définir des conditions pour sensibiliser les règles politiques. Les widgets Earliest et Latest permettent de composer des notifications d événement lors de la spécification d une règle politique. Avec Earliest, une règle politique est sensibilisée dès qu un des événements spécifiés est notifié. Avec Latest, une règle politique est sensibilisée dès que tous les événements spécifiés sont notifiés. a From: CA1 a:m* b From: CA2 a:m* X: %m X: %m X: %m From: CA1 a:m* b:>10 From: CA2 d:m* t: From: CA1 a:n* m: Fig. 3. Illustrations de Latest et Earliest x: %m To: CA3 y: %c La Fig. 3 présente trois exemples de règles politiques. L exemple (a) illustre une règle simple qui est sensibilisée lorsque l événement spécifié est notifié (si le prédicat associé est vrai lors de la notification de l événement). Dans l exemple (b) une notification d événement et un prédicat sont composés par un Earliest. Dans ce cas, la règle politique dépend d une certaine condition pour être sensibilisée (par exemple, un prédicat portant sur l état de la Super) ; cependant, si un événement particulier est notifié avant que cette condition ne soit satisfaite, la règle politique est également sensibilisée. Dans l exemple (c), nous illustrons une combinaison de Earliest et de Latest. V. DEVELOPPEMENT DE LEICA Nous décrivons ci-dessous l architecture de LEICA en nous appuyant sur l approche d intégration présentée dans la section 3 ; nous détaillons également différents points relatifs à l implémentation du prototype de LEICA en cours de développement. A. Architecture de LEICA Dans le but de décrire les éléments architecturaux essentiels, nous identifions et détaillons les cinq étapes nécessaires pour mettre en oeuvre une Super. a) Intégration d une application collaborative Nous considérons trois types d architecture différents pour c 1 Lorsqu elle est intégrée à LEICA, une application fourni son API événements/actions qui définit ses types d événements et d actions.

5 les applications collaboratives à intégrer dans l environnement LEICA : (i) des applications client/serveur, (ii) des applications multi-serveurs, et (iii) des applications. Lorsque nous intégrons des applications collaboratives client/serveur ou multi-serveurs, nous devons ajouter un (des) wrapper(s) (appelé ) à ce(s) serveur(s). Dans le cas d applications, nous utilisons un. Comme cela est illustré dans la Fig. 4, la différence entre ces deux wrappers concerne l interface aux services Web (WS ), qui est absente dans le deuxième cas. Etant donné que les applications sont en général exécutées de manière dynamique dans les machines hôtes (c est à dire lors de la connexion des utilisateurs), elles ne peuvent pas être disponibles de manière permanente en tant qu un service Web. Pour résoudre ce problème, nous utilisons un Proxy. WS Connector Manager Notification Proxy Connector Manager Fig. 4. Les wrappers de LEICA Notification Dans le but de diminuer les efforts de développement lors de l intégration d applications coopératives, nous avons défini un module particulier, appelé API Factory. Ce module, en s appuyant sur des spécifications XML des APIs d une application, engendre un wrapper adapté à cette application. L adaptation consiste en la création d un sous-module du appelé qui définit toutes les méthodes nécessaires (i.e. celles qui correspondent à l API événements/actions) pour communiquer avec cette application. Le sous-module est le composant du wrapper qui doit être couplé à l application collaborative. Par l intermédiaire de cette interface l application collaborative notifie au wrapper ce qui se passe à l intérieur de son contexte de collaboration, et elle reçoit les requêtes d établissement de sessions spécifiques ainsi que les requêtes d exécution d actions. Le sous-module Manager implémente les fonctionnalités de base du wrapper. Il a la responsabilité (i) de recevoir et traiter les données de configuration des sessions spécifiques ; (ii) de gérer les politiques de collaboration ; (iii) d envoyer les notifications d événement aux autres applications collaboratives. b) Enregistrement d une nouvelle application intégrée Pour s enregistrer auprès de LEICA, comme cela est illustré dans la Fig. 5, le wrapper publie ses services dans un UDDI Registry privé [14]. Pour les applications multi-serveurs, un Master est désigné pour enregistrer l application. Pour les applications, l enregistrement est réalisé par le Proxy. Client/ s Multi- s Master publish publish Private UDDI Registry publish Proxy registry Fig. 5. Enregistrement d applications collaboratives s c) Création de Supers La Fig. 6 illustre les différentes étapes nécessaires pour créer une nouvelle Super. Web Browser 1 HTTP Private UDDI Registry Portal 2 find s Directory 3 4 Proxy s Multi- s Master Fig. 6. Création de nouvelles Supers Client/ s 1. Un portail Web est utilisé pour accéder au service de configuration de session et démarrer le processus de création. 2. Le service de configuration de session accède au UDDI Registry privé pour déterminer quelles sont les applications collaboratives intégrées. 3. Chaque application intégrée est contactée pour lui demander (i) de quelles données spécifiques elle a besoin pour créer des sessions spécifiques, (ii) quels types d événement elle peut notifier et (iii) quels types d action elle peut exécuter. 4. Le détail du processus de configuration correspond à ce que nous avons présenté dans la section 4. A la fin de ce processus de configuration, un fichier de configuration de la Super en format XML est créé et enregistrée. d) Démarrage de Supers La Fig. 7 illustre le démarrage d une Super. 1. Le portail Web est utilisé. 2. Le fichier de configuration de la Super est rapatrié et analysé. Les applications collaboratives qui seront utilisées dans cette Super sont identifiées. 3. Le service de configuration de session contacte les s concernés pour établir des sessions spécifiques et leur envoyer la politique de collaboration (ensemble de règles) de la Super.

6 Web Browser 1 HTTP Portal C 4 3 s Directory 2 Notification System Fig. 7. Démarrage d une Super A Master B 4. Les s sont interconnectés au moyen d un système de notification d événements (les services Web ne sont plus utilisés comme nous l avons justifié auparavant). Le système de notification d événements utilisé par LEICA s appuie sur le paradigme publish/subscribe [15], car un tel schéma d interactions est très bien adapté à des environnements faiblement couplés. En général, les souscripteurs (subscribers) indiquent qu ils sont intéressés à des types particuliers d événement et reçoivent ensuite, de manière asynchrone, les événements qui correspondent à ces types, quelle que soit la source de ces événements (publisher). Après s être connecté au système de notification d événements, chaque wrapper analyse la politique de collaboration pour découvrir: quels types d événement il doit publier et à quels types d événement il doit s abonner. Un wrapper a uniquement besoin de publier des événements qui peuvent sensibiliser des règles politiques, et s abonner à des événements qui peuvent sensibiliser une règle politique définissant une action à exécuter par l application à laquelle il est associé. e) Connexion à une Super Pour se connecter à une Super, les utilisateurs doivent exécuter l application LClient. La Fig. 8 illustre la connexion d un nouvel utilisateur. User host Client B 3 1 LClient D s Directory C 2 4 B Notification System Fig. 8. Connexion d un utilisateur à une Super A Master 1. LClient contacte le service de configuration de session et reçoit en retour GSMinfo, IAinfo, ainsi que la politique de collaboration définie pour la Super sélectionnée. 2. LClient permet de lancer localement les applications et les applications clients. Comme LClient a besoin d exécuter les règles de collaboration pour déterminer quand les applications /client doivent être exécutées, il rejoint le système de notification d événements. 3. Au fur et à mesure que LClient met en œuvre les règles politiques, il exécute les applications /client afin de connecter les utilisateurs aux sessions spécifiques. Ainsi, dans la Fig. 8, LClient n exécute que les applications "B" et "D" ; 4. Les wrappers des applications se connectent au système de notification d événements et exécutent le même processus publish/subscribe que celui décrit pour le (comme le fait l application dans la Fig. 8). B. Problèmes de conception et d implémentation De manière à obtenir une implémentation concise et correcte de LEICA, nous avons formalisé les éléments architecturaux de LEICA et avons dans ce but utilisé l outil de modélisation UML TAU G2 de la société TeleLogic [16]. Nous avons adopté une démarche de type top-down pour le processus de conception. Nous avons ainsi décomposé les éléments architecturaux et défini les comportements de chaque sous-composant. Nous avons effectué des simulations avec TAU G2 pour valider le modèle UML de LEICA. La Fig. 9 montre deux diagrammes d architecture UML : le premier représente l environnement LEICA dans son ensemble et le second détaille le composant. LEICASystem Architecture padmin conf : Config clt : client::lclient puser pw pd Architecture active class {1/1} reg : UDDIRegistry p4 p3 ps ws:ws[0..1] active class LEICASystem {1/1} pw pu svr: [2] p serverapp : pw appint : Connector pa pu sessionmanager:manager pd evtnot: EvtNotification pd evtnot:not Fig. 9. Diagrammes d architecture UML de LEICA En s appuyant sur le modèle UML, nous avons développé un premier prototype de LEICA en utilisant Java comme technologie sous-jacente ainsi que des APIs Java particulières pour implémenter les interactions avec les services Web : Apache juddi pour implémenter le UDDI Registry; UDDI4J (de IBM), utilisé par le 's WS et le Proxy pour interagir avec le UDDI Registry Apache Jakarta Tomcat 5.0 et Apache pour ps

7 interagir avec le service de configuration de session ; le LClient utilise également Apache 2.3 pour contacter le service de configuration de session. Nous utilisons l infrastructure Scribe [17] pour mettre en oeuvre le système de notification d événements. Scribe est un système écrit en Java qui met en oeuvre une approche publish/subscribe à grande échelle et en pair à pair. Scribe propose également un service efficace de multicast au niveau applicatif. VI. CONCLUSIONS ET TRAVAUX FUTURS Dans cet article, nous avons présenté LEICA, un environnement faiblement couplé pour intégrer des applications collaboratives. Des applications collaboratives existantes peuvent ainsi être intégrées en utilisant les services Web comme technologie d intégration. Dans le contexte d une Super, nous pouvons ainsi développer une activité collaborative globale constituée de différentes applications intégrées utilisées en parallèle et de manière coordonnée. En s appuyant sur la spécification de politiques de collaboration, LEICA définit le comportement des applications en réponse à des notifications d événements. Pour tester le prototype de LEICA, nous sommes en train d intégrer actuellement deux applications : un outil de navigation coopérative sur le Web définissant une API (CoLab [18]) et un outil open source de chat multi-salons (Babylon [19]). Par la suite, nous intégrerons d autres applications qui définissent des APIs (comme par exemple, Skype). L implémentation actuelle de notre prototype confirme le fait que des applications collaboratives open source permettent des niveaux d interaction plus élaborés étant donné que nous disposons dans ce cas de toute la flexibilité nécessaire pour attacher des wrappers aux applications. Cependant, comme de plus en plus de logiciels sont aujourd hui rendus disponibles avec des spécifications d API (qui s appuient d ailleurs parfois sur des services Web), leur intégration à LEICA a tendance à être simple. Différentes expérimentations doivent être réalisées sur ce prototype pour évaluer les temps de réponse de LEICA en fonction des performances du système de notification d événements et de celles du module d exécution des règles politiques. Le passage à l échelle de l approche proposée devra également être vérifié. En ce qui concerne les services Web, un effort important a été déployé dans le but de proposer des solutions pour optimiser la transmission et le codage de messages. Dans cette perspective, le système de notification d événements actuel de LEICA pourrait devenir un système s appuyant sur un service Web sans souffrir des problèmes de performance inhérents actuellement à. REFERENCES [1] Web s Activity. [2] Dewan, P. "An experiment in interoperating heterogeneous collaborative systems". 6th European Conference on Computer Supported Cooperative Work, Copenhagen, Denmark, [3] Iqbal, R., James, A., Gatward, R. "A practical solution to the integration of collaborative applications in academic environment". 5th International Workshop on Editing Systems, Helsinki, Finland, [4] Spellman, P. J., Mosier, J. N., Deus, L. M., Carlson, J. A. " virtual workspace". International ACM SIGGROUP Conference of Supporting Group Work, ACM Press, p.p , Phoenix, [5] Fuchs, L. "AREA: a cross-application notification service for groupware". 6th European Conference on Computer Supported Cooperative Work, Copenhagen,Denmark, [6] Prinz, W. "NESSIE: an awareness environment for cooperative settings". 6th European Conference on Computer Supported Cooperative Work, Copenhagen, Denmark. Kluwer Academic Publishers, [7] Fox, G. et al. "A Web services framework for collaboration and videoconferencing". Workshop on Advanced Environments, Seattle, Washington, [8] Orfali, R., Harkey, D. "Client/server programming with Java and CORBA". Wiley, NewYork, [9] DCOM: [10] Roman, E., Ambler S.W.: Jewell T Mastering Enterprise, JavaBeans. Wiley, NewYork, [11] Alonso, G., Casati, F., Kuno, H., Machiraju, V. "Web s" (chapter 5). In Web s Concepts, Architectures and s, Springer Verlag, [12] Skype website. [13] Courtiat, J.P., Santos, C.A.S, Lohr, C., Benaceur, O. "Experience with RT-LOTOS,a temporal extension of the LOTOS formal description technique". Computer Communications, v.23, n.12, pp , July [14] UDDI: [15] Eugster, P., Felber, P., Guerraoui, R., Kermarrec, A.-M. "The many faces of publish/subscribe". ACM Computing Surveys, v.35, i.2, pp , [16] Telelogic s TAU Generation2: [17] Castro, M., Druschel, P., Kermarrec, A.-M., Rowstron, A. "Scribe: A large-scale and decentralized application-level multicast infrastructure. IEEE Journal on Selected Areas in Communications (JSAC), 20(8), [18] Hoyos-Rivera, G.J., Gomes, R.L., Courtiat, J.P. "CoLab: a flexible collaborative web browsing tool". The IEEE 19th International Conference on Advanced Information Networking and s (AINA 2005). Tamkang University, Taiwan, March [19] Babylon: