Les catégories fonctionnelles d’applications de TCAO

Télécharger le fichier pdf d’un mémoire de fin d’études

TCAO : Concepts et classifications

Dans les années 80, l’utilisation de l’informatique pour gérer la coopération entre membres d’un groupe (travaillant ou pas en même temps, et ou non dans un même lieu) a constitué une révolution concernant le travail coopératif [Cosquer-99]. Cette révolution est à l’origine du domaine intitulé “Travail Coopératif Assisté par Ordinateur”, ou TCAO (de l’anglais Compurter Suported Cooperative Work, ou CSCW1). L’objet du TCAO est en substance d’adapter ces technologies aux besoins des utilisateurs impliqués dans des activités de groupe.
Les systèmes informatiques, élaborés dans le cadre de la recherche en TCAO, permettant à des groupes d’utilisateurs de collaborer à des buts communs sont qualifiés en anglais de groupware. La traduction française couramment utilisée pour ce terme est “collecticiel” [Lévy-90]. En fait, la pluridisciplinarité du TCAO rend difficile la définition de ces systèmes. Une définition assez courante que nous devons à Ellis [Ellis-91] a été traduite par Karsenty [Karsenty-94] de la façon suivante : “Système informatique qui assiste un groupe de personnes engagées dans une tâche commune (ou but commun) et qui fournit une interface à un environnement partagé”.
Collecticiel est également la traduction officielle adoptée par l’Association Française pour la Cybernétique Économique et Technique 1 (ASTI) [ASTI]. Mais très souvent, nous rencontrons également les termes “système collaboratif”, “système de TCAO” ou encore “application collaborative” pour désigner le groupware. Pour notre part, nous n’emploierons par la suite que les termes “collecticiel” ou “application collaborative” pour désigner ces systèmes informatiques.
Le TCAO est un domaine multidisciplinaire qui concerne, entre autres, les systèmes répartis, l’interface homme-machine, l’automatisation du bureau, etc . Cette multidisciplinarité entraîne une grande diversité d’applications qui assistent des groupes d’individus à accomplir des tâches communes. Par conséquent, nous trouvons des divergences importantes parmi les concepts et classifications proposés dans la littérature au sujet des applications collaboratives.

Quelques concepts fondamentaux

Malgré la diversité des applications, nous arrivons à identifier certains concepts fondamentaux que les collecticiels doivent s’efforcer de prendre en compte afin que les tâches coopératives puissent se dérouler correctement. Bien évidemment, pour qu’un collecticiel soit accepté, il faut qu’il offre à ses utilisateurs de bonnes conditions de travail en coopération.

La coopération et la collaboration

Les termes “coopération” et “collaboration”, et les concepts qu’ils représentent, sont important dans notre présentation. Néanmoins, leur distinction devient rapidement difficile. Dans la littérature ces deux termes sont très souvent utilisés comme synonymes. Les dictionnaires ne nous aident pas vraiment dans cette tâche : une des définition pour “collaborer” étant “coopérer”.
Dans les travaux de Ellis [Ellis-94], nous trouvons cependant une distinction entre ces deux termes. Son “modèle des 3C” cherche à caractériser la coopération en trois niveaux distincts, selon l’intensité des relations établies entre les individus et les tâches réalisées : la communication, la coordination, et la collaboration. La communication représente le niveau de coopération le plus lâche, la coordination un niveau intermédiaire, et la collaboration représente le niveau de coopération où les tâches sont les plus imbriquées et fortement liées.
Dans “le modèle du trèfle fonctionnel” [Graham- 99] [Lonchamp-03] nous trouvons une classification plutôt fonctionnelle qui n’insiste pas sur une distinction entre coopération et collaboration. La notion de coopération est caractérisée par trois axes ou fonctions principales : la communication, la coordination, et la production. La communication correspond à l’échange direct d’informations entre les membres d’un groupe. La coordination consiste à définir les règles d’interaction pour contrôler la contribution des membres du groupe qui participent à un travail commun. La production est caractérisée par le partage d’un espace où les membres peuvent stocker, traiter et partager un ou plusieurs objets communs. Dans [Graham-99], le lecteur trouvera plus de détails concernant les fonctionnalités relatives à chacun de ces trois axes.
Nous prenons en conséquence le parti de considérer les termes de coopération et de collaboration comme étant synonymes, comme l’usage commun et scientifique semblent l’avoir montré.

La télé-présence

