LEICA : un environnement faiblement couplé pour l’intégration d’applications collaboratives

LEICA : un environnement faiblement couplé pour
l’intégration d’applications collaboratives

Classification des applications collaboratives

Il est difficile de définir une classification (ou taxonomie) unifiée des applications de TCAO. En plus de la grande diversité du domaine, chaque classification peut privilégier un aspect particulier. Nous avons ainsi choisi de présenter deux classifications considérées comme incontournables dans la littérature du domaine : l’une concerne des caractéristiques temporelles et spatiales, et l’autre la catégorie fonctionnelle de l’application.

La classification espace-temps

L’espace et le temps constituent les dimensions les plus courantes dans les classifications d’applications collaboratives . La première dimension, l’espace, concerne la distance géographique séparant les utilisateurs de l’application. Par exemple, les membres d’une réunion peuvent se trouver dans une même pièce ou être carrément situés dans des lieux distants (des bâtiments, des villes, ou bien même des pays différents). La dimension temporelle caractérise plutôt le type d’interaction entre utilisateurs. Les membres du groupe peuvent interagir en même temps et en direct (les actions d’un participant sont immédiatement transmises aux autres), ce qui définit une collaboration synchrone. Dans ce cas, des problèmes de synchronisation et de gestion de la concurrence se posent. Il faut en effet résoudre les problèmes de conflit induits par exemple lors de modifications simultanées et contradictoires réalisées sur une même donnée. Si une gestion de la concurrence n’est pas mise en place, il est fort probable que des conflits et des incohérences se produiront dans le déroulement de l’application. Les problèmes de contrôle de concurrence et de synchronisation ont été beaucoup étudiés : dans le domaine des systèmes répartis conventionnels et dans le domaine du TCAO (où des problèmes d’ordre humain s’ajoutent aux problèmes techniques) .LEICA : Un environnement faiblement couplé pour l’intégration d’applications collaboratives 9 Outre la collaboration synchrone, les membres d’un groupe peuvent également agir à des instants différents, c’est-à-dire, les actions sont espacées dans le temps. Il s’agit alors d’une collaboration asynchrone. Dans ce cas, il est important que l’état de l’activité soit conservé en permanence afin que les membres du groupe soient capables d’observer l’historique des actions qui ont été effectuées avant leur arrivée. interaction face à face instants différents interaction synchrone repartie interaction asynchrone repartie interaction asynchrone même instant même lieu lieux différents Figure II.1 La matrice espace-temps La Figure II.1 illustre la “matrice espace-temps”, ou encore matrice de Johansen [Johansen-88]. De nombreuses critiques ont été suscitées vis-à-vis de cette classification traditionnelle (de plus en plus les applications tendent à couvrir plusieurs quadrants) et plusieurs propositions ont été développées pour affiner cette classification [Grudin-94].

Les catégories fonctionnelles d’applications de TCAO

Beaucoup d’auteurs choisissent d’élaborer une classification par domaines d’application, où une liste de catégories fonctionnelles est définie pour regrouper les applications de TCAO [Bernard-04] [Laurillau-02] [Terzis-99]. Par la suite, nous présentons, à titre d’exemple, une liste non exhaustive de catégories d’applications collaboratives les plus souvent référencées : • Courrier électronique (courriel) – Cette catégorie de collecticiels représente de loin le moyen de communication asynchrone le plus répandu et le plus utilisé de nos jours. Le courriel désigne le service de transfert de messages envoyés via Internet vers la boîte aux lettres électronique des destinataires choisis par l’émetteur. Une adaptation de ce service de messagerie a connu un grand succès dans le monde de la téléphonie mobile, appelé SMS (de l’anglais Short Messaging Services). • Messagerie instantanée et le forum de discussion – Comme le courrier électronique, ces deux types de systèmes sont dédiés à la communication par échange de messages. Dans le premier cas (également appelé Chat), contrairement au courrier électronique, la communication est conçue pour être instantanée, i.e. synchrone. Le deuxième type de système représente des lieux (normalement des sites Web) où les individus peuvent partager leurs connaissances/expériences par des échanges de messages de manière asynchrone. La plupart des forums sont organisés en fils de discussion où un message ou un thème initial détermine un premier fil de discussion. L’ensemble des discussions est généralement visible par les participants, et éventuellement par tous les internautes. Les deux classes principales de forum de discussion sont les newsgroups et les bulletin boards (ou tableaux d’affichage). • Gestion de flux de processus – Connue en anglais sous le nom de workflow management, cette catégorie représente des systèmes dédiés à la gestion de processus (industriels, commerciaux, administratifs, etc.) et à la coordination des différents intervenants au cours d’un processus . Également dénommé gestionnaire de procédés, il est souvent défini comme un outil qui prend en charge les documents en cours d’élaboration liés à des procédures et au routage des données. Ces systèmes sont très souvent utilisés par des entreprises dans le but de coordonner les taches exécutées par différents secteurs.

