Je tiens à remercier M. Je tiens également à remercier M. Michel Diaz, directeur de recherche CNRS et responsable du groupe de recherche Outils logiciels pour la communication (OLC) au moment de mon arrivée au LAAS-CNRS, de m'avoir permis d'effectuer mes travaux au sein de ce groupe.
Introduction générale
- Contexte général
- Problématique abordée
- Principales contributions de la thèse
- Plan de thèse
Notre objectif, objet de nos travaux de thèse, est de définir un environnement d'intégration pour les applications collaboratives existantes. Ainsi, dans le cadre de cette thèse, nous proposons un environnement d'intégration qui, basé sur une approche faiblement couplée, permet l'intégration d'applications collaboratives existantes, tout en évitant les détails internes de ces applications.
État de l’art
Introduction
TCAO : Concepts et classifications
- Quelques concepts fondamentaux
- La coopération et la collaboration
- La télé-présence
- La session et les artéfacts de travail
- Classification des applications collaboratives
- La classification espace-temps
- Les catégories fonctionnelles d’applications de TCAO
Outre la coopération synchrone, les membres d’un groupe peuvent également agir à des moments différents, c’est-à-dire que les actions se déroulent de manière étalée dans le temps. Cela donne par exemple à l'organisateur d'une réunion une idée claire de la disponibilité des personnes impliquées dans un projet.
Développement de systèmes de TCAO
- Quelques difficultés
- La flexibilité, l’extensibilité et la malléabilité
- Les approches de développement
- Développement from scratch
- Développement s’appuyant sur des boîtes à outils
- Développement s’appuyant sur des frameworks et des plates-formes
Une application peut ainsi également être étendue grâce à l'intégration de nouvelles fonctionnalités sous la forme de nouveaux composants, modules ou autres applications. Une boîte à outils est une bibliothèque de composants logiciels chargés de gérer les structures de données et d'effectuer des opérations courantes pour le développement d'applications.
Vers l’intégration d’applications collaboratives existantes
- Motivations
- Plates-formes et environnements généraux d'intégration
- Les intergiciels conventionnels
- Enterprise Application Integration
- Les services Web
- Bilan des solutions générales d’intégration
- Plates-formes et environnements pour l’intégration d’applications
- Positionnement de notre proposition
Un autre exemple d'environnement collaboratif permettant l'intégration d'applications collaboratives est DARE (Distributed Activity in a Reflexive Environment [Bourguin-00]). Dans [Iqbal03], les auteurs décrivent trois niveaux différents qui peuvent être atteints lors de l'intégration d'applications collaboratives.
L’Approche d’intégration initiale
- Introduction
- CIE : l’environnement d’intégration collaboratif
- Les contraintes des CVEs conventionnels
- Le cadre général d’intégration
- L’architecture de base
- Implémentation de l’environnement d’intégration collaboratif
- Implémentation des modules de l’architecture
- Le fichier d’initialisation
- L’extensibilité de l’environnement
- Conclusions
Sur la base de ce modèle, nous avons pu définir les différentes composantes de l’état global d’une SuperSession. Dans la Figure B.11, nous décrivons la syntaxe définie pour les références aux composants de l'état global de la SuperSession.
L’environnement d’intégration : LEICA
Introduction
Dans le processus de configuration de SuperSession, nous déterminons quelles applications collaboratives seront utilisées, ainsi que leur comportement. Nous présenterons ensuite la définition de SuperSession détaillant les différents éléments du modèle proposé.
Approche générale d’intégration
- Scénarios d’intégration
- Outil de navigation coopérative enrichi d’un outil de messagerie
- Réunions virtuelles
- E-learning
- Cadre général d’intégration
Une politique de collaboration SuperSession représente un ensemble de règles exprimées sous la forme d'un modèle de conditions/action. La politique de collaboration précise ainsi le couplage souhaité entre applications intégrées lors de l'exécution d'une SuperSession, et par conséquent le comportement dynamique de la SuperSession.
Description d’une SuperSession
- Modèle de SuperSession
- Applications collaboratives
- Applications non collaboratives
- Rôles généraux
- Utilisateurs connectés
- Sessions spécifiques
- Illustration d’une SuperSession
Mbbl={Mbl.n}n≤φ est l'ensemble fini des relations d'appartenance actuelles ; Uatl est une liste d'attributs qui caractérisent l'utilisateur. Une session spécifique représente une session collaborative partagée au sein d'une application collaborative (par exemple, une session d'audioconférence ou une session de navigation Web collaborative). Notez qu'une application collaborative n'est pas censée définir explicitement cette abstraction de session spécifique.
Nous avons choisi la notation SSt pour représenter un instantané d'une SuperSession (et récursivement de ses éléments).
Création d’une SuperSession
- Configuration des informations de gestion
- GSMinfo
- IAinfo
- Spécification des politiques de collaboration
- Types de notification d’événement et de requêtes d’exécution d’action
- La définition des règles de collaboration : les policy widgets
- Exemples de règles
- Formalisation de la sémantique des règles politiques
Toujours sur la Figure IV.9, on remarque que le paramètre « z » du widget Action est associé à une composante de l'état global de la SuperSession. Notez que le déclencheur peut définir un état qui concerne uniquement les composants de l'état global du dépassement (y compris sa durée). Le déclencheur a donc la sémantique d'un événement qui peut « notifier » les changements dans l'état global de la SuperSession.
Les widgets Early et Latest vous permettent de composer différentes notifications d'événements lorsque vous spécifiez une règle de stratégie.
Conclusion
Chaque Wrapper et chaque client LC doivent conserver une version locale de l'état global de SuperSession. Cela est nécessaire car les règles de politique peuvent dépendre de l'état général de la SuperSession. Ainsi, contrairement à CoLab, nous avons spécifié deux formats d'appel d'application client (le premier pour les systèmes Windows et le second pour Unix1).
Dans la figure VI.18 nous avons fait la moyenne des résultats obtenus pour 5 répétitions de l'expérience.
L’architecture de LEICA
Introduction
Dans le chapitre précédent, nous avons présenté l'approche générale d'intégration suivie par LEICA, ainsi que l'abstraction de base, appelée SuperSession, qui permet à LEICA de gérer une session de collaboration en s'appuyant sur différentes applications intégrées dans l'environnement. Ce chapitre, à son tour, est consacré à la description de l'architecture LEICA, qui permet de mettre en œuvre efficacement l'approche générale d'intégration proposée. Dans une première partie, nous présentons un aperçu global de l'environnement d'intégration en décrivant les principaux modules de l'architecture ainsi que leurs rôles respectifs lors de l'exécution de l'environnement.
Dans la deuxième partie, nous présentons la méthode de modélisation utilisée dans la conception de l'architecture LEICA ; cette méthode est basée sur le profil UML/SDL [UML] [SDL] [Björkander-03].
Architecture : de l’intégration des applications à l’exécution d’une SuperSession . 75
- Création dynamique d’un Wrapper
- Couplage du Wrapper à l’application
- Enregistrement d’une application
- Configuration d’une SuperSession
- Configuration du GSMinfo et découverte des applications intégrées à
- Choix et configuration des applications collaboratives
- Spécification de la politique de collaboration
- Exécution d’une SuperSession
- Démarrage d’une SuperSession
- Connexion des utilisateurs à la SuperSession
- Gestion de l’état global d’une SuperSession
- Les incohérences potentielles dues à la répartition
- La gestion d’un état global cohérent et l’exécution repartie de la politique
- Les incohérences en présence de contraintes temporelles
- Autres incohérences concernant l’exécution des règles politiques : la
Notez que toutes les fonctions disponibles dans l'API d'une application ne correspondent pas nécessairement aux méthodes de l'interface de l'application. Avant de démarrer l'éditeur de règles de stratégie, l'application Web Session Configuration Service demande l'API d'événements/actions pour chaque application sélectionnée par l'administrateur SuperSession. Les composants de l'état d'une SuperSession sont définis selon le modèle SuperSession décrit à la section IV.3.1.
1 Sauf pour le prédicat associatif associé aux composants d'état global de SuperSession, comme nous l'avons précisé dans la section précédente.
Modélisation de LEICA en UML
- Introduction à UML 2.0
- Méthode de modélisation utilisée
- Modélisation en UML de l’architecture de LEICA
- L’analyse : les cas d’utilisation et les diagrammes de séquences de LEICA93
- Comparaison des scénarios engendrés par Tau G2 à ceux initialement
L'analyse : cas d'utilisation de LEICA et diagrammes de séquence La figure V.10 montre le diagramme général de cas d'utilisation de LEICA. Nous associons des diagrammes de séquence à chaque cas d'utilisation pour définir les interactions entre les différents composants (et sous-composants, lorsque nous disposons de diagrammes plus raffinés) du système. Dans la figure V.16, nous avons le diagramme de structure composite détaillant la structure interne du LEICASystem.
Pour chaque composant, nous avons défini des diagrammes de classes et de structure composite, où nous avons déterminé leurs sous-composants.
Conclusion
Dans le cas des événements Management API liés à LEICA, les entités sont nommées "LEICA:event_type". Comme mentionné précédemment, nous avons introduit une application pour simuler le comportement d'une application Web qui donnera accès au service de configuration de session. Dans le document de configuration XML de SuperSession, nous trouvons des informations sur les paramètres utilisés lors de l'appel de ces applications.
Enfin, nous avons finalisé l'implémentation de la classe LEICABabylonServer en créant les connexions entre les méthodes de l'API Babylon Chat et celles de l'ApplicationInterface.
Implémentation et déploiement de LEICA
- Introduction
- Les choix technologiques
- Les services Web
- Le paradigme publish/subscribe
- Principaux modules du prototype
- APIFactory
- Server Wrapper
- Session Configuration Service
- LClient
- L’intégration d’outils de collaboration et déploiement de LEICA
- CoLab
- Babylon Chat
- La SuperSession “CoLabPlusChat”
- L’environnement d’exécution
- Quelques considérations sur le prototype
- Conclusions
Dans la Figure B.1, nous illustrons le format XML du fichier de configuration SuperSession. 1 Si l'élément
Comme le montre la Figure B.5, chaque élément
Conclusion générale et perspectives
Bilan des travaux réalisés
Dans le cas de l'édition d'un document, toute modification apportée au document dans une application doit être signalée à l'autre application. Nous avons donc formellement défini l'architecture de l'environnement d'intégration en utilisant le profil UML/SDL supporté par l'outil TAU G2 de Telelogic. En plus de valider l'architecture, cette modélisation UML était très importante pour documenter LEICA et en même temps démontrer la complexité d'un tel environnement d'intégration distribué.
Bien que les contraintes de temps ne nous aient pas permis de mettre en œuvre tous les modules initialement prévus, ce prototype nous a permis de vérifier la faisabilité de l'approche d'intégration proposée.
Les perspectives de nos travaux
Notez que l'approche d'intégration de LEICA dépend fortement des API pour les applications collaboratives :. i) un Wrapper est généré dynamiquement pour une application sur la base des descriptions XML de son API ; ii) la spécification de la politique de coopération d'une SuperSession dépend directement de l'API événements/actions de l'application. L'utilisation d'un service de notification d'événements (basé sur le paradigme publication/abonnement) lors de l'exécution d'une SuperSession nécessite l'utilisation d'une technologie dans les Wrappers qui n'est pas standardisée. Il serait donc possible d'utiliser la modélisation RdP pour la vérification formelle de la politique de coopération d'une SuperSession.
Le problème est qu’une telle solution ne s’applique qu’aux applications développées avec la plateforme Java.
Le format du fichier d’attributs et d’API
- L’élément <attributes>
- L’élément <API>
- Les éléments <evtsAPI> et <actsAPI>
- L’élément <gestionAPI>
- Les événements et les actions de l’API de gestion
Comme le montre la Figure A.4, cette balise contient des éléments qui permettent de spécifier l'API d'événements/actions (via les éléments
Le but de cet élément est de permettre de préciser les actions de l'API de gestion que l'application n'est pas en mesure de gérer.
L’élément <GSMInfo>
La racine
L’élément <IAInfo>
Toujours sur la Figure B.3 on voit que cet élément, en plus de l'attribut "id" (qui précise l'identifiant de la session spécifique), contient trois éléments. 2 Pour avoir une association statique de rôles spécifiques, les rôles généraux doivent également être associés statiquement aux utilisateurs.
L’élément <rules>
- L’élément <event>
- Les éléments <trigger> et <predicate>
- L’élément <action>
3rd International IEEE Conference on Information Technology: Research and Education (ITRE 2005), IEEE Computer Society Press. 3rd International IEEE Conference on Advanced Learning Technologies (ICALT'03), IEEE Computer Society Press, Short Paper. 4th IEEE International Conference on Information Technology Based Higher Education and Training (ITHET'03), IEEE Computer Society Press.
Third IEEE International Conference on Software Engineering and Formal Methods (SEFM'05), IEEE Computer Society Press.