La télé-présence, ou notion de présence, représente la conscience (de l’anglais awareness) commune dans un travail de groupe qui permet de définir le contexte dans lequel le travail se réalise. Cette conscience de groupe correspond à la compréhension que chacun a sur : (i) avec qui il travaille, (ii) l’activité de chacun et (iii) la manière dont les actions de chacun interagissent [Dourish-92].
Dans un collecticiel, à la différence d’une application mono-utilisateur, plusieurs personnes peuvent agir en même temps sur les mêmes artefacts de travail. Dans un tel environnement partagé, les acteurs n’ont pas spontanément connaissance des actions des autres. Ainsi la conscience des activités individuelles et des activités du groupe s’avère une information critique pour rendre possible le succès de la collaboration. Elle peut présenter des avantages tels que : la réduction de l’effort de coordination des actions ; l’anticipation des actions des autres; ou même l’aide à des personnes pour s’intégrer aux activités [Gutwin-02].
Selon l’analyse détaillée de Dix [Dix-97], la notion de télé-présence se décline sous trois formes :
• conscience de la présence des membres du groupe et de leur disponibilité dans le travail coopératif ;
• conscience des actions réalisées par les membres du groupe ;
• conscience des effets consécutifs à ces actions.
Ainsi, la télé-présence, sous ses différentes formes, permet de contrôler les comportements de chaque participant. En effet, pour pouvoir travailler ensemble il est indispensable d’une part d’être conscient de la présence des autres participants et d’autre part d’être au courant de leur travail.

La session et les artéfacts de travail

Le concept de session est généralement utilisé en TCAO pour structurer et organiser le travail de groupe. Dans [Haake-99] les auteurs définissent une session par :
• un groupe d’utilisateurs (ou des agents logiciels les représentant) ;
• un espace de travail commun dans lequel les utilisateurs agissent et manipulent des artéfacts de travail ;
• un mode de coopération spécifique exploité par ces utilisateurs.
Ainsi, l’application collaborative doit fournir des opérateurs permettant de gérer une session, tels que créer et détruire une session ; joindre et quitter une session ; et sélectionner ou modifier les modes de coopération, ainsi que les modes de manipulation des artéfact de travail.
La manipulation d’artéfacts évoque la manipulation d’objets physiques que l’on déplace ou modifie sur un bureau réel, comme par exemple déplacer un livre, écrire sur une feuille, utiliser son téléphone, etc. Ce concept vise ainsi à déterminer comment les collecticiels peuvent mettre en œuvre le partage d’artefacts de travail (i.e. des objet virtuels, des documents, des outils, etc.). Le concept de “bureau virtuel” ou d’ “espace partagé” (de l’anglais shared workspace) correspond à une des notions les plus répandues dans l’organisation d’artefacts de travail tels que des documents et des outils partagés nécessaires aux tâches à être exécutées par le groupe [Dourish-92] [Gutwin-02] [Pinelle-03]. Un bureau virtuel est en fait une instanciation de la métaphore de la pièce, ou the room metaphor, décrite en détail dans [Greenberg-02].
Certaines applications collaboratives doivent offrir des fonctionnalités pour contrôler l’accès concurrent aux artefacts de travail partagés. Très souvent ce contrôle est mis en œuvre par un mécanisme de passage de main (connu en anglais sous le terme de floor control [Dommel-99]) qui permet à des utilisateurs de prendre la main (ou le floor) à distance sur une application partagée.

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 [Ellis-91].
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) [Munson-96] [Prakash-99] [Yang-04].
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.

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 [Aslst-02] [Ellis-99]. É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) [Ahuja-90] [Begole-99]. 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.
• Agenda partagé – Également connu comme calendriers partagés (de l’anglais group calendars [Palen-03]), ces systèmes permettent de résoudre des problèmes concernant la planification de tâches. Normalement ces systèmes incluent des fonctionnalités telles que la détection d’incompatibilités dans la planification d’une tâche ou la détermination de plages horaires communes aux membres d’un groupe. Cela permet, par exemple, à l’organisateur d’une réunion d’avoir une vision claire de la disponibilité des acteurs d’un projet.
• Environnement collaboratif virtuel – Les CVEs (de l’anglais Collaborative Virtual Environments) représentent une catégorie importante de systèmes de TCAO qui fournissent des facilités de collaboration à travers l’implémentation d’un espace virtuel réparti. L’espace virtuel peut être représenté par de simples environnements textuels, comme dans le cas des environnements Multi-User Dimension (MUD) tel que MOOSE Crossing [Bruckman-97]. Mais très souvent il s’appuie sur de riches scènes 3D partagées (ce qu’on appelle des mondes virtuels), comme par exemple [Activeworlds] et [Blaxxun]. L’utilisation de la réalité virtuelle est encouragée à cause de sa capacité importante de modélisation et d’interactivité, permettant aux CVEs de résoudre plusieurs problèmes concernant les applications de TCAO : (i) la notion de présence ; (ii) la représentation des métaphores du monde réel (des gestes humains) et des objets (simulations en 3D) ; (iii) la réduction des coûts de transmissions à travers le réseau (notamment par rapport aux systèmes de vidéoconférence).
• Plate-forme collaborative – Cette catégorie spéciale de collecticiels représente en fait des applications qui rassemblent dans un même environnent intégré différents outils associés aux catégories précédentes. Par ailleurs, pour Schmidt et Rodden [Schmidt-96], le caractère dynamique du travail coopératif et ses articulations sont tels que les efforts devraient se tourner vers la mise au point de ces plates-formes fournissant un large éventail de support pour le TCAO : support de partage et d’échange d’information (partage d’application, éditeur partagé, etc.) ; support pour la communication (messagerie instantanée, vidéoconférence, etc.) ; support pour la prise de décisions, etc.

