Comparaison MOTU/BSCW

1. Comparaison MOTU/BSCW Projet COCAO Pascal Molli MC Université Henri Poincaré

2. Virtual team services • Shared data • Object and dependencies, Concurrency, versioning, annotation, Access Control, Notification • Communication Services • Synchronous: video-conference, application sharing, collaborative tools, shared whiteboard, chat • Asynchronous: Mailing list, web pages, forums, persistent notification

3. Virtual Team Services • Coordination : Tasks management • Manual : Project Management • Enacted : ToDo List • Defined in a process and enacted: Workflows • Awareness : pertinent • Activity awareness, Availability awareness, Process awareness.

4. MOTU/BSCW:Shared Data

5. MOTU/BSCW:Communication

6. Workflow Process definition Task management Workflow engine based on anticipation Nothing Motu/BSCW:Coordination

7. Motu/BSCW: Awarness

8. Les « + » des Motus • COO-Transactions • State-Awarness • Flexible-workflow

9. read modify read modify update write write Shared Data and Copy-Modify-Merge Private Workspace Private Workspace Private Workspace Shared Workspace Private Workspace Private Workspace Private Workspace Private Workspace

10. Read read b a C b a b a b a b a b a C Validation of C ?? Shared Data and Consistency b a C

11. Data Consistency • Transactional approach: • Encapsulate activities in transactions. • The system will take in charge the problem of concurrent access

12. read modify read modify update write write Data Consistency Private Workspace Private Workspace Private Workspace Shared Workspace Private Workspace Private Workspace Private Workspace Private Workspace

13. Data Consistency • Results: • Coo-serializability : new correction criterion for cooperative executions • Coo-transactions : new advanced transaction model based on coo-serlializability • COO prototype: a cooperative development environment based on the coo-transactions.

14. Les « + » des Motus • COO-Transactions • State-Awarness • Flexible-workflow

15. checkout modify checkout modify update commit commit Copier/Modifier/Fusionner et Conscience de Groupe Espace de Travail Espace de Travail Espace de Travail Que font les autres membres du projet ? Référentiel Est ce que mes modifications sont prises en compte ? Y a-t-il une nouvelle version du fichier ? Est ce la dernière version du fichier Espace de Travail Est ce qu’un autre utilisateur possède cette version de fichier ? Espace de Travail Voyons nous la même chose? Est ce qu’un autre utilisateur modifie les mêmes données ? Espace de Travail Espace de Travail

16. Problématique • L’accès concurrent aux données basé sur le principe du Copier/Modifier/Fusionner présente des limites • Que font les autres membres du projet ? • Est-ce qu’ils modifient les mêmes données ? • Y a-t-il une nouvelle version du fichier ?

17. Proposition • Besoin d’awarness sur données partagées: • Calcul des états des objets partagés • Représentation graphique • Communication

18. Plan de la présentation • Conscience de groupe et données partagées • Conscience de groupe et visualisation • Conscience de groupe et communication

19. Conception du système de conscience de groupe • Définir les trois catégories d’états concurrents : • local : modifications d’un utilisateur dans son espace de travail privé • global : modifications des autres utilisateurs sur les mêmes données partagées • potentiel : un futur état possible du fichier existant dans l’espace de travail local

20. Conception du système de conscience de groupe • Définir tous les états pour chaque catégorie • Définir toutes les transitions pour assurer les passages d’un état vers un autre • Diagrammes états-transitions

21. Définition des états

22. Définition des transitions

23. LOCAL INITIAL T_CHECKOUT T_MOD_RS T_ADD T_MOD_PHYS T_MOD_PHYS T_COMMIT LOCAL UP_TO_DATE LOCAL ADDED LOCAL MODIFIED T_COMMIT T_UPDATE T_MOD_PHYS T_UPDATE T_MOD_RS Diagramme états-transitionsétat local

24. GLOBAL INITIAL T_CHECKOUT T_MOD_PHYS T_ADD T_MOD_PHYS T_COMMIT T_MOD_RS GLOBAL NOT_APPLICABLE GLOBAL UP_TO_DATE GLOBAL NEED_UPDATE T_UPDATE T_MOD_PHYS T_COMMIT T_MOD_RS Diagramme états-transitionsétat global