Système d’aide à la décision – Les GDSS (de l’anglais Group Decision Support Systems) sont conçus pour faciliter la prise de décisions en implémentant un sorte de salle de réunion électronique apportant de nombreux outils (par exemple votes, annotation d’idées, brainstorming, etc.) [Mora-02]. L’anonymat et le droit de parole sont des fonctionnalités normalement mises en oeuvre dans ces systèmes pour encourager les utilisateurs à s’engager dans le processus de prise de décision.
Outil de partage d’application – Ce type de logiciel permet à plusieurs utilisateurs (travaillant sur des ordinateurs différents) d’utiliser simultanément une application hébergée sur un seul ordinateur (normalement représenté par un serveur). Cette fonctionnalité est très souvent implémentée en déportant la fenêtre partagée (voire tout le bureau [Richardson-98]) vers les machines des autres utilisateurs. • Editeur partagé – Ces systèmes d’édition conjointe (de l’anglais shared editing [Prakash-99]) permettent à un groupe d’utilisateurs d’éditer collectivement un document partagé. Ils peuvent être utilisés de façon synchrone ou asynchrone, et ils offrent en général des mécanismes de gestion de versions. Mais la principale complexité de ces systèmes concerne la gestion des tâches concurrentes [Lorcy-00], lorsque des utilisateurs modifient un même document simultanément.
Tableau blanc partagé – Le système de tableau blanc partagé, comme son nom l’indique, met à disposition une surface de dessin accessible par plusieurs utilisateurs. Il permet ainsi à des utilisateurs de travailler d’une manière synchrone sur des documents 2D. Il est par exemple possible de réaliser des captures d’écran pour les annoter dans le but d’expliquer une idée ou un concept [Kam-05].
Audioconférence – Les outils d’audioconférence permettent aux utilisateurs de parler à plusieurs. Si d’un coté la qualité de transmission joue un rôle important pour la compréhension de la communication, les flux audio ne consomment pas énormément de bande passante. La communication audio est l’un des moyens de communication le plus riche au niveau signifiant, mais l’utilisation d’un système d’audioconférence à plusieurs comme seul moyen de communication peut entraîner des difficultés dans l’identification des interlocuteurs [Kilgore-03].
Vidéoconférence 1 – Ces systèmes permettent aux utilisateurs distants de se réunir et communiquer par l’intermédiaire d’un support audio et vidéo en même temps. Si la vidéo peut donner une sensation de présence plus forte que l’audioconférence seule, une vidéoconférence nécessite de disposer d’une bande passante capable de diffuser et recevoir des données audio et vidéo avec une qualité acceptable. Dans [Tang-92] les auteurs suggèrent que, l’audio ayant un rôle plus important que la vidéo pour supporter la collaboration, les systèmes de vidéoconférence ont intérêt à dégrader en priorité la vidéo pour le bénéfice de la qualité de l’audio.

Table des matières

Avant-propos
Table des figures
Chapitre I Introduction générale
. 1 I.1. Contexte général
1 I.2. Problématique abordée
1 I.3. Principales contributions de la thèse 3 I.4. Plan de thèse Chapitre II État de l’art II.1. Introduction II.2. TCAO : Concepts et classifications II.2.1. Quelques concepts fondamentaux II.2.1.1. La coopération et la collaboration II.2.1.2. La télé-présence II.2.1.3. La session et les artéfacts de travail II.2.2. Classification des applications collaboratives II.2.2.1. La classification espace-temps II.2.2.2. Les catégories fonctionnelles d’applications de TCAO9 II.3. Développement de systèmes de TCAO II.3.1. Quelques difficultés II.3.1.1. La flexibilité, l’extensibilité et la malléabilité II.3.2. Les approches de développement II.3.2.1. Développement from scratch II.3.2.2. Développement s’appuyant sur des boîtes à outils II.3.2.3. Développement s’appuyant sur des frameworks et des plates-formes II.4. Vers l’intégration d’applications collaboratives existantes

II.4.1. Motivations II.4.2. Plates-formes et environnements généraux d'intégration