Développement de systèmes de TCAO

Dans cette section nous allons analyser différentes approches qui ont été employées pour la conception de collecticiels. Nous aborderons d’abord des difficultés d’ordre général pour le développement d’applications collaboratives. Nous passerons ensuite à une description et analyse des approches généralement utilisées dans le développement des collecticiels.

Quelques difficultés

Qu’il s’agisse d’outils pour la communication médiatisée, pour la gestion de contextes coopératifs, de gestionnaires de procédés, etc., l’objectif commun est de fournir un système capable de supporter et de répondre au mieux aux besoins des utilisateurs tout en encourageant la coordination et la gestion des artefacts de travail partagés. Si nous reprenons le modèle du trèfle fonctionnel (voir section II.2.1.1), les trois axes caractérisant la coopération impliquent qu’une application collaborative doit supporter à la fois des mécanismes pour la communication, pour la coordination et pour la production collaborative.
Il ne faut pas oublier qu’il s’agit de supporter des interactions dirigées par des utilisateurs. Ainsi, les collecticiels doivent prendre également en compte des aspects plus “humains” de la coopération tels que la gestion d’un groupe de personnes et la télé-présence. De plus, différentes équipes et organisations exécutant différentes tâches, demandent autant de fonctionnalités différentes [Haake-99].
Compte tenu de tous ces aspects et contraintes à prendre en compte, c’est bien naturel que les collecticiels rencontrent toujours des difficultés à atteindre une acceptation importante de la part de vrais groupes de travail [Palen-03]. Nous retrouvons en fait, à l’origine de cet échec, la façon dont les personnes travaillent généralement en groupe, qui, comme cela est signalé dans [Hummes -00], n’est pas tout à fait prévisible. Par conséquent, il est pratiquement impossible pour les concepteurs/développeurs de collecticiels de prédéfinir par anticipation les besoins réels des utilisateurs vis-à-vis des artefacts de collaboration nécessaires au support du travail en groupe. Ainsi, selon Hummes, “un système collaboratif doit permettre la création et l’insertion de nouveaux modules et artefacts coopératifs”. Il faut donc que les développeurs conçoivent les applications collaboratives tout en prenant en compte les problèmes liés à l’intégration des nouvelles fonctionnalités qui n’ont pas été prévues à l’avance, mais qui s’avèrent nécessaires pendant le déroulement du travail. En vérité, depuis longtemps plusieurs auteurs (par exemple [Edwards-96], [Malone-95], [Roseman-93], [Shen-02] et [Wang-00]) définissent cette capacité de permettre au système de s’adapter à des besoins particuliers, caractéristique couramment appelée flexibilité, et considérée comme indispensable en TCAO. Effectivement, étant donné que les activités collaboratives impliquent plusieurs personnes qui expriment souvent des besoins de travail en groupe différents et parfois imprévisibles, il est fort probable que des systèmes plus flexibles soient mieux acceptés par les utilisateurs [Kahler-00].

La flexibilité, l’extensibilité et la malléabilité

Nous trouvons souvent deux autres propriétés associées à la flexibilité : (i) l’extensibilité, qui selon une définition générale, privilégie l’ajout de nouveaux comportements aux systèmes, soit par l’intégration de nouveaux modules ou composants, soit par l’extension des modules/composants existants dans l’application [terHofte-98] ; et (ii) le tailoring [Dourish-96], traduit en français par “malléabilité” [Bourguin-00], qui définit des notions d’adaptabilité et de flexibilité pour les utilisateurs finaux (ou à un responsable plus expérimenté, tel qu’un administrateur).
Mørch [Mørch-97] distingue trois formes de malléabilité : le paramétrage, l’intégration et l’extension de l’application. Le paramétrage permet de sélectionner une ou plusieurs valeurs pour certains paramètres d’une application afin de la spécialiser. Quant à la distinction entre intégration et extension, Mørch insiste que l’extensibilité est associée à la possibilité d’étendre une application en modifiant des parties spécifiques de cette application, pour qu’elle puisse répondre à des besoins provenant de l’utilisateur ; l’intégration, quant à elle, se limite à l’ajout et à la composition de nouveaux modules ou composants à l’application.
Nous avons décidé d’emprunter la notion d’extensibilité dans le sens plus général du terme (telle qu’elle est présentée dans [terHofte-98]). Ainsi, une application peut être également étendue par le biais de l’intégration de nouvelles fonctionnalités sous la forme de nouveaux composants, modules ou d’autres applications.

les approches de développement

Tout en essayant de prendre en compte ces différents aspects, conséquences de la diversité intrinsèque au domaine du TCAO, différentes approches ont été utilisées dans le développement d’applications collaboratives. Nous allons par la suite décrire ces approches tout en identifiant comment elles peuvent influencer l’acceptation des applications (développées selon ces approches) au sein de véritables groupes de travail.

Développement from scratch