25. T_MOD_PHYS T_COMMIT T_UPDATE T_POTENTIAL POTENTIAL INITIAL DYNAMIC INITIAL T_MOD_RS T_CHECKOUT T_ADD LocalStatus = LOCAL_UP_TO_DATE ! Oi LOCAL_MODIFIED T_COMMIT T_MOD_RS POTENTIAL UPDATE DYNAMIC UPDATE  Oi LOCAL_MODIFIED T_POTENTIAL LocalStatus = LOCAL_MODIFIED T_MOD_PHYS T_COMMIT T_MOD_RS POTENTIAL CONFLICT DYNAMIC CONFLICT  Oi LOCAL_MODIFIED T_POTENTIAL Diagramme états-transitionsétat potentiel T_UPDATE ! Oi LOCAL_MODIFIED T_UPDATE

26. Réalisation des tests états concurrents du fichier

27. Conception du système de conscience de groupe • Réalisation des tests : • l’affichage des trois états concurrents trop compliqué pour l ’utilisateur • Besoin de condenser l’information pour la rendre plus pertinente. • Utiliser un outil graphique dédié à l’affichage des informations sur les données partagées

28. Plan de la présentation • Conscience de groupe et données partagées • Conscience de groupe et visualisation • Conscience de groupe et communication

29. Visualisation des états de partage • Objectif : Pouvoir surveiller l’état des objets partagés comme un trafic réseau ou une charge CPU • Problème : Le nombre de fichiers partagés peut être grand… et l’espace d’affichage est restreint...

30. Un Treemap • Permet de représenter en deux dimensions une arborescence de fichiers • Chaque fichier est représenté par un rectangle de couleur : • la dimension est définie par sa taille • la couleur est associée à une propriété du fichier • Chaque niveau de l’arborescence est représenté par une rotation de 90°

31. 1 2 3 4 5 6 11 12 7 8 9 10 11 3 1 4 7 5 6 Mise en place du Treemap Exemple : Arborescence de 12 fichiers sur 3 niveaux Treemap correspondant

32. Mise en place du Treemap • Caractéristique de notre Treemap : • les fichiers représentés correspondent aux données existantes dans l’espace de travail privé • la couleur est associée à un état unique du fichier partagé • La couleur doit être significative pour l’utilisateur

33. Définition des états uniques

34. Réalisation des tests Besoin d’un moyen de communication simple et efficace pour permettre aux utilisateurs en conflits de résoudre leurs problèmes

35. Plan de la présentation • Conscience de groupe et données partagées • Conscience de groupe et visualisation • Conscience de groupe et communication

36. Intégration de la visioconférence • Système de visioconférence développé par des étudiants d’ESIAL • Caractéristiques générales : • Utilise le JMF (Java Media FrameWork) • Communications entre plusieurs utilisateurs possédant la même adresse IP Multicast

37. Intégration de la visioconférence • Performance du système : • résultat satisfaisant pour une connexion unidirectionnelle • qualité dégradée rapidement pour une connexion bidirectionnelle • choix des normes de capture vidéo (H263) et audio (g723) adaptées à la visioconférence

38. Réalisation des test

39. Les « + » des Motus • COO-Transactions • State-Awarness • Flexible-workflow

40. Workflow Management System • Two components: • Process definition (declarative or/and visual) • Define tasks ... • Who must accomplish the task • Define transitions between tasks. • Process execution engine • Execution environment • Users tasks appear on their desktop...

41. owner: me write doc owner: him reviewer doc Change the Execution Engine • Anticipation.. • If intermediate results are available you can use them • To start tasks as soon as • Example: process of write/ review a document

42. Flexible Workflow

43. Flexible Workflow

44. Conclusion • Les plus des motus: • Concurrence d’accès et ingéniérie concurrente • State Awarness, communication et auto-coordination • Workflow flexible • Les moins de motus: • En développement… • Pas fiable…