INSTITUT NATIONAL POLYTECHNIQUE DE GRENOBLE
N
◦attribu´ e par la biblioth` eque
...
Th` ese
pour obtenir le grade de Docteur de l’INPG
pr´ epar´ ee ` a Dassault Syst` emes et au laboratoire
SIRAC (INRIA Rhˆ ones-Alpes) dans le cadre de l’´ ecole doctorale
« Math´ ematiques, sciences et technologies de l’information, informatique » , sp´ ecialit´ e « Informatique : syst` emes et communications » , pr´ esent´ ee
et soutenue publiquement le 9 septembre 2002 par
Nicolas Esposito
Coopeer : une architecture d’´egal ` a
´egal pour la conception collaborative
—
M´ ethode optimiste de r´ esolution automatique des conflits pour la coh´ erence de donn´ ees r´ epliqu´ ees
Directeur de th` ese : Michel Riveill Jury :
Jacques Mossi` ere Pr´ esident Bernadette Charron-Bost Rapporteur
Christian Toinard Rapporteur
Michel Riveill Directeur
Daniel Hagimont Examinateur
Arnaud Ribadeau-Dumas Examinateur
Avant-propos
Les travaux de recherche de cette th` ese ont principalement ´ et´ e r´ ealis´ es au sein du service de recherche
1de la soci´ et´ e Dassault Syst` emes
2dans le cadre d’une bourse CIFRE. Les r´ esultats de ces travaux ont fait l’objet de deux d´ epˆ ots de brevet [96, 97], ce qui a largement retard´ e la possibilit´ e de publication.
Note : les figures et les tableaux repris dans ce document et traduits de l’anglais vers le fran¸cais apparaissent en versions originales en annexe C (page 97).
Je remercie mon directeur de th` ese (Michel Riveill ), les membres du jury pour leur richesse de discussion, ceux qui ont rendu cette th` ese possible
`
a Dassault Syst` emes (St´ ephane Decl´ ee , Alan Hudin et Arnaud Ribadeau Dumas ), ceux qui ont particip´ e au projet (Valentin Chartier , Florent Car- pentier , S´ ebastien Lagarrigue , Nizar Es-Skali et Alexandru Popescu ), les relecteurs (Rapha¨ el Leblanc , Lo¨ıc Lefeuvre , Jean Buffet , David Le- sage et Danielle Esposito ), Nicolas Salzmann , Renaud Sirdey et Chrys- telle.
1
Service Recherche et nouvelles technologies (division Strat´ egie et recherche, d´ eparte- ment Recherche et d´ eveloppement).
2
http://www.3ds.com/
1
Table des mati` eres
Avant-propos 1
Introduction 11
1 Contexte de la conception collaborative 13
1.1 Introduction . . . . 13
1.2 Contraintes li´ ees aux applications de CAO . . . . 13
1.2.1 Introduction . . . . 13
1.2.2 Poids des donn´ ees et longueur des calculs . . . . 13
1.2.3 Complexit´ e de l’architecture . . . . 14
1.2.4 Complexit´ e du mod` ele de donn´ ees . . . . 15
1.2.5 Nommage g´ en´ erique . . . . 16
1.2.6 Conclusion . . . . 17
1.3 Gestion de la coh´ erence de donn´ ees r´ epliqu´ ees . . . . 18
1.3.1 Pr´ esentation du probl` eme . . . . 18
1.3.2 Contexte social . . . . 19
1.4 Architecture r´ eseau . . . . 20
1.4.1 Introduction . . . . 20
1.4.2 Client/serveur . . . . 21
1.4.3 D’´ egal ` a ´ egal . . . . 22
1.4.4 Comparaison . . . . 22
1.4.5 Conclusion . . . . 23
1.5 Conclusion . . . . 24
2 Solutions de conception collaborative 25 2.1 Introduction . . . . 25
2.2 Produits . . . . 26
2.2.1 Partage d’application . . . . 26
2.2.2 Partage de donn´ ees . . . . 27
2.2.3 R´ ef´ erences . . . . 27
2.2.4 Conclusion . . . . 28
3
2.3 Recherche . . . . 29
2.3.1 Introduction . . . . 29
2.3.2 Projets . . . . 29
2.3.3 Conclusion . . . . 34
3 Une architecture d’´ egal ` a ´ egal 37 3.1 Introduction . . . . 37
3.2 Premier sc´ enario de collaboration . . . . 37
3.3 Architecture r´ eseau . . . . 37
3.4 Transmission des op´ erations . . . . 38
3.5 Composant de partage de donn´ ees . . . . 38
3.6 Conclusion . . . . 39
4 Probl` eme de la gestion des conflits 41 4.1 Introduction . . . . 41
4.2 Conflits d’ordonnancement . . . . 41
4.3 Conflits de simultan´ eit´ e . . . . 41
4.4 Exemples . . . . 42
4.5 Ordonnancement et TCP/IP . . . . 42
4.6 Respect de l’intention de l’utilisateur . . . . 43
4.7 Contraintes . . . . 44
4.8 Autres caract´ eristiques . . . . 45
4.9 Conclusion . . . . 46
5 Etat de l’art ´ 47 5.1 Introduction . . . . 47
5.2 Syst` eme distribu´ e/r´ eparti . . . . 47
5.3 Temps logique . . . . 49
5.3.1 Introduction . . . . 49
5.3.2 D´ ependance causale . . . . 49
5.3.3 Horloges de Lamport . . . . 49
5.3.4 Historiques et graphes de d´ ependance . . . . 50
5.3.5 Horloges vectorielles . . . . 50
5.3.6 Matrices . . . . 51
5.4 Probl` emes . . . . 52
5.4.1 Exclusion mutuelle . . . . 52
5.4.2 Election . . . . ´ 52
5.4.3 Terminaison . . . . 53
5.4.4 Communication par s´ equenceur . . . . 53
5.4.5 Communication fiable . . . . 54
5.4.6 Communication causale . . . . 54
TABLE DES MATI ` ERES 5
5.5 Contrˆ ole de la concurrence . . . . 56
5.5.1 Introduction . . . . 56
5.5.2 Coh´ erence . . . . 58
5.5.3 Approches pessimistes . . . . 58
5.5.4 Transformation d’op´ eration . . . . 58
5.5.5 Ex´ ecution r´ eversible . . . . 60
5.5.6 Versions multiples . . . . 60
5.6 Conclusion . . . . 61
6 Une m´ ethode de gestion des conflits 63 6.1 Introduction . . . . 63
6.2 Principes de la m´ ethode . . . . 63
6.3 Algorithme . . . . 66
6.3.1 Contenu d’un message . . . . 66
6.3.2 Contenu d’une estampille . . . . 66
6.3.3 Structures de donn´ ees pour chaque machine . . . . 66
6.3.4 ´ Emission (l’op´ eration est fournie en entr´ ee) . . . . 66
6.3.5 R´ eception (le message est fourni en entr´ ee) . . . . 66
6.3.6 Traitement (le message est fourni en entr´ ee) . . . . 66
6.3.7 Ex´ ecution (le message est fourni en entr´ ee) . . . . 67
6.3.8 Note . . . . 67
6.4 Exemples . . . . 67
6.5 Gestion des priorit´ es . . . . 72
6.6 Impact sur l’interface utilisateur . . . . 72
6.7 Applications et extensions . . . . 73
6.8 R´ esultats . . . . 74
7 Gestion du groupe et tol´ erance aux pannes 79 7.1 Pr´ eambule . . . . 79
7.2 Tol´ erance aux pannes . . . . 79
7.2.1 Pr´ esentation du probl` eme . . . . 79
7.2.2 Solutions . . . . 80
7.2.3 Un m´ ecanisme de tol´ erance aux pannes . . . . 81
7.2.4 Algorithme . . . . 81
7.2.5 Exemple . . . . 81
7.2.6 Conclusion . . . . 82
7.3 Gestion du groupe . . . . 82
7.3.1 Pr´ esentation du probl` eme . . . . 82
7.3.2 Solutions . . . . 83
7.3.3 Deux m´ ecanismes de connexion . . . . 83
7.3.4 Algorithme de notre second m´ ecanisme . . . . 84
7.3.5 Exemple pour notre second m´ ecanisme . . . . 84
7.3.6 Conclusion . . . . 85
8 Conclusion 87 8.1 Bilan . . . . 87
8.2 Perspectives . . . . 88
A Algorithme en pseudo code 91 B Arguments de validation 93 B.1 Syst` eme de datation . . . . 93
B.1.1 Pr´ ec´ edence causale directe . . . . 93
B.1.2 D´ etection de la concurrence . . . . 93
B.2 Gestion des conflits . . . . 94
B.2.1 Ordonnancement . . . . 94
B.2.2 Simultan´ eit´ e . . . . 94
B.2.3 Priorit´ es . . . . 94
B.3 Diffusion ordonn´ ee . . . . 94
B.3.1 Introduction . . . . 94
B.3.2 Propri´ et´ e de sˆ uret´ e . . . . 94
B.3.3 Propri´ et´ e de vivacit´ e . . . . 95
C Versions originales 97
Bibliographie 101
Index 110
Table des figures
1.1 SolidWorks, une application de CAO largement diffus´ ee. . . . 14
1.2 Vision simplifi´ ee d’une application de CAO. . . . 15
1.3 Exemple d’arbre de construction avec la g´ eom´ etrie associ´ ee. . 16
1.4 Exemple d’utilisation du langage Cell Descriptor. . . . 18
1.5 Exemple n
◦1 de causalit´ e non respect´ ee. . . . 19
1.6 Exemple n
◦2 de causalit´ e non respect´ ee. . . . 20
1.7 Architectures client/serveur et d’´ egal ` a ´ egal. . . . 21
1.8 Exemple d’architecture hybride. . . . 24
2.1 Coh´ erence via partage d’´ etat [59]. . . . 25
2.2 Diff´ erentes approches pour une conf´ erence de conception [18]. . 26
2.3 Conception d’une poubelle avec Alibre Design. . . . 28
3.1 Int´ egration du composant Distributeur. . . . 39
4.1 Conflit d’ordonnancement. . . . 42
4.2 Conflit de simultan´ eit´ e. . . . 42
4.3 Exemple de conflit d’ordonnancement. . . . . 43
4.4 Exemple de conflit de simultan´ eit´ e. . . . 43
4.5 Conflit d’ordonnancement avec trois machines. . . . 44
4.6 Exemple de non respect de l’intention de l’utilisateur. . . . 45
5.1 Exemples de topologies fr´ equemment utilis´ ees [86]. . . . 48
5.2 Trois types d’´ ev´ enements dans un syst` eme distribu´ e. . . . . . 48
5.3 Exemple simple d’utilisation des horloges. . . . . 50
5.4 Exemple simple d’utilisation des vecteurs. . . . . 51
5.5 Exemple simple d’utilisation des matrices. . . . 52
5.6 ABCAST utilise 3n messages pour une ´ emission vers n sites. . 54
5.7 R´ eception, mise en attente, puis livraison d’un message. . . . . 55
5.8 Exemple d’ex´ ecution de CBCAST. . . . 56
5.9 Ev´ ´ enements concurrents (e et f ). . . . 56
5.10 Classification des approches de contrˆ ole de la concurrence [9]. . 57
7
5.11 Ex´ ecution d’op´ eration concurrentes [82]. . . . 59
5.12 Gestion de la concurrence par transformation d’op´ eration. . . 59
5.13 Gestion des conflits par ex´ ecution r´ eversible. . . . 60
6.1 Ajout du composant Coopeer. . . . 64
6.2 Contenu d’un message et de son estampille. . . . . 64
6.3 Gestion de l’ordonnancement de Coopeer. . . . 65
6.4 Gestion de la simultan´ eit´ e de Coopeer. . . . . 65
6.5 Exemple n
◦1 de conflits g´ er´ es par Coopeer. . . . 68
6.6 Exemple n
◦2 de conflits g´ er´ es par Coopeer. . . . 69
6.7 Exemple n
◦3 de conflits g´ er´ es par Coopeer. . . . 70
6.8 Exemple n
◦4 de conflits g´ er´ es par Coopeer. . . . 71
6.9 Impact de la gestion de l’ordonnancement sur l’interface uti- lisateur. . . . 73
6.10 Impact de la gestion de la simultan´ eit´ e sur l’interface utilisateur. 74 6.11 Les trois onglets de la fenˆ etre de contrˆ ole de Coopeer. . . . 75
6.12 Application de CAO au sein de laquelle Coopeer a ´ et´ e int´ egr´ e. 76 6.13 Application d’annotation collaborative 3D. . . . 77
7.1 Classification des pannes [34]. . . . 80
7.2 Exemple de panne g´ er´ ee par Coopeer. . . . 82
7.3 Exemple d’op´ eration rat´ ee par un nouveau participant. . . . . 83
7.4 Exemple de r´ ecup´ eration d’une op´ eration manquante. . . . 84
7.5 Exemple d’op´ eration rat´ ee qui est annul´ ee. . . . 85
C.1 Different approaches for a design conference [18]. . . . . 97
C.2 Consistency via Shared State [59]. . . . 98
C.3 Examples of frequently used topologies [86]. . . . 98
C.4 Classification of concurrency control approaches [9]. . . . 99
C.5 Fault classification [34]. . . 100
Liste des tableaux
1 Utilisation de la CAO ` a travers le temps et l’espace [48, 20]. . 11
1.1 Comparaison des architectures client/serveur et d’´ egal ` a ´ egal. . 23
2.1 Exemples de produits utilisant le partage d’application. . . . . 26
2.2 Produits permettant la conception collaborative. . . . 27
2.3 Projets de recherche en conception collaborative. . . . 35
2.4 L´ egende du tableau 2.3. . . . . 35
5.1 Niveaux d’optimisme pour le verrouillage [31]. . . . 57
5.2 Trois degr´ es de coh´ erence [41]. . . . 58
6.1 Exemple de crit` eres pour calculer une priorit´ e en fonction des conditions de connexion. . . . 72
C.1 The use of CAD across time and space [48, 20]. . . . 97
C.2 Levels of optimism for locking [31]. . . . 99
9
Introduction
La conception collaborative repr´ esente une nouvelle opportunit´ e pour l’in- dustrie : convevoir un produit depuis des sites distants de fa¸con collaborative.
En ´ evitant le d´ eplacement des personnes, on r´ eduit les coˆ uts. On acc´ el` ere aussi les processus de d´ eveloppement en limitant le temps n´ ecessaire au cycle de conception. Ainsi, les produits sont prˆ ets ` a ˆ etre mis sur le march´ e plus rapidement. On a l` a une nouvelle m´ ethode de travail pour les entreprises
´ etendues.
Cette th` ese se place dans ce cadre et a pour objectif de rendre possible le sc´ enario suivant : concevoir ` a plusieurs un mˆ eme mod` ele
3` a l’aide d’une application de CAO
4, en mˆ eme temps et grˆ ace ` a un r´ eseau tel qu’Internet.
Il s’agit de conception collaborative
5(voir tableau 1 [48, 20]) et nous nous int´ eresserons plus particuli` erement ` a la conception de pi` eces m´ ecaniques.
En mˆ eme A des moments ` temps diff´ erents Au mˆ eme CAO avec un seul CAO avec gestion endroit utilisateur de donn´ ees A des endroits ` Conception CAO diff´ erents collaborative distribu´ ee
Tab. 1 – Utilisation de la CAO ` a travers le temps et l’espace [48, 20].
Les applications de CAO sont lourdes et complexes, et les architectures collaboratives existantes ne peuvent s’y appliquer
6. L’ambition de ce projet est donc de proposer une architecture collaborative applicable aux applica- tions de CAO et de ce fait, ` a toute une gamme d’applications dont le passage en mode collaboratif est loin d’ˆ etre ´ evident (un tableur complet par exemple,
3
Au sens mod` ele de l’objet qui sera construit.
4
Conception assist´ ee par ordinateur.
5
Collaborative design en anglais.
6
Nous allons voir pourquoi.
11
dont le contenu des cellules peut comporter une s´ emantique assez complexe).
Pour cela, nous partirons d’une premi` ere probl´ ematique, le partage de donn´ ees
7, afin de mettre en ´ evidence les probl` emes que cela pose :
– le chapitre 1 pr´ esente le contexte de la conception collaborative ; – le chapitre 2 fait un tour des solutions existantes ;
– le chapitre 3 d´ ecrit l’architecture que nous choisissons comme base.
Puis, nous utiliserons ces probl` emes comme support de r´ eflexion pour ´ elaborer une m´ ethode de gestion des conflits :
– le chapitre 4 pr´ esente le probl` eme de la gestion des conflits ;
– le chapitre 5 est un ´ etat de l’art des diff´ erents aspects qui sont li´ es aux syst` emes distribu´ es et que nous avons ` a notre disposition pour r´ esoudre ce probl` eme ;
– le chapitre 6 d´ ecrit notre m´ ethode, Coopeer.
Enfin, nous ´ etendrons cette m´ ethode de fa¸con ` a g´ erer le groupe de travail et la tol´ erance aux pannes (chapitre 7) avant de conclure (chapitre 8).
7
C’est-` a-dire permettre aux multiples instances de l’application pr´ esente sur le r´ eseau
d’avoir acc` es aux mˆ emes donn´ ees.
Chapitre 1
Contexte de la conception collaborative
1.1 Introduction
Dans ce chapitre, nous allons voir en quoi une application de CAO pose probl` eme pour le partage de donn´ ees, et notamment en ce qui concerne la coh´ erence de ces donn´ ees. Nous verrons aussi quelle architecture r´ eseau nous convient le mieux.
1.2 Contraintes li´ ees aux applications de CAO
1.2.1 Introduction
Une application de CAO est un syst` eme complexe que nous opposons en cela aux ´ editeurs de texte et aux tableaux blancs dont le partage des donn´ ees ne pose plus actuellement de probl` eme majeur.
Une application de CAO permet de concevoir un objet, c’est-` a-dire d’en construire un mod` ele informatique. Les mod´ elisations en 3D
1de logiciels comme CATIA ou SolidWorks (voir figure 1.1) fournissent une maquette num´ erique qui remplace les blocs de mousse utilis´ es auparavant dans les phases de conception.
1.2.2 Poids des donn´ ees et longueur des calculs
Un moteur d’avion, par exemple, est un objet tr` es complexe, sa maquette num´ erique peut peser tr` es lourd en m´ emoire. Certains assemblages peuvent
1
Trois dimensions.
13
Fig. 1.1 – SolidWorks, une application de CAO largement diffus´ ee.
atteindre plusieurs centaines de Mo et la mise ` a jour d’une pi` ece peut en- traˆıner des temps de calcul pouvant d´ epasser la minute.
Par cons´ equent, dans la mesure o` u le d´ ebit entre les machines des parti- cipants peut ˆ etre faible (par exemple, quelques Ko par seconde), il n’est pas possible de transmettre r´ eguli` erement l’ensemble des donn´ ees sur le r´ eseau dans un contexte de conception collaborative. Chaque participant doit dis- poser de l’ensemble des donn´ ees localement.
1.2.3 Complexit´ e de l’architecture
De nombreux composants interagissent dans une application de CAO. Ci- tons les principaux (voir figure 1.2) : le modeleur feature
2qui g` ere les sp´ ecifi- cations de l’utilisateur (nous aborderons ce composant de fa¸con plus pr´ ecise dans la section suivante), le solveur de contraintes qui cherche une solution sa- tisfaisant toutes les contraintes qui ont ´ et´ e pos´ ees et le modeleur g´ eom´ etrique qui g` ere la repr´ esentation tridimensionnelle de l’objet (repr´ esentation B- Rep
3).
2
Autrement dit, le modeleur de donn´ ees.
3
Boundary Representation.
1.2. CONTRAINTES LI ´ EES AUX APPLICATIONS DE CAO 15 Lorsqu’un mod` ele est mis ` a jour, le solveur de contraintes intervient pour fixer les valeurs du modeleur feature et le modeleur g´ eom´ etrique peut alors construire la repr´ esentation g´ eom´ etrique.
Application
Utilisateur
Solveur de contrainte
Modeleur feature
Modeleur géométrique
Fig. 1.2 – Vision simplifi´ ee d’une application de CAO.
1.2.4 Complexit´ e du mod` ele de donn´ ees
Beaucoup d’applications de CAO sont bas´ ees sur un mod` ele de donn´ ees de type prototype-instance. Il s’agit d’un mod` ele orient´ e objet particuli` erement dynamique. Une instance peut ˆ etre utilis´ ee pour cr´ eer de nouveaux objets, elle est alors consid´ er´ ee comme leur prototype.
On donne le nom de feature
4aux objets. Ils sont agr´ eg´ es dans un arbre qui contient ainsi toutes les sp´ ecifications que l’utilisateur a pr´ ecis´ ees pour contruire son mod` ele. Du fait de sa chronologie, cet arbre de construction peut ˆ etre qualifi´ e d’historique (voir figure 1.3). Il s’agit de la repr´ esentation CSG
5(une description par assemblage de primitives solides ´ el´ ementaires sur lesquelles on effectue des op´ erations bool´ eennes).
Au sein d’un tel arbre, les relations sont tr` es nombreuses : h´ eritage dyna- mique (prototype/instances), relations d’agr´ egation (hi´ erarchie de l’arbre), op´ erations bool´ eennes, relations p` ere/fils (r´ ef´ erences de construction au ni- veau feature ou g´ eom´ etrique), contraintes (distance, angle, co¨ıncidence, etc.), formules (propri´ et´ es dynamiques) et scriptes (m´ ethodes dynamiques).
4
Toute personne connaissant un ´ equivalent satisfaisant en fran¸ cais est pri´ ee de contacter l’auteur...
5
Constructive Solid Geometry.
Fig. 1.3 – Exemple d’arbre de construction avec la g´ eom´ etrie associ´ ee.
1.2.5 Nommage g´ en´ erique
Le nommage g´ en´ erique
6[10, 42, 93] est une bonne illustration de la com- plexit´ e d’une application de CAO. Il s’agit de ce que nous avons appel´ e r´ ef´ erences de construction au niveau g´ eom´ etrique dans la section pr´ ec´ edente.
Lorsque l’utilisateur ajoute un cong´ e
7` a un cube, il doit pr´ eciser l’arˆ ete concern´ ee ` a l’aide de la souris. Or, il n’existe pas dans l’arbre de feature correspondant ` a cette arˆ ete. La r´ ef´ erence de construction ne se fait donc pas au niveau feature , mais au niveau g´ eom´ etrique. Il y a interaction avec le modeleur g´ eom´ etrique pour trouver un nom unique ` a l’arˆ ete en fonction de la g´ eom´ etrie d´ ej` a cr´ e´ ee. Ce nom est dit g´ en´ erique car il doit ˆ etre valide quelle que soit la configuration, il doit toujours d´ esigner la mˆ eme arˆ ete.
Ainsi, on fait r´ ef´ erence dans le modeleur feature, au niveau du feature n par exemple (un cong´ e), ` a de la g´ eom´ etrie qui aura ´ et´ e construite par le modeleur g´ eom´ etrique sur la base des n − 1 features pr´ ec´ edents.
Dans la mˆ eme ´ equipe et parall` element au projet de conception colla- borative, une ´ etude a permis de concevoir un nouveau type de nommage
6
Generic naming en anglais, ou identification topologique.
7
Fillet en anglais, arrondi d’une arˆ ete.
1.2. CONTRAINTES LI ´ EES AUX APPLICATIONS DE CAO 17 g´ en´ erique. L’id´ ee est d’ajouter ` a un modeleur g´ eom´ etrique existant une cou- che logicielle de d´ ecodage et d’encodage dans un langage de nommage g´ en´ e- rique universel.
Cela permet notamment les utilisations suivantes :
– l’utilisateur peut sp´ ecifier lui-mˆ eme les noms g´ en´ eriques, sans que le syst` eme ne les g´ en` ere ` a partir des interactions ` a la souris ;
– il peut aussi le faire dans un scripte ;
– les noms g´ en´ eriques peuvent traverser le r´ eseau et ˆ etre compris de la mˆ eme fa¸con sur une autre machine (ce qui pose probl` eme avec cer- tains types de nommage g´ en´ erique, notamment s’ils se basent sur des identifiants d´ ependants de l’´ etat du modeleur g´ eom´ etrique) ;
– les noms g´ en´ eriques peuvent ˆ etre compris de la mˆ eme fa¸con par un autre modeleur g´ eom´ etrique auquel on aurait ajout´ e le support du mˆ eme langage.
Ce type de nommage g´ en´ erique est donc int´ eressant pour la conception collaborative. Par ailleurs, il se r´ ev` ele particuli` erement puissant et productif.
Par exemple, lorsqu’il s’agit de poser des cong´ es sur toutes les arˆ etes issues de la face sup´ erieure d’un cube sur laquelle on aurait fait de nombreuses rigoles, une seule ligne suffit (voir le champ de saisie de la figure 1.4). Le travail de cette ´ etude fait aussi l’objet d’un d´ epˆ ot de brevet sous le nom de Cell Descriptor [95].
1.2.6 Conclusion
Lors d’une session de travail collaboratif, il n’est pas possible d’´ echanger en continu les donn´ ees. Celles-ci doivent ˆ etre r´ epliqu´ ees
8afin que l’´ echange d’information se limite ` a la description des op´ erations ` a effectuer pour pr´ e- server la coh´ erence des r´ eplicats.
Cela suppose une organisation particuli` ere en ce qui concerne l’archi- tecture de l’application. Cette derni` ere doit permettre l’identification d’une op´ eration et de ses arguments d’une part (chez l’auteur de l’op´ eration) et l’ex´ ecution de l’op´ eration ` a partir de cette identification d’autre part (chez les autres utilisateurs).
La complexit´ e du mod` ele de donn´ ees et de l’architecture nous place devant un constat simple : il n’est pas possible de pr´ evoir l’impact qu’aura une op´ eration. Il n’est pas possible non plus de partitionner les donn´ ees (l’arbre de construction) pour ´ eviter la r´ eplication totale car attribuer une partie d’une pi` ece m´ ecanique ` a un utilisateur, comme on pourrait le faire avec le
8
Les donn´ ees sont t´ el´ echarg´ ees sur les machines des participants qui rejoignent la session
de conception collaborative.
Fig. 1.4 – Exemple d’utilisation du langage Cell Descriptor.
paragraphe d’un texte, reviendrait le plus souvent ` a lui attribuer toute la pi` ece tant les relations sont nombreuses.
1.3 Gestion de la coh´ erence de donn´ ees r´ epli- qu´ ees
1.3.1 Pr´ esentation du probl` eme
On ne peut pas diviser l’arbre en sous parties ind´ ependantes et l’on ne peut donc pas permettre les op´ erations simultan´ ees.
En effet, toutes les op´ erations doivent ˆ etre effectu´ ees exactement dans le mˆ eme ordre sur toutes les machines, le probl` eme ´ etant d’obtenir strictement le mˆ eme r´ esultat chez tous les participants. Si deux features n’ont pas le mˆ eme ordre dans l’arbre de construction sur deux machines diff´ erentes, le r´ esultat peut ne pas provoquer d’erreur mais ˆ etre diff´ erent. L’´ etat global des donn´ ees est alors incoh´ erent, les r´ eplicats divergent.
Par exemple, si un utilisateur pose un cong´ e avec propagation selon les
tangences (c
1) sur une arˆ ete d’un cube et qu’un autre utilisateur pose, au
mˆ eme moment, un autre cong´ e avec propagation minimale (c
2) sur une arˆ ete
1.3. GESTION DE LA COH ´ ERENCE DE DONN ´ EES R ´ EPLIQU ´ EES 19 adjacente, on aura finalement, apr` es l’´ echange des op´ erations sans utiliser de protocole de gestion de la coh´ erence, deux arˆ etes arrondies sur la premi` ere machine (voir haut de la figure 1.5) et trois sur la seconde (voir bas de la figure 1.5).
Fig. 1.5 – Exemple n
◦1 de causalit´ e non respect´ ee.
La figure 1.6 pr´ esente un exemple plus complet qui montre comment les r´ eplicats peuvent diverger, mˆ eme si les arˆ etes sur lesquelles on pose des cong´ es appartiennent ` a des solides diff´ erents. On a dans cet exemple deux solides li´ es par une op´ eration d’union et un cong´ e sur l’un des deux qui va propager c
1sur une arˆ ete commune aux deux solides. Si c
1est pos´ e avant c
2, il se propagera deux fois (voir haut de la figure 1.6). S’il est pos´ e apr` es c
2, il se propagera trois fois (voir bas de la figure 1.6).
1.3.2 Contexte social
Le sc´ enario de conception collaborative que nous ´ etudions est proche, au niveau humain, d’une r´ eunion. Dans ce contexte, il y a souvent moins de dix personnes et les participants s’expriment les uns apr` es les autres (sachant que l’un des participants peut animer la r´ eunion, celui qui l’a organis´ ee par exemple).
La session de travail collaboratif s’architecture autour d’une discussion (ils
ne parlent pas tous en mˆ eme temps), comme dans une r´ eunion dont l’objet se-
Fig. 1.6 – Exemple n
◦2 de causalit´ e non respect´ ee.
rait la construction d’une pi` ece m´ ecanique, le lien social entre les participants pouvant par exemple s’´ etablir grˆ ace ` a une conf´ erence t´ el´ ephonique ou vid´ eo.
On consid` ere ainsi les op´ erations simultan´ ees comme des ´ ev´ enements rela- tivement peu fr´ equents et dont les participants pourront comprendre qu’ils n´ ecessitent un traitement particulier [76].
1.4 Architecture r´ eseau
1.4.1 Introduction
Deux grands types d’architectures s’opposent lorsqu’il s’agit de collaborer grˆ ace ` a Internet : l’architecture client/serveur et l’architecture d’´ egal ` a ´ egal
9(voir figure 1.7).
9
On dit aussi pair ` a pair ou peer-to-peer en anglais.
1.4. ARCHITECTURE R ´ ESEAU 21
Fig. 1.7 – Architectures client/serveur et d’´ egal ` a ´ egal.
1.4.2 Client/serveur
L’architecture client/serveur est tr` es r´ epandue sur Internet. Le Web en est sˆ urement l’exemple le plus ´ evident : les navigateurs envoient des requˆ etes aux serveurs Web qui leur fournissent des pages HTML et autres ´ el´ ements de pr´ esentation en retour. Les serveurs h´ ebergent donc des donn´ ees, mais ils peuvent aussi ex´ ecuter des op´ erations ` a l’aide par exemple de scriptes CGI ou de servlets Java.
Dans notre cas, les donn´ ees et les traitements doivent se trouver sur les machines clientes (voir section 1.2.2, page 13). Le serveur ne peut donc ˆ etre qu’un serveur de communication g´ erant les messages et le groupe de travail.
Du fait de sa topologie, le mod` ele client/serveur contraint tous les mes- sages ` a passer par le serveur. Pour qu’un message passe d’un client ` a un autre, deux transmissions sont ainsi n´ ecessaires : du premier client au ser- veur, puis du serveur au second client. Il apparaˆıt alors que si le serveur tombe en panne, la session de travail collaboratif ne peut plus continuer. Le serveur en lui-mˆ eme pr´ esente aussi des contraintes : il faut une machine de plus que le nombre de participants, le cˆ ot´ e serveur de l’application doit ˆ etre d´ evelopp´ e s´ epar´ ement et il doit ˆ etre administr´ e.
Malgr´ e ces contraintes, l’architecture client/serveur propose aussi des fa-
cilit´ es int´ eressantes. La gestion du groupe de travail peut ˆ etre centralis´ ee,
ainsi qu’une partie de la gestion des messages. De plus, on peut imaginer que
le serveur remplisse d’autres services comme la sauvegarde ou la gestion des
diff´ erentes versions des donn´ ees. Enfin, les machines clientes ne sont donc pas
serveurs, il est inutile d’y ouvrir un port de communication.
1.4.3 D’´ egal ` a ´ egal
L’architecture d’´ egal ` a ´ egal se passe de serveur central. L’id´ ee est que chaque machine est ` a la fois cliente et serveur. Cette architecture a principa- lement ´ et´ e popularis´ ee par Napster
10, une application d’´ echange de fichiers musicaux. Mais Napster n’est finalement pas une bonne illustration puisqu’un serveur est utilis´ e comme index afin de r´ ef´ erencer les morceaux que poss` ede chaque utilisateur. On dit qu’il s’agit d’une architecture d’´ egal ` a ´ egal assist´ ee.
Un produit tel que Groove
11, qui propose diff´ erentes applications partag´ ees (tableau blanc, ´ editeur de texte, chat, etc.), est plus proche de notre cas. En effet, Groove ne n´ ecessite pas de serveur, mais peut utiliser un relais pour passer les pares feu.
Les avantages de cette architecture sont particuli` erement int´ eressants : la communication entre les machines est directe, donc rapide ; si l’une des machines tombe en panne, la session de travail collaboratif peut continuer ; on se passe naturellement d’un serveur et du travail qu’il faut lui consacrer.
Mais on ne retrouve pas les facilit´ es de l’architecture client/serveur : il faut mettre en place une gestion distribu´ ee des groupes et des messages, et il faut ouvrir un port de communication sur les machines pour qu’elles soient aussi serveurs.
1.4.4 Comparaison
Le tableau 1.1 compare ces deux architectures en fonction des crit` eres suivants :
– Communication : la transmission des informations est-elle directe ou indirecte ? Si elle est directe (elle ne passe pas par un serveur), elle est donc plus rapide.
– Gestion du groupe : a-t-on des facilit´ es pour g´ erer le groupe de travail ? – Tol´ erance aux pannes : quelle incidence peut avoir une panne sur la
session de travail collaboratif ?
– S´ ecurit´ e : l’architecture n´ ecessite-t-elle une ouverture sp´ ecifique pou- vant poser des probl` emes de s´ ecurit´ e, notamment au niveau d’un ´ even- tuel pare feu ?
– Installation : l’ajout de mat´ eriel est-il n´ ecessaire ? Un d´ eveloppement sp´ ecifique est-il n´ ecessaire pour le serveur ? Y a-t-il des coˆ uts suppl´ e- mentaires en administration ?
– Gestion des messages : la gestion des messages est-elle centralis´ ee ou distribu´ ee ?
10
http://www.napster.com/
11
http://www.groove.net/
1.4. ARCHITECTURE R ´ ESEAU 23
Client/serveur D’´ egal ` a ´ egal Communication Transmission indirecte des
messages, ils passent tous par le serveur ; deux clients ne peuvent pas dialoguer entre eux directement
Transmission directe des mes- sages ; chaque client connaˆıt les autres clients
Gestion du groupe
Gestion centralis´ ee du groupe Gestion r´ epartie du groupe
Tol´ erance aux pannes
La session de travail collabo- ratif se termine si le serveur tombe en panne
La panne d’une des machines ne p´ enalise pas la session de travail collaboratif
S´ ecurit´ e Les machines des participants ne sont que clientes
Les machines des participants doivent aussi ˆ etre serveurs Installation Un serveur est ´ evidemment
n´ ecessaire, il doit faire l’ob- jet d’un d´ eveloppement logiciel sp´ ecifique et il doit aussi ˆ etre administr´ e
Les machines des participants suffisent
Gestion des mes- sages
Le serveur peut faciliter la ges- tion des messages
Une gestion distribu´ ee sans as- sistance est n´ ecessaire
Tab. 1.1 – Comparaison des architectures client/serveur et d’´ egal ` a ´ egal.
1.4.5 Conclusion
L’architecture client/serveur pr´ esente des contraintes fortes sur lesquelles on ne peut pas revenir (communication, tol´ erance aux pannes et serveur en lui-mˆ eme). Par contre, les inconv´ enients de l’architecture d’´ egal ` a ´ egal (gestion du groupe, s´ ecurit´ e et gestion des messages) peuvent ˆ etre contourn´ es si l’on est capable de mettre en place des m´ ecanismes r´ esolvant ces probl` emes.
Nous choisissons donc cette solution.
Concernant la s´ ecurit´ e, on peut compter sur les administrateurs syst` eme des entreprises utilisatrices pour limiter le port d´ edi´ e ` a l’application au pro- tocole utilis´ e. Par ailleurs, nous n’abordons pas ici les probl` emes d’authen- tification et d’encryption ; ´ etant donn´ e le nombre important de solutions existantes, libre ` a chacun d’utiliser la m´ ethode qui lui convient.
Notons enfin qu’une architecture hybride telle que celle de la figure 1.8
cumule des inconv´ enients des deux autres types d’architectures (tol´ erance
aux pannes, serveur en lui-mˆ eme, s´ ecurit´ e et gestion des messages). Nous ne
retiendrons donc pas cette solution.
Fig. 1.8 – Exemple d’architecture hybride.
1.5 Conclusion
On retiendra principalement de ce chapitre que nos donn´ ees doivent ˆ etre
r´ epliqu´ ees, que l’on ne peut pas permettre les op´ erations simultan´ ees et que
nous choississons l’architecure d’´ egal ` a ´ egal.
Chapitre 2
Solutions de conception collaborative
2.1 Introduction
Nous pr´ esentons ici des solutions de conception collaborative suivant deux approches (voir figure 2.2 [18], sp´ ecialisation de la figure 2.1 [59]) : le partage d’application et le partage de donn´ ees. Nous commen¸cons par les produits commerciaux, les projets de recherche viennent ensuite.
Modèle
Vue
Affichage Affichage Fichier
Vue partagée
Modèle
Vue
Affichage Affichage Fichier
Modèle partagé
Vue
Modèle
Vue
Affichage Affichage Fichier
Fichier partagé
Vue Modèle
Fig. 2.1 – Coh´ erence via partage d’´ etat [59].
25
Maître
Modèle géométrique
Scène 3D
Image
Esclave
Image
Utilisateur A
Modèle géométrique
Scène 3D
Image
Utilisateur B
Image Modèle géométrique
Scène 3D Mes-
sages
Partage d'applic.
Fig. 2.2 – Diff´ erentes approches pour une conf´ erence de conception [18].
2.2 Produits
2.2.1 Partage d’application
Le partage d’application, avec des technologies telles que NetMeeting de Microsoft ou SameTime de Lotus, permet d’utiliser une mˆ eme application ` a plusieurs en mˆ eme temps. Bien que cette solution pr´ esente des limitations majeures (par exemple, tous les participants ont forc´ ement la mˆ eme vue
1), elle repr´ esente tout de mˆ eme une approche possible de la conception colla- borative. Dans les faits, elle est principalement utilis´ ee pour des sc´ enarios ponctuels d’expertise. Le tableau 2.1 donne quelques exemples de produits utilisant ce mode de collaboration.
Produit Editeur ´ Site Web
Inventor 4 Autodesk http://www.autodesk.com/
Solid Edge Exchange EDS http://www.eds.com/
SolidWorks 2001Plus SolidWorks http://www.solidworks.com/
Tab. 2.1 – Exemples de produits utilisant le partage d’application.
1
C’est le mode WYSIWIS [77] (What You See Is What I See ).
2.2. PRODUITS 27
2.2.2 Partage de donn´ ees
Le partage de donn´ ees nous concerne plus dans le sens o` u chaque par- ticipant dispose de l’application sur sa machine, contrairement au partage d’application o` u l’on offre un acc` es multiple ` a une mˆ eme application. Dans le partage d’application, on fait une distinction entre la machine maˆıtre qui fait tourner l’application et les machines esclaves. Ce n’est pas n´ ecessaire dans le partage de donn´ ees et on peut ainsi envisager des architectures d’´ egal ` a
´ egal. Les solutions commerciales de partage de donn´ ees pr´ esentent de fortes restrictions (voir la synth` ese du tableau 2.2), tant en termes de gestion des conflits qu’en termes de fonctionnalit´ es.
Produit Editeur ´ Site Web
Alibre Design Alibre http://www.alibre.com/
(voir figure 2.3) Conception collaborative o` u il faut demander la main sur le mod` ele pour y apporter des modifications
IX SPeeD ImpactXoft http://www.impactxoft.com/
Conception collaborative dans laquelle chaque participant envoie les modifications de son choix au moment o` u il le d´ esire ; les participants doivent g´ erer eux-mˆ emes les conflits OneSpace CoCreate http://www.cocreate.com/
Conception collaborative limit´ ee ` a certains types de modifications sur de la g´ eom´ etrie (` a ce niveau, on a perdu les features ) ; les conflits peuvent provoquer des erreurs et l’intention des participants peut ne pas ˆ etre respect´ ee
Tab. 2.2 – Produits permettant la conception collaborative.
2.2.3 R´ ef´ erences
Voici une s´ election de tests particuli` erement int´ eressants qui pr´ esentent des produits de conception collaborative :
– Greco (Joe), Real-Time 3D Collaboration, http://www.cadenceweb.
com/cadscope_zeroing/scopegreco.htm
– Greco (Joe), Alibre Design-Web-Based 3D CAD, mai 2000, http:
//www.cadenceweb.com/2000/0500/cadoptions0500.html
– Rowe (Jeffrey), Teamwork 24/7, juin 2000, http://www.mcadcafe.
com/MCADVision/June2000/Collaboration.html
– MacKrell (John), CoCreate OneSpace, f´ evrier 2001, http://www.
deskeng.com/articles/01/Feb/cover/main.htm
– Greco (Joe), The CAD Collaboration Trials, aoˆ ut 2001, http://cgw.
pennnet.com/Articles/Article_Display.cfm?Section=Articles&
Fig. 2.3 – Conception d’une poubelle avec Alibre Design.
Subsection=Display&ARTICLE_ID=108469
– Greco (Joe), The Best in Class ASPs, septembre 2001, http://www.
cadenceweb.com/2001/0901/issuefocus0901.html
– Greco (Joe), IX Speed, d´ ecembre 2001, http://www.deskeng.com/
articles/01/dec/cover/main.htm
– Greco (Joe) et Rowe (Jeffrey), Simultaneous Product Development With IX SPeeD, http://www.cadalog.com/articles.php?creview=
31_1
2.2.4 Conclusion
Les produits existants de conception collaborative selon l’approche qui
nous int´ eresse (le partage de donn´ ees) sont assez peu nombreux et ne pro-
posent qu’une collaboration limit´ ee par rapport ` a notre objectif. Il faut de-
mander la main dans Alibre Design, envoyer soi-mˆ eme ses modifications dans
IX SPeeD et se limiter ` a certains types de modifications dans OneSpace. Nous
voulons ne pas avoir ` a demander la main, la gestion de la session doit ˆ etre
automatique et toutes les op´ erations de conception doivent ˆ etre accessibles.
2.3. RECHERCHE 29
2.3 Recherche
2.3.1 Introduction
Il existe de nombreux projets de recherche sur le th` eme de la conception collaborative. Nous en d´ ecrivons bri` evement 16 dans la section suivante.
2.3.2 Projets
Teledesign [76] :
– ann´ ee de publication : 1994 ; – domaine : CAO ;
– architecture : r´ eplication des donn´ ees sur les clients, traitements sur les clients ;
– approche : acc` es s´ equentiel par passage de jeton ou acc` es simultan´ e avec ex´ ecution r´ eversible ;
– niveau de partage : mod` ele ; – cˆ ot´ e serveur : pas de serveur ;
– cˆ ot´ e client : application de CAO et composant de distribution ; – composant de collaboration : propri´ etaire.
Co-CAD [29] :
– ann´ ee de publication : 1994 ; – domaine : CAO ;
– architecture : r´ eplication des donn´ ees sur les clients, traitements sur les clients ;
– approche : m´ ecanismes de possession et de permissions d’acc` es ; – niveau de partage : objets ;
– cˆ ot´ e serveur : gestion des sessions ;
– cˆ ot´ e client : application de CAO (bas´ ee sur le modeleur g´ eom´ etrique ACIS) ;
– composant de collaboration : ABSI [27].
Atelier de sculpture virtuelle multi-utilisateurs [89] : – ann´ ee de publication : 1995 ;
– domaine : sculpture ;
– architecture : r´ eplication des donn´ ees sur les clients, traitements sur les clients ;
– approche : il faut poser un verrou sur un objet pour le modifier ; – niveau de partage : objets ;
– cˆ ot´ e serveur : gestion des sessions ;
– cˆ ot´ e client : application VIPER de sculpture ;
– composant de collaboration : VIPER [88].
Cocadam [38] :
– ann´ ee de publication : 1996 ; – domaine : CAO ;
– architecture : r´ eplication des donn´ ees sur les clients et le serveur, trai- tements sur les clients ;
– approche : il faut avoir la main sur le mod` ele pour y apporter des modifications ;
– niveau de partage : mod` ele ;
– cˆ ot´ e serveur : gestion des sessions, gestion de la g´ eom´ etrie, bases de donn´ ees pour les sessions et la g´ eom´ etrie ;
– cˆ ot´ e client : application de CAO (Anvil-5000), base de donn´ ees pour la g´ eom´ etrie, composants de distribution ;
– composant de collaboration : propri´ etaire.
DIVEdit [78] :
– ann´ ee de publication : 1996 ; – domaine : mod´ elisation 3D ;
– architecture : r´ eplication des donn´ ees sur les clients, traitements sur les clients ;
– approche : un objet ne peut ˆ etre modifi´ e que par un participant ` a la fois ;
– niveau de partage : objets ; – cˆ ot´ e serveur : liste des sessions ;
– cˆ ot´ e client : application DIVE de mod´ elisation 3D ;
– composant de collaboration : DIVE [11] (qui utilise ISIS [7]).
Synchronous Collaborative Design [48] : – ann´ ee de publication : 1997 ;
– domaine : CAO ;
– architecture : donn´ ees et traitements sur le serveur ;
– approche : il faut avoir la main sur le mod` ele pour y apporter des modifications ;
– niveau de partage : application ;
– cˆ ot´ e serveur : base de donn´ ees Postgres, application de CAO (Auto- CAD), outils d’annotation et de suivi des donn´ ees, espace de travail partag´ e ;
– cˆ ot´ e client : client l´ eger ;
– composant de collaboration : bas´ ee sur X Share [53].
ARCADE [79] :
2.3. RECHERCHE 31 – ann´ ee de publication : 1997 ;
– domaine : CAO ;
– architecture : r´ eplication des donn´ ees sur les clients, traitements sur les clients ;
– approche : un objet ne peut ˆ etre modifi´ e que par un participant ` a la fois ;
– niveau de partage : objets ;
– cˆ ot´ e serveur : gestion des sessions, base de donn´ ees ;
– cˆ ot´ e client : application de CAO propri´ etaire (bas´ ee sur le modeleur g´ eom´ etrique ACIS) ;
– composant de collaboration : propri´ etaire.
TOBACO [18, 92] :
– ann´ ees de publication : 1997 et 1999 ; – domaine : CAO ;
– architecture : r´ eplication des donn´ ees sur les clients, traitements sur les clients ;
– approche : il faut avoir la main sur le mod` ele pour y apporter des modifications ;
– niveau de partage : mod` ele ;
– cˆ ot´ e serveur : gestion et historique des sessions ;
– cˆ ot´ e client : application de CAO propri´ etaire [18] (bas´ ee sur le modeleur g´ eom´ etrique ACIS) ou AutoCAD augment´ e d’une extension [92] ; – composant de collaboration : TOBACO [18].
DCEE [52] :
– ann´ ee de publication : 1998 ; – domaine : CAO ;
– architecture : r´ eplication des donn´ ees sur les clients et le serveur, trai- tements sur les clients ;
– approche : la s´ election d’un objet verrouille celui-ci ; – niveau de partage : objets ;
– cˆ ot´ e serveur : gestion des sessions, bases de donn´ ees ; – cˆ ot´ e client : environnement collaboratif d’ing´ enierie ; – composant de collaboration : propri´ etaire.
CollIDE [56] :
– ann´ ee de publication : 1998 ; – domaine : CAO ;
– architecture : r´ eplication des donn´ ees sur les clients et le serveur, trai-
tements sur les clients ;
– approche : chacun travaille sur sa partie des donn´ ees et peut r´ ecup´ erer celle des autres ;
– niveau de partage : pi` ece d’un assemblage ;
– cˆ ot´ e serveur : gestion des sessions, base de donn´ ees ;
– cˆ ot´ e client : application de CAO (Alias Studio) pour ´ editer ses donn´ ees, une fenˆ etre suppl´ ementaire pour visualiser la g´ eom´ etrie partag´ ee ; – composant de collaboration : GroupKit [71].
CSCW-FeatureM [80] :
– ann´ ee de publication : 1998 ; – domaine : CAO ;
– architecture : r´ eplication des donn´ ees sur les clients, traitements sur les clients ;
– approche : modifications l’un apr` es l’autre en se mettant d’accord par conf´ erence audio, contrˆ ole de la coh´ erence en fin de session en compa- rant les historiques ;
– niveau de partage : mod` ele ; – cˆ ot´ e serveur : pas de serveur ;
– cˆ ot´ e client : FeatureM (bas´ e sur le modeleur g´ eom´ etrique ACIS) ; – composant de collaboration : propri´ etaire.
Web Based Collaborative CAAD [4] : – ann´ ee de publication : 1999 ; – domaine : architecture ;
– architecture : r´ eplication des donn´ ees sur les clients et un serveur, trai- tements sur un ou plusieurs serveurs ;
– approche : chacun travaille sur une partie diff´ erente de la structure (avec possibilit´ e de d´ efinir des relations entre les diff´ erentes parties) ; – niveau de partage : partie d’une structure ;
– cˆ ot´ e serveur : gestion des sessions, modeleurs g´ eom´ etriques Plasm, base de donn´ ees DB2 pour la persistance et la gestion des acc` es concurrents ; – cˆ ot´ e client : interface vers Plasm et navigateur Web pour la visualisation
(Java et VRML) ;
– composant de collaboration : Shastra [2].
NetFeature [45] :
– ann´ ee de publication : 1999 ; – domaine : CAO ;
– architecture : r´ eplication des donn´ ees sur les clients et le serveur, trai- tements sur les clients et le serveur ;
– approche : pas de gestion des conflits ;
2.3. RECHERCHE 33 – niveau de partage : mod` ele ;
– cˆ ot´ e serveur : gestion des sessions, gestion de la g´ eom´ etrie bas´ ee sur ACIS, base de donn´ ees sur un autre serveur ;
– cˆ ot´ e client : navigateur Web (visualisation grˆ ace ` a Java3D) ; – composant de collaboration : propri´ etaire.
Collaborative Solid Modelling [12] : – ann´ ee de publication : 1999 ; – domaine : CAO ;
– architecture : r´ eplication des donn´ ees sur les clients et le serveur, trai- tements sur les clients et le serveur ;
– approche : il faut avoir la main sur le mod` ele pour y apporter des modifications, des op´ erations peuvent ˆ etre bloqu´ ees pour certains uti- lisateurs, gestion des versions multiples ;
– niveau de partage : mod` ele ;
– cˆ ot´ e serveur : gestion des sessions, gestion de la g´ eom´ etrie ; – cˆ ot´ e client : navigateur Web ;
– composant de collaboration : propri´ etaire.
webSpiff [90, 91] :
– ann´ ee de publication : 2000 ; – domaine : CAO ;
– architecture : donn´ ees et traitements sur le serveur ;
– approche : les op´ erations sont s´ erialis´ ees comme dans le produit Co- Create ;
– niveau de partage : donn´ ees ;
– cˆ ot´ e serveur : gestion des sessions, gestion de la g´ eom´ etrie (Spiff, bas´ e sur ACIS), serveur Web ;
– cˆ ot´ e client : navigateur Web (visualisation grˆ ace ` a VRML et Java3D ou des images fixes) ;
– composant de collaboration : propri´ etaire.
Syco3D [57] : – domaine : CAO ;
– ann´ ee de publication : 2001 ;
– architecture : r´ eplication des donn´ ees sur les clients, traitements sur les clients ;
– approche : chacun travaille sur sa partie des donn´ ees et peut r´ ecup´ erer celle des autres ;
– niveau de partage : pi` ece d’un assemblage ;
– cˆ ot´ e serveur : gestion des sessions ;
– cˆ ot´ e client : application de CAO propri´ etaire pour ´ editer ses donn´ ees, une fenˆ etre suppl´ ementaire pour visualiser les donn´ ees et les structures partag´ ees ;
– composant de collaboration : GroupKit [71].
2.3.3 Conclusion
Le tableau 2.3 (dont le tableau 2.4 est la l´ egende) permet de comparer rapidement les projets ´ evoqu´ es dans la section pr´ ec´ edente.
On y remarque un seul projet de partage d’application (Synchronous Col- laborative Design, pas de donn´ ees sur les clients), un seul projet purement client/serveur (webSpiff, uniquement de la g´ eom´ etrie sur les clients), deux projets sans gestion des conflits (CSCW-FeatureM et NetFeature) et deux projets sans serveur (Teledesign et CSCW-FeatureM). Les autres projets se distinguent suffisamment les uns des autres pour que l’on ne puisse pas les classer en cat´ egorie. Par contre, on peut observer une certaine ´ evolution dans le temps.
On peut notamment constater que depuis 1999, les projets se concentrent principalement sur la conception collaborative sur le Web avec partionnement des donn´ ees entre les participants. Les donn´ ees et les traitements ont ainsi tendance ` a passer d’un mode de r´ eplication sur les clients vers un mode plus centralis´ e.
Il est aussi int´ eressant de noter que les approches en ce qui concerne la ges-
tion des conflits sont assez contraignantes pour les participants (verrouillage
le plus souvent). On imagine ais´ ement qu’avec une m´ ethode de gestion des
conflits plus satisfaisante, on revienne vers un mod` ele r´ epliqu´ e, en se passant
de serveur, donc en architecture d’´ egal ` a ´ egal. C’est vers cette direction que
nous allons.
2.3. RECHERCHE 35
Projets An Dm Dn Tr Ap Nv Sr Cl
Teledesign [76] 1994 C C C V E M - A C
Co-CAD [29] 1994 C C C V O S A
SVMU [89] 1995 S C C V O S A
Cocadam [38] 1996 C S C C V M S G B A B C
DIVEdit [78] 1996 M C C V O S A
SCD [48] 1997 C S S V A S B A F L
ARCADE [79] 1997 C C C V O S B A
TOBACO [18, 92] 97/99 C C C V M S H A
DCEE [52] 1998 C S C C V O S B A
CollIDE [56] 1998 C S C C P P S B A F
CSCW-Feature [80] 1998 C C C - M - A
WBC CAAD [4] 1999 A S C S P M S G B W F
NetFeature [45] 1999 C S C S - M S G B W
CSM [12] 1999 C S C S V P S G W
webSpiff [90, 91] 2000 C S S S D S G W W
Syco3D [57] 2001 C C C P P S A F
Tab. 2.3 – Projets de recherche en conception collaborative.
An Ann´ee de publication
Dm Domaine Cpour CAO,Spour sculpture etMpour mod´elisation 3D Dn Donn´ees Spour sur le serveur etCpour r´eplication sur les clients Tr Traitements Spour sur le serveur etCpour sur les clients
Ap Approche V pour verrouillage, P pour partitionnement, S pour s´erialisation,Epour ex´ecution r´eversible et-pour pas de ges- tion des conflits
Nv Niveau
de partage
Opour objets,Mpour mod`ele,Apour application,Ppour pi`ece d’un assemblage etDpour donn´ees
Sr Cˆot´e serveur Spour gestion des sessions,Gpour gestion de la g´eom´etrie,B pour base de donn´ees,Apour application de CAO ou autre, Hpour historique des sessions,Wpour serveur Web et-pour pas de serveur
Cl Cˆot´e client Apour application de CAO ou autre,Bpour base de donn´ees, Cpour composant de distribution,Lpour client l´eger,Fpour fenˆetre suppl´ementaire etWpour navigateur Web
SVMU Sculpture virtuelle multi-utilisateurs SCD Synchronous Collaborative Design WBC CAAD Web Based Collaborative CAAD CSM Collaborative Solid Modelling
Tab. 2.4 – L´ egende du tableau 2.3.
Chapitre 3
Une architecture d’´ egal ` a ´ egal
3.1 Introduction
Sur la base des conclusions de notre ´ etude, nous avons choisi une solution nous permettant de partager les donn´ ees d’une application de CAO. Cette infrastructure de communication nous servira notamment de plate-forme de test pour mettre en ´ evidence diff´ erents probl` emes.
3.2 Premier sc´ enario de collaboration
Le sc´ enario suivant repr´ esente le protocole exp´ erimental de base :
1. Un utilisateur d´ ecide de partager le mod` ele sur lequel il est en train travailler.
2. D’autres utilisateurs, qui disposent de la mˆ eme application, rejoignent la session de travail collaboratif, le mod` ele est transf´ er´ e sur leur ma- chine.
3. Les diff´ erents participants r´ ealisent localement des op´ erations sur le mod` ele, elles sont communiqu´ ees aux autres participants.
4. On v´ erifie manuellement que la coh´ erence des donn´ ees est respect´ ee (` a la fin de la session, les donn´ ees doivent ˆ etre identiques sur toutes les machines).
3.3 Architecture r´ eseau
L’architecture d’´ egal ` a ´ egal a ´ et´ e retenue. Conscients des probl` emes qu’elle pose en termes de gestion des messages et du groupe de travail, nous nous fixons comme objectif de les r´ esoudre dans la suite de ce travail.
37
Lorsqu’un utilisateur d´ ecide de partager le mod` ele qu’il est en train d’´ editer, celui-ci est mis ` a disposition sur le r´ eseau. Un autre utilisateur peut alors interroger la machine du premier et choisir de rejoindre la session de conception collaborative. L’ensemble des donn´ ees constituant le mod` ele est alors transf´ er´ e, ainsi que les informations concernant la session (en particulier la liste des participants et l’historique).
Le groupe de travail est donc g´ er´ e de fa¸con distribu´ ee. Chaque utilisateur dispose de la liste des participants qui est mise ` a jour de la fa¸con suivante : lorsqu’un participant fourni le mod` ele ` a un nouvel arrivant, il informe les autres de son arriv´ ee.
3.4 Transmission des op´ erations
Les donn´ ees sont r´ epliqu´ ees sur chaque machine. Elles ne circulent pas sur le r´ eseau
1, ce sont les op´ erations qui y transitent. ` A chaque fois qu’une op´ eration est ex´ ecut´ ee, elle est transmise aux autres machines du groupe de travail. De cette fa¸con, en partant des mˆ emes donn´ ees et en y appliquant les mˆ emes op´ erations dans le mˆ eme ordre avec la mˆ eme application, on devrait obtenir le mˆ eme r´ esultat.
Les op´ erations que nous transmettons sont celles qui ont un impact sur les donn´ ees (par exemple, le changement de point de vue n’est pas envoy´ e).
Nous devons envoyer un identifiant pour l’op´ eration, mais aussi le contexte de son ex´ ecution. Par exemple, pour la suppression d’un ´ el´ ement de l’arbre de construction, il faudra envoyer l’identifiant de l’op´ eration de suppression, mais aussi l’identifiant de l’´ el´ ement qui doit ˆ etre d´ etruit.
Une op´ eration complexe peut ˆ etre d´ ecrite comme une suite d’op´ erations
´ el´ ementaires sur les donn´ ees. Si une machine ne dispose pas de l’op´ eration, il sera ainsi possible de lui communiquer sa description.
3.5 Composant de partage de donn´ ees
L’impact au niveau de l’architecture applicative correspond ` a l’ajout d’un composant de distribution, le Distributeur (voir figure 3.1), qui a les fonctions suivantes :
– envoi des op´ erations locales aux autres participants ; – r´ eception des op´ erations des autres participants ;
– gestion de la session de travail collaboratif (notamment le groupe).
1
Sauf lorsqu’un participant rejoint la session.
3.6. CONCLUSION 39
Application
Utilisateur
Solveur de contrainte
Modeleur feature
Modeleur géométrique
Réseau Distributeur
Fig. 3.1 – Int´ egration du composant Distributeur.
3.6 Conclusion
Notre solution a ´ et´ e impl´ ement´ ee dans une application de CAO existante.
Les avantages de l’architecture d’´ egal ` a ´ egal ont ´ et´ e v´ erifi´ es (transmission rapide des op´ erations, pas de serveur ` a installer ou qui peut tomber en panne) et plus g´ en´ eralement, les probl` emes pressentis ont ´ et´ e mis en ´ evidence.
On observe des versions divergentes suite aux ´ ev´ enements suivants : – mauvais ordonnancement des messages ;
– op´ erations simultan´ ees ;
– connexion au groupe de travail ; – panne d’une ou plusieurs machines.
C’est donc sur ces points que nous allons travailler afin d’obtenir une
nouvelle m´ ethode assurant la coh´ erence des donn´ ees r´ epliqu´ ees.
Chapitre 4
Probl` eme de la gestion des conflits
4.1 Introduction
Comme nous l’avons vu, nous sommes en architecture d’´ egal ` a ´ egal. Les donn´ ees sont r´ epliqu´ ees et les op´ erations sont ´ echang´ ees entre les partici- pants grˆ ace ` a un composant de distribution. Ce composant de distribution, qui permet principalement l’envoi ` a tous les autres participants d’op´ erations au sein de messages et leur r´ eception, n’apporte pas de propri´ et´ es particuli` ere au syst` eme. On a notamment aucune assurance sur la fiabilit´ e ou l’ordre des messages. Sur cette base, les tests pratiques de notre impl´ ementation ont permis de valider la pr´ esence de deux types de conflits : les conflits d’ordon- nancement et les conflits de simultan´ eit´ e. Dans ce chapitre, nous allons les d´ efinir, puis nous pr´ eciserons le cadre de notre intervention.
4.2 Conflits d’ordonnancement
Un conflit d’ordonnancement survient lorsqu’au moins deux messages sont re¸cus par une machine dans un ordre diff´ erent de celui de l’´ emission (voir figure 4.1).
4.3 Conflits de simultan´ eit´ e
Un conflit de simultan´ eit´ e survient lorsqu’au moins deux op´ erations sont effectu´ ees au mˆ eme moment sur deux machines diff´ erentes, c’est-` a-dire lors- qu’aucune ne d´ epend de l’autre (voir figure 4.2).
41
Fig. 4.1 – Conflit d’ordonnancement.
f
e g
h
Fig. 4.2 – Conflit de simultan´ eit´ e.
4.4 Exemples
Les figures 4.3 et 4.4 pr´ esentent les effets des deux types de conflits.
Premier exemple. Le premier participant pose un cong´ e sur une arˆ ete (4.3.a). Le second participant ne fait rien (4.3.d). Puis, le premier participant vide la pi` ece (4.3.b). Le second participant re¸coit cette op´ eration (4.3.e). Il ne re¸coit le cong´ e qu’apr` es. Les op´ erations n’ont donc pas ´ et´ e ex´ ecut´ ees dans le mˆ eme ordre et le r´ esultat est diff´ erent sur les deux machines.
Second exemple. Au mˆ eme moment, le premier participant augmente la hauteur de la pi` ece (4.4.a) et le second participant diminue cette mˆ eme hauteur (4.4.d). Les op´ erations sont ex´ ecut´ ees localement (4.4.b et 4.4.e).
Puis, chaque machine ex´ ecute l’op´ eration provenant de l’autre (4.4.c et 4.4.f).
L` a aussi, le r´ esultat est diff´ erent sur les deux machines.
4.5 Ordonnancement et TCP/IP
Les conflits d’ordonnancement sont r´ esolus par TCP/IP si les deux ma-
chines utilisent une connexion permanente comme une socket (mode connec-
t´ e). Par contre, ce n’est pas le cas lorsqu’elles sont connect´ ees par intermit-
tence, par exemple grˆ ace ` a des requˆ etes XML sur HTTP (mode d´ econnect´ e).
4.6. RESPECT DE L’INTENTION DE L’UTILISATEUR 43
a b c
d e f
Fig. 4.3 – Exemple de conflit d’ordonnancement.
a b c
d e f
Fig. 4.4 – Exemple de conflit de simultan´ eit´ e.
Le probl` eme n’est pas r´ esolu non plus si les messages sont envoy´ es par plus d’une machine (voir figure 4.5).
4.6 Respect de l’intention de l’utilisateur
En cas d’op´ erations simultan´ ees, on peut ˆ etre tent´ e d’ex´ ecuter les op´ era-
tions dans le mˆ eme ordre sur toutes les machines, les s´ erialiser. En architec-
Fig. 4.5 – Conflit d’ordonnancement avec trois machines.
ture client/serveur, cet ordre peut-ˆ etre donn´ e par le serveur.
Si la seconde op´ eration provoque une erreur, on peut pr´ evenir son auteur qu’il n’est pas possible de l’ex´ ecuter correctement (par exemple : la modifi- cation d’un ´ el´ ement apr` es sa suppression). Si elle ne provoque pas d’erreur, il se peut qu’il n’y ait pas de probl` eme, mais il se peut aussi que l’utilisateur constate une diff´ erence entre ce qu’il voulait faire et ce qui a effectivement
´ et´ e fait. Dans ce cas, le syst` eme ne respecte pas son intention.
La figure 4.6, sur la base des exemples de la section 1.3.1 (page 18), pr´ esente un cas d’intention non respect´ ee.
4.7 Contraintes
Voici les contraintes que nous nous fixons pour g´ erer les conflits : – g´ erer les conflits d’ordonnancement ;
– g´ erer les conflits de simultan´ eit´ e ;
– r´ esoudre les conflits de fa¸con automatique ;
– ne pas allonger le temps de r´ eponse de l’application, les op´ erations doivent ˆ etre ex´ ecut´ ees d` es qu’elles sont invoqu´ ees ;
– ne pas ajouter d’interm´ ediaire pour la transmission des messages ; – ne pas augmenter la taille des messages de mani` ere significative ; – limiter l’ajout de messages en plus de la transmission des op´ erations ; – conserver l’architecture d’´ egal ` a ´ egal ;
– ne pas tenir compte de la s´ emantique des op´ erations ; – respecter l’intention de l’utilisateur ;
On ajoutera aussi par la suite :
– autoriser la connexion et la d´ econnexion d’utilisateurs en cours de ses- sion ;
– ˆ etre tol´ erant aux pannes.
4.8. AUTRES CARACT ´ ERISTIQUES 45
Modèle initial sur le serveur : les clients 1 et 2 téléchargent
ce même modèle
Souhait du client 1 : un congé qui se propage une fois
Résultat des deux opérations : le congé du client 1 se
propage deux fois Opération simultanée du client 2 qui
est exécutée avant celle du client 1 sur le serveur (congé de gauche)
Fig. 4.6 – Exemple de non respect de l’intention de l’utilisateur.
4.8 Autres caract´ eristiques
Et voici quelques caract´ eristiques globales du syst` eme sur lesquelles nous pourrons compter :
– les participants disposent d’un syst` eme de communication qui structure la session autour d’une discussion (voir section 1.3.2, page 19) ;
– ils comprennent ainsi que le syst` eme doive parfois intervenir, on pourra par exemple annuler leur derni` ere op´ eration (cela suppose donc que l’application dispose d’une op´ eration d’annulation
1) ;
– on accepte aussi que les donn´ ees soient temporairement diff´ erentes d’une machine ` a l’autre (divergence temporaire possible), pendant quel- ques op´ erations par exemple ;
1