Le développement from scratch1 concerne la conception complète de nouveaux systèmes de TCAO “à partir de rien”, c’est-à-dire, sans faire appel à des composants ou des sous- systèmes implémentant des fonctionnalités générales ou spécifiques. Le principal avantage de cette approche est que le développeur est libre de prendre ses propres décisions concernant la spécification, la modélisation et l’implémentation de l’application.
Puisque ces systèmes représentent souvent des solutions propriétaires ne s’appuyant pas sur des modèles de conception ouverts, ils risquent fort de présenter les inconvénients classiques des applications fermées : non-standardisation, manque de flexibilité et d’interopérabilité. En outre, le fait de développer tout un système sans faire appel à des solutions pré-existantes peut conduire à “ré-inventer” la roue, sans parler de l’augmentation des coûts et de la fiabilité, probablement inférieure, du système. Finalement, puisque toutes les fonctionnalités collaboratives ont été statiquement imbriquées dans l’application, cela peut représenter une vraie surcharge architecturale étant donné que certaines fonctionnalités peuvent même ne pas être utilisées.
Il s’agit d’une approche en général utilisée pour le développement d’applications qui ne présentent pas trop de complexité vis-à-vis du nombre de fonctionnalités collaboratives offertes (par exemple CoLab [Hoyos-05b], Skype [Skype], Shared Calendar [SharedCalen], etc.). Or, nous trouvons également des plates-formes collaboratives, surtout dans le domaine commercial, qui ont été développées selon cette approche (par exemple KnowEdge eLearning Suite [KnowEdge], Groove Virtual Office [Groove], Avilar WebMentor [WebMentor], etc.).

Développement s’appuyant sur des boîtes à outils

Une boîte à outils (de l’anglais toolkit) est une bibliothèque de composants logiciels en charge de gérer des structures de données et de réaliser des opérations communes pour le développement d’applications. Ces composants sont en général accessibles par un programme via des appels procéduraux. L’objectif d’une boîte à outils est ainsi de fournir un cadre de programmation adéquat pour implémenter certaines parties d’une l’application tout en réduisant l’effort de programmation. Nous nous intéressons aux boîtes à outils dédiées au développement de collecticiels (groupware toolkit ou CSCW toolkit). Il s’agit d’environnements qui fournissent un ensemble d’éléments (outils) implémentant des services spécialisés généralement requis pour la coopération.
L’approche de développement s’appuyant sur des boîtes à outils, comparée à l’approche de développement from scratch, présente l’avantage de réduire le coût de développement et de faciliter le prototypage rapide de nouveaux collecticiels. Par ailleurs, l’utilisation d’une boîte à outils permet de concevoir des collecticiels variés et adaptés aux besoins des utilisateurs, tout en gardant un environnement homogène (notamment en terme d’interface graphique), ce qui peut faciliter leur utilisation [Laurillau-02].
Une propriété importante de ces types de systèmes est le bas niveau d’extensibilité qu’ils peuvent offrir aux développeurs. Dans le cas de boîtes à outils plus spécialisées, comme SDGToolkit [Tse-04], qui est un toolkit dédié au SDG (Single Display Groupware), ou Collabrary [Boyle-02], qui représente un toolkit pour le prototypage de collecticiels pour la manipulation de données multimédia, cette propriété peut ne pas être essentielle. Cependant, dans le cas de boîtes à outils à vocation plus générale, un manque d’extensibilité constitue un grave inconvénient. Par conséquent, pour pouvoir offrir plus de possibilités aux développeurs, ces boîtes à outils peuvent devenir très volumineuses, impliquant une prise en main par le développeur de plus en plus difficile. Par ailleurs, comme dans le cas du développement from scratch, il est impossible d’avoir des boîtes à outils offrant toutes les fonctionnalités possibles (notamment celles qui n’ont pas été prévues !).
L’extensibilité consiste donc à permettre aux développeurs de créer de nouveaux outils (implémentant de nouveaux comportements) et de les incorporer à la boîte à outils. Les boîtes à outils offrant une “implémentation ouverte” (de l’anglais Open Implementation, une approche décrite par Kiczales [Kiczales-96]) et celles que sont carrément open source1, sont extensibles de manière intrinsèque (par exemple Prospero [Dourish-98]). Mais le niveau d’expertise exigé des développeurs peut être décourageant étant donné qu’ils doivent bien comprendre les stratégies d’implémentation employées à l’intérieur du système.
Pour aider le développeur dans cette tâche, certains systèmes offrent quelques facilités d’extensibilité. COAST [Schuckmann-96], par exemple, caractérise une boîte à outils qui, s’appuyant sur les principes de l’orientation objet, offre un ensemble de classes abstraites2 et génériques qui peuvent être spécialisées par le développeur afin de créer de nouveaux éléments. Mais ceci implique des efforts de développement et d’implémentation qui doivent être entrepris en dehors du contexte de la boîte à outils (c’est-à-dire, en utilisant un environnement de programmation extérieur) afin de concevoir de nouveaux outils. Ces nouveaux outils resteront de plus spécifiques à la boîte à outils.
D’autres solutions ont été proposées pour assurer flexibilité et extensibilité [Dourish-00] [Roseman-96] [Shen-04]. Nous avons par exemple GroupKit [Roseman -96], qui est certainement la boîte à outils la plus connue dans le monde du TCAO. Il s’agit d’un environnement pour le développement de collecticiels développé en langage interprété (en l’occurrence Tcl/TK). Outre l’ensemble des services pour la coopération présenté sous la forme de groupware widgets3, GroupKit fournit un outil appelé Class Builder qui permet aux développeurs de créer de nouveaux widgets ou d’adapter le comportement des widgets existants.
Pendant un moment l’approche de développement basée sur des boîtes à outils a été très répandue. Néanmoins les développeurs ont vite constaté que ces boîtes à outils (extensibles ou non) présentent une contrainte de taille : elle n’offrent pas de mécanismes
1 Terme suggéré par Christine Peterson du Foresight Institute [Foresight] pour caractériser les logiciels dont le code source est disponible, modifiable et “redistribuable” sous certaines conditions.
2 En programmation orientée objet, une classe abstraite est une classe “non-instanciable” qui contient des fonctions virtuelles sans code (aussi dites abstraites). Elle sert juste de base à d’autres classes héritées.