II.4.2.1. Les intergiciels conventionnels a) CORBA b) DCOM c) Java RMI II.4.2.2. Enterprise Application Integration II.4.2.3. Les services Web II.4.2.4. Bilan des solutions générales d’intégration II.4.3. Plates-formes et environnements pour l’intégration d’applications collaboratives II.4.4. Positionnement de notre proposition Chapitre III L’Approche d’intégration initiale III.1. Introduction III.2. CIE : l’environnement d’intégration collaboratif III.2.1. Les contraintes des CVEs conventionnels III.2.2. Le cadre général d’intégration III.2.3. L’architecture de base III.3. Implémentation de l’environnement d’intégration collaboratif III.3.1. Implémentation des modules de l’architecture III.3.2. Le fichier d’initialisation III.3.3. L’extensibilité de l’environnement III.4. Conclusions Chapitre IV L’environnement d’intégration : LEICA IV.1. Introduction IV.2. Approche générale d’intégration IV.2.1. Scénarios d’intégration IV.2.1.1. Outil de navigation coopérative enrichi d’un outil de messagerie instantanée (Chat) IV.2.1.2. Réunions virtuelles IV.2.1.3. E-learning IV.2.2. Cadre général d’intégration IV.3. Description d’une SuperSession IV.3.1. Modèle de SuperSession IV.3.1.1. Applications collaboratives IV.3.1.2. Applications non collaboratives IV.3.1.3. Rôles généraux IV.3.1.4. Utilisateurs connectés IV.3.1.5. Sessions spécifiques IV.3.2. Illustration d’une SuperSession IV.4. Création d’une SuperSession IV.4.1. Configuration des informations de gestion IV.4.1.1. GSMinfo IV.4.1.2. IAinfo IV.4.2. Spécification des politiques de collaboration IV.4.2.1. Types de notification d’événement et de requêtes d’exécution d’action IV.4.2.2. La définition des règles de collaboration : les policy widgets IV.4.2.3. Exemples de règles IV.4.2.4. Formalisation de la sémantique des règles politiques

IV.5. Conclusion Chapitre V L’architecture de LEICA V.1. Introduction V.2. Architecture : de l’intégration des applications à l’exécution d’une SuperSession V.2.1. Intégration d’une application collaborative à LEICA

V.2.1.1. Création dynamique d’un Wrapper V.2.1.2. Couplage du Wrapper àl’application V.2.1.3. Enregistrement d’une application V.2.2. Configuration d’une SuperSession V.2.2.1. Configuration du GSMinfo et découverte des applications intégrées à LEICA V.2.2.2. Choix et configuration des applications collaboratives V.2.2.3. Spécification de la politique de collaboration V.2.3. Exécution d’une SuperSession V.2.3.1. Démarrage d’une SuperSession V.2.3.2. Connexion des utilisateurs à la SuperSession LEICA: Un environnement faiblement couplé pour l'intégration d'applications collaboratives V.2.3.3. Les notifications d’événement et l’exécution de la politique de collaboration V.2.3.4. Gestion de l’état global d’une SuperSession V.2.4. Les incohérences potentielles dues à la répartition

V.2.4.1. La gestion d’un état global cohérent et l’exécution repartie de la politique de collaboration .87 V.2.4.2. Les incohérences en présence de contraintes temporelles88 V.2.4.3. Autres incohérences concernant l’exécution des règles politiques : la problématique des applications multiserveurs et P2P .89 V.3. Modélisation de LEICA en UML V.3.1. Introduction à UML 2.0 V.3.2. Méthode de modélisation utilisée V.3.3. Modélisation en UML de l’architecture de LEICA V.3.3.1. L’analyse : les cas d’utilisation et les diagrammes de séquences de LEICA V.3.3.2. La conception : les diagrammes de classes et de structures composites V.3.3.3. Comparaison des scénarios engendrés par Tau G2 à ceux initialement proposés dans le cas des applications client/serveur .99 V.4. Conclusion Chapitre VI Implémentation et déploiement de LEICA VI.1. Introduction VI.2. Les choix technologiques VI.2.1. Les services Web VI.2.2. Le paradigme publish/subscribe VI.2.2.1. Pastry et Scribe VI.3. Principaux modules du prototype VI.3.1. APIFactory VI.3.2. Server Wrapper VI.3.2.1. La mise en place du système de notification d’événements VI.3.2.2. Le PolicyManager et l’exécution de la politique de collaboration VI.3.3. Session Configuration Service VI.3.4. LClient

VI.4. L’intégration d’outils de collaboration et déploiement de LEICA VI.4.1. CoLab VI.4.2. Babylon Chat1 VI.4.3. La SuperSession “CoLabPlusChat” VI.4.4. L’environnement d’exécution VI.4.5. Quelques considérations sur le prototype a) L’intégration faiblement couplée b) L’utilisation des technologies de services Web c) Le système de notification d’événements d) L’exécution de la politique de collaboration VI.5. Conclusions Chapitre VII Conclusion générale et perspectives VII.1. Bilan des travaux réalisés VII.2. Les perspectives de nos travaux Annexe A Le “fichier de données spécifiques” et le “fichier d’attributs et d’API” A.1. Le format du fichier de données spécifiques A.2. Le format du fichier d’attributs et d’API A.2.1. L’élément A.2.2. L’élément A.2.2.1. Les éléments A.2.2.2. L’élément A.2.3. Les événements et les actions de l’API de gestion Annexe B Le “fichier de configuration de la SuperSession” B.1. L’élément B.2. L’élément B.3. L’élément B.3.1. L’élément B.3.2. Les éléments et B.3.3. L’élément Références bibliographiques Publications de l’auteur Bibliographie Références Web