Développement s’appuyant sur des frameworks et des plates-formes

De nombreux projets de recherche se fixent comme objectif de construire des frameworks ou des plates-formes pour le développement d’applications collaboratives. Il s’agit en général de solutions plus génériques que les boîtes à outils qui cherchent notamment à supporter des propriétés telles que la flexibilité et l’extensibilité.
Les frameworks, couramment appelés en français “architectures cadre” ou “cadre d’application”, fournissent une structure réutilisable qui spécifie les fondements de l’application. Normalement, cette structure se présente sous la forme d’une architecture générique ou conceptuelle. Les frameworks peuvent également être associés à la notion de pattern (ou “patron”) qui décrivent des solutions reconnues pour une classe de problèmes (par exemple [Tarpin-Bernard-98]).
Une plate- forme offre en général un support générique d’exécution et de développement de collecticiels en définissant une architecture et des briques logicielles implémentant des mécanismes de contrôle pour la collaboration. Certaines plates-formes sont développées en s’appuyant sur des frameworks (par exemple, [Barthelmess-05] et [Domingos-97]). Néanmoins, une distinction consensuelle entre frameworks et plates-formes s’avère difficile, surtout quand nous trouvons le terme framework désignant des environnements fournissant un ensemble de bibliothèques ou briques logicielles pour permettre le développement d’applications (par exemple [.NET]). Nous allons ainsi employer ces termes selon les critères choisis par chaque auteur des travaux cités par la suite.
Un framework ou une plate-forme peut être définie pour supporter la construction de nouvelles applications ou la transformation d’applications existantes en applications collaboratives. Dans cette dernière catégorie, nous avons par exemple la plate-forme XTV [Abdel-Wahab-91] et les frameworks Habanero [Jackson-99] et DISCIPLE [Li-99]. Ces systèmes permettent de partager entre plusieurs utilisateurs des applications originalement conçues pour un seul utilisateur. En particulier, Habanero et DISCIPLE offrent aux développeurs les outils nécessaires à la création de collecticiels implémentés en Java par l’intégration et le partage de différentes applications mono-utilisateur (l’intégration d’applications originalement collaboratives est également envisageable). Malgré cette flexibilité concernant la possibilité de combiner différentes applications dans un même environnement, il s’agit beaucoup plus d’une “cohabitation” que d’une réelle intégration, car il n’existe pas vraiment d’interactions entre ces applications.
Dans la catégorie des frameworks et des plates-formes pour la construction de nouvelles applications collaboratives, une tendance actuelle des concepteurs de ces systèmes consiste à réaliser un développement modulaire en s’appuyant sur des composants. En effet, au cours de ces dernières années dans le domaine de l’ingénierie de systèmes, plusieurs travaux ont porté sur les approches orientées composants. Le développement à base de composants logiciels est devenu un facteur majeur pour rendre possible la composabilité, l’extensibilité et la malléabilité [Slagter-00].
Il existe plusieurs définitions du terme “composant logiciel”. En particulier la définition de Szyperski [Szyperski-02] est très souvent adoptée, notamment dans le domaine du TCAO. Szyperski définit un composant logiciel comme : “une unité de composition avec des interfaces contractuellement spécifiées et des dépendances explicites sur son contexte. Un composant logiciel peut être déployé indépendamment et il est sujet à des compositions par des tiers”.
Différents auteurs considèrent que les collecticiels de demain seront davantage des assemblages de composants (par exemple [Farias-00b] et [Grundy-02]). Ils partent du principe que la plupart des fonctionnalités requises existeront déjà sous forme de composants développés par des tiers. En s’appuyant sur des assemblages de composants, les systèmes peuvent définir des environnements collaboratifs complètement intégrés.
Ainsi, au contraire des boîtes à outils, un schéma d’interaction entre composants doit être défini afin de permettre l’intégration de différents composants dans une même plate-forme. TeamWave Workplace (TeamRooms à l’origine) [Roseman-97] par exemple propose une extension basée composants de GroupKit. Une architecture et un modèle de composant spécifique sont définis de manière simple afin d’encourager le développement de nouveaux composants par des tiers. Neem [Barthelmess-05] représente également une plate-forme définissant une infrastructure de composants réutilisables et extensibles. Mais dans les deux cas, la réutilisation des composants est limitée au système en question. Ainsi, le développeur est contraint d’utiliser les composants spécifiques au système.
Afin de rendre possible l’intégration de composants développés sans avoir de système spécifique cible, la construction de collecticiels converge de plus en plus vers l’utilisation d’intergiciels (de l’anglais middleware [Geihs-01]) définissant des modèles généraux de composants). Des exemples répandus de modèles de composants sont CCM (CORBA Component Model [OMG-04]), EJB (Entreprise JavaBeans [EJB]) et .NET [.NET]. Ces modèles de composants offrent une séparation entre les fonctionnalités métier du composant et les fonctionnalités système (sécurité, répartition, cycle de vie, etc.). Cette séparation est réalisée suivant le paradigme composant/conteneur [Szyperski-02].
Ainsi, de nombreux systèmes pour le développement d’applications collaboratives ont été développés en s’appuyant sur ces modèles généraux de composants, notamment ceux définis par CORBA et JavaBeans [Slagter-00]. Nous avons par exemple les systèmes basés sur CORBA, tels que CoCoWare [Slagter-01], DARE [Bourguin-00] et la plate-forme décrite en [terHofte-96], et sur JavaBeans, tels que ACOST [Hummes-00], EVOLVE [Stiemerling-00], MAUI toolkit [Hill-04] et ANTS [Garcia-01].
L’intérêt de ces systèmes est ainsi d’assurer la propriété d’extensibilité par le biais de l’intégration de composants développés par des tiers 1 qui n’ont pas été a priori préconisés pour ces systèmes. La condition à respecter est que ces composants s’appuient sur le même modèle général de composants. Certains systèmes offrent des possibilités d’extensibilité encore plus élaborées permettant que de nouveaux composants soient intégrés aux collecticiels en temps d’exécution (par exemple [Hummes-00]). En outre, puisque les composants originellement disponibles dans ces systèmes (généralement des composants intégrant les mécanismes de base nécessaires à la coopération) ont été développés selon le modèle général de composant utilisé par le système, ils peuvent être réutilisés par des tiers, ou même intégrés dans un environnement de développement intégré (EDI 2 ) standard. Par exemple, les MAUI components (des composants offrant des fonctionnalités multi-utilisateurs fournis par MAUI toolkit1) peuvent être utilisés dans des EDIs Java tels que NetBeans [NetBeans] et JBuilder [JBuilder].
Ainsi, l’approche de développement s’appuyant sur des modèles généraux de composants définis par des intergiciels facilite l’intégration d’autres fonctionnalités coopératives sous la forme de composants logiciels. L’utilisation de telles technologies impose toutefois des contraintes vis-à-vis de l’environnement d’exécution. Autrement dit, cela reste difficile (voire impossible) d’intégrer aux collecticiels des composants, ou carrément d’autres applications collaboratives, qui n’ont pas été conçus en se reposant sur ces intergiciels.
Même si les intergiciels viennent à l’aide du développeur en lui cachant plusieurs problèmes liés à la conception d’applications collaboratives, comme par exemple la distribution géographique des participants, ils deviennent de plus en plus complexes [Kordon-05]. Cette complexité est souvent liée au fait que les concepteurs des intergiciels cherchent à établir des systèmes répartis toujours plus sophistiqués [Colyer-03]. Cette tendance amène les développeurs à être confrontés au même ensemble de problèmes que les intergiciels étaient censés résoudre – les systèmes pour le développement de collecticiels, ainsi que les collecticiels développés, risquent de devenir trop complexes. Dans le paragraphe II.4.2.1 nous allons aborder plus en détail quelques intergiciels en tant que solutions pour l’intégration d’applications.

Vers l’intégration d’applications collaboratives existantes

Motivations

Indépendamment de l’approche de développement choisie, la conception de nouvelles applications collaboratives qui soient extensibles se présente comme un grand défi pour les développeurs. Si d’un coté l’utilisation de boîtes à outils s’avère simple et rapide, le degré d’extensibilité obtenu est très restreint. Si les développeurs choisissent de s’appuyer sur des frameworks ou des plates-formes, la possibilité d’intégrer de nouveaux composants est également contraignante puisque ces derniers doivent suivre un schéma d’interaction imposé par le système en question. Ou alors les développeurs doivent faire face à la complexité des intergiciels afin de pouvoir intégrer des composants disponibles sur le marché.
Dans la pratique, nous trouvons sur le marché soit des collecticiels se focalisant sur des aspects spécifiques de la coopération, et qui ont souvent été développés selon l’approche from scratch, soit des plates-formes collaboratives, qui ont souvent été développées selon des frameworks très sophistiqués [Eseryel-02]. Dans cette deuxième catégorie, nous trouvons des systèmes commerciaux très diffusés tels que Microsoft Live Meeting [LiveMeeting] et IBM Lotus Software [Lotus]. Ces deux plates-formes offrent tout un éventail d’outils pour la communication, la gestion et le partage de documents, des calendriers partagés, etc. La possibilité d’intégration est effectivement considérée dans Live Meeting qui peut facilement interagir avec d’autres outils Microsoft (notamment les outils de Microsoft Office). Lotus Software, de son coté, assure l’extensibilité par son application Domino, qui offre une suite d’outils de développement permettant aux développeurs de créer de nouvelles fonctionnalités et de les ajouter au collecticiel. Mais malgré toutes les possibilités d’extensibilité offertes par ces plates-formes, elles sont loin d’être considérées comme une panacée. Outre le coût associé à ces systèmes, l’utilisateur se trouve toujours limité à une plate-forme donnée. Autrement dit, il est confronté à un choix limité d’outils de collaboration.
Ainsi, des utilisateurs finissent par composer leurs propres “environnements collaboratifs” en choisissant, selon leurs besoins, différentes applications offrant des fonctionnalités spécifiques, en les exécutant en même temps mais indépendamment les unes des autres. Néanmoins, compte tenu du fait que ces applications collaboratives sont en réalité employées pour réaliser une même tâche ou un ensemble commun de tâches pour le travail en groupe, il devrait exister une liaison, voire des interactions entres ces différentes applications. En effet, 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. Par ailleurs, par l’intégration d’applications fournissant des technologies complémentaires, la valeur de la technologie dans son ensemble est supérieure à la somme des valeurs associées à chaque application [Mangematin-96]. Il y a une vingtaines d’années, Wilson [Wilson-88] dans une révision des travaux réalisés dans le domaine du TCAO montrait déjà que le besoin d’environnements collaboratifs intégrés était évident.
Teege [Teege-96] récapitule les deux démarches à suivre pour construire de tels environnements collaboratifs intégrés. La première démarche est celle que nous avons abordée jusqu’à présent ; elle consiste à les concevoir et les développer dès le début en tant que systèmes intégrés. Leur mise en œuvre peut être réalisée selon une des approches de développement décrites dans le paragraphe II.3.2. La deuxième démarche, au contraire de ces approches de développement, ne cherche pas à concevoir de nouveaux collecticiels. En fait l’objectif est de construire des plates- formes ou environnements collaboratifs intégrés en rassemblant des collecticiels existants tout en assurant leur interopérabilité. Dans les paragraphes suivants, nous allons tout d’abord étudier la problématique associée à l’intégration d’applications de façon générale, pour ensuite aborder les démarches spécifiques à l’intégration d’applications collaboratives.

Plates-formes et environnements généraux d’intégration

La problématique associée à l’intégration d’applications ne se restreint pas au domaine du TCAO. Dans de nombreux domaines, et notamment dans le domaine du développement d’applications réparties, l’un des principaux axes de recherche concerne la possibilité de faire interopérer différents systèmes. L’interopérabilité ou l’intégration1 entre les applications facilite la coopération au sein d’une organisation ou entre différentes organisations sans les contraindre à utiliser exactement les mêmes systèmes ni à posséder les mêmes équipements.
La notion d’intergiciel a fait son apparition afin de faciliter le développement d’applications réparties et de gérer les intéractions entre ces applications via des plates-formes hétérogènes (par exemple diversité du matériel, des systèmes d’exploitation ou des langages de programmation). Un intergiciel représent ainsi une solution architecturale au problème de l’intégration de différentes applications tout en imposant à ces applications une interface de service commune.
Également dans le cas des entreprises, la nécessité de collaborer efficacement via l’intégration des applications de l’entreprise n’a jamais été aussi importante. L’environnement économique actuel impose de nouvelles stratégies, telles que le partenariat, incitant de plus en plus les entreprises à échanger des données et à interagir les unes avec les autres. Dans ce contexte, le concept de EAI (Enterprise Application Integration) est apparu pour désigner l’ensemble des méthodes, technologies et outils destinés à l’intégration des différentes composantes des systèmes d’information des entreprises.
Parallèlement à l’évolution des intergiciels et de l’EAI, dans le domaine de l’Internet, les technologies Web ont émergé et remporté un succès important, en permettant des interactions simples avec des ordinateurs à distance. Plus récemment, les services Web, qui reprennent la plupart des principes du Web en les appliquant à des interactions ordinateur-ordinateur, se présentent comme une technologie potentielle pour l’intégration d’applications à travers l’Internet.

Les intergiciels conventionnels

Les solutions à base d’intergiciels sont largement utilisées dans les architectures des systèmes d’information [Schantz-02]. Elles peuvent être divisées en deux classes principales : les intergiciels orientés objet et les intergiciels orientés messages. Dans la première classe, très souvent, les intergiciels fournissent un modèle de composants. La communication entre objets (ou composants) est normalement synchrone et s’appuie sur le mécanisme RPC (Remote Procedure Call). Les intergiciels orientés messages, ou MOM (Message-Oriented Middeleware), offrent une interopérabilité dont le paradigme d’interaction est asynchrone et s’appuie sur l’échange de messages. Néanmoins, nous remarquons que les trois grands intergiciels qui ont remporté un succès certain dans ce domaine suivent en fait les principes de l’orientation objet : CORBA, DCOM et Java RMI.

CORBA

L’ OMG (Object Management Group [OMG]) est un organisme international qui s’est fixé pour objectif de définir des standards pour la mise en place et l’intégration d’applications réparties. Son premier travail fut la définition de l’OMA (Object Management Architecture [OMA]) spécifiant un modèle d’objet et une architecture d’intégration. La spécification de CORBA (Common Object Request Broker [OMG-04]) suit directement la définition de l’OMA. Nous trouvons le concept d’ORB (Object Request Broker) au centre de l’architecture CORBA. Il s’agit d’un mécanisme qui permet, de façon transparente, de localiser des objets et d’établir des relations de type client/serveur afin d’invoquer des méthodes de ces objets. Il existe aujourd’hui plusieurs implémentations d’ORBs (par exemple [Orbix] et [Visibroker]).
L’interopérabilité entre objets hétérogènes est rendue transparente par la spécification d’interfaces en utilisant le langage CORBA-IDL (CORBA Interface Description Language). Ce langage permet de spécifier l’interface de chaque objet en décrivant toutes ses méthodes, et leurs paramètres, qui peuvent être invoquées à distance. Ainsi le service fourni par un objet CORBA est décrit indépendamment de son implémentation. Un compilateur génère, à partir d’une spécification CORBA-IDL, des souches (stubs) qui sont destinées aux clients, et des squelettes (skeletons) qui sont destinés aux serveurs, et ce dans différents langages d’implémentation (C, C++, Java, etc.). Ces objets mis en œuvre sur des systèmes hétérogènes peuvent ensuite interopérer.
Le principe de fonctionnement d’un ORB consiste à intercepter la requête du client, trouver un serveur, lui passer les paramètres et invoquer la méthode correspondante à l’appel pour ensuite retourner les résultats au client. En général, l’appel est fait de façon statique, correspondant à un appel bloquant de type RPC. Néanmoins, CORBA possède un MOM spécifique permettant également de réaliser des appels dynamiques (au moyen d’échange de messages) à des objets dont les interfaces ne sont pas connues a priori. Un réceptacle d’interfaces contenu dans l’ORB est utilisé pour permettre aux objets de découvrir dynamiquement les autres objets.
En spécifiant comment différents ORBs peuvent interopérer, CORBA représente la réponse de l’OMG au problème de l’interopérabilité entre applications. Le protocole GIOP (General Inter-ORB Protocol), qui permet de coder les messages associés à la sémantique des échanges requête-réponse, prévoit un support d’interopérabilité entre ORBs. Le mécanisme IIOP (Internet Inter-ORB Protocol) de ce protocole définit comment la communication entre différents MOMs basée sur TCP/IP doit s’effectuer.

DCOM

DCOM [Microsoft-96] (Distributed Component Object Model) est un intergiciel propriétaire développé par Microsoft. Il s’agit d’une extension distribuée de COM [COM], une architecture logicielle à base de composants. Cette dernière technologie s’appuie sur OLE (Object Linking and Embeding) pour permettre l’interaction entre différentes applications Windows.
COM définit une spécification et l’implémentation correspondante, et selon cette spécification, des composants (dits objets COM) peuvent fournir des services. Grâce à un ensemble d’interfaces spécifiées dans le langage MIDL ( Microsoft Interface Description Language), les objets COM sont exposés et leurs services peuvent alors être invoqués par des clients. En utilisant ce langage, comme dans le cas de CORBA, la description du service reste découplée de son implémentation. En fait, le codage des objets COM et des clients peut être réalisé dans n’importe quel langage supportant le format binaire de COM.
La principale différence entre COM et son extension distribuée est que le premier assure l’interopérabilité des applications à l’intérieur d’un même ordinateur, tandis que DCOM permet de faire interopérer des applications sur des plates-formes Windows distinctes à travers un réseau. Par conséquent, DCOM doit faire face à toutes les contraintes imposées par COM. La contrainte la plus importante concerne le fait que l’environnement doit être homogène, c’est-à-dire, DCOM finit par être une architecture distribuée fermée. L’interopérabilité n’est alors supportée qu’entre plates-formes Windows.

Table des matières

Avant-propos
Table des matières
Table des figures
Chapitre I Introduction générale
I.1. Contexte général
I.2. Problématique abordée
I.3. Principales contributions de la thèse
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 TCAO
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
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
V.2.4.2. Les incohérences en présence de contraintes temporelles
V.2.4.3. Autres incohérences concernant l’exécution des règles politiques : la problématique des applications multiserveurs et P2P
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
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 Chat
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 <attributes>
A.2.2. L’élément <API>
A.2.2.1. Les éléments <evtsAPI> et <actsAPI>
A.2.2.2. L’élément <gestionAPI>
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 <GSMInfo>
B.2. L’élément <IAInfo>
B.3. L’élément <rules>
B.3.1. L’élément <event>
B.3.2. Les éléments <trigger> et <predicate>
B.3.3. L’élément <action>
Références bibliographiques
Publications de l’auteur
Bibliographie

Télécharger le rapport complet