Les outils du travail coopératif La cohérence des données coopératives

Les outils du travail coopératif

La cohérence des données coopératives

Claude GodartUniversité Henri Poincaré Nancy1

Equipe ECOO, LORIA

Les outils du travail coopératif - La cohérence des données coopératives - ECOO - [email protected]

2/60

Problématique générale

Permettre à des personnes qui sont sur des sites différents, avec des décalages horaires importants, et dans des organisations différentes

de travailler « presque » aussi bien que si elles étaient dans la même pièce en même temps.

•Problématique•Gestion de versions•Gestion de transactions•Gestion de workflow•Editeurs synchrones•Conclusion


3/60

Mieux partager les données

• Gestion de versions• Gestion de transactions• Gestion de réplications• Gestion de procédés

• Plus de flexibilité, d’interactivité, d’intégration• Sans perdre cohérence, confidentialité, robustesse …



4/60

Plan

• Problématique• Gestion de versions• Gestion de transactions• Gestion de workflow• Editeurs synchrones• Conclusion

Intégrer la subtilité des interactions coopératives

pour mieux partager



6/60

T2

T1

Paradigme« Ingénierie concurrente »

read(m1)

Modify(m)

m1

Résultat intermédiaire

read(mf)

mf

write(mf)

Résultat final

r

Ecrire(r)

Compensation

read(mn)

write(m1)

mn

write(mn)

m2

write(m2)

Write(r1)

r1



7/60

rw• Client/Serveur

• Echange itératif de résultats intermédiaires, pas de modification concurrente

r/wr/w

• Ecriture Coopérative• Modifications simultanées de deux copies d’un même objet

Patrons de coopération

rw

rw

• Rédacteur/re-lecteur• Echange croisé de

résultats intermédiaires


+ dans : [Tata2001]

Gestion de versions



9/60

Le paradigme« Copy-Modify-Merge » • La référence• Le point de départ

Edit

CheckOut

User 0WS

User 1WS

Edit

Comm

itUpdateChe

ckOut

Copy

Merge

Modify

Repository



10/60

Gestion de versions(les + et les -)• Les + :

La référence pour le développement de logiciel Ça marche

• Les - : Pas de contrôle de la divergence, risque de

réconciliation difficile Lectures sales … Pas de base formelle … mais ça marche



11/60

Gestion de versions(Perspectives)• Intégration à la gestion de transactions

[Canals1998]• Mesure qualitative de la divergence (des deltas)

[Molli2002]• Amélioration de la convergence (relation entre

travail asynchrone et synchrone) [Bouazza2000]


Gestion de transactions



13/60

Gestion de transaction

• Transactions ACID• Modèles de transactions avancés (MTA)• Relation MTA / Workflow



14/60

Gestion des transactionsTransactions ACID

• La référence ACID Bien fondée : sérialisabilité Protocoles simples à mettre en œuvre :

• Ex : 2PL (2 Phases Locking)



15/60

La référence :les transactions ACID

• Atomicité: tout ou rien. Soit toutes les opérations de la transaction sont exécutées, soit aucune.

• Cohérence: une transaction prise individuellement fait passer la base d’un état cohérent dans un autre état cohérent.

• Isolation: une transaction n’observe que des états cohérents de la base (pas de résultat intermédiaire d’une autre transaction)

• Durabilité: lorsqu’une transaction termine, ses résultats deviennent permanents et ne peuvent plus être remis en cause, ni par une panne du système, ni par une autre transaction



16/60

Transactions ACID(les + et les -)• Les +

Bases saines : sérialisabilité Protocoles efficaces (2 PL)

• Correction • Gestion des « pannes », recouvrement

• Les - Atomicité trop forte pour des transactions de longue durée Isolation en opposition avec coopération Cohérence « à priori » impossible pour des tâches

« incertaines »



17/60

Modèles de transactions avancés• Dépasser les limites ACID• [Jajodia1997]• transactions emboîtées, Sagas, COO-transactions,

transactions flexibles, check-out/check-in, split/join, transactions coopératives, clients/sous-contractants, modèles à flot de tâches, transactions multi-niveaux

ProblématiqueGestion de versionsGestion de transactionsGestion de workflowEditeurs synchronesConclusyon


18/60

• Objectif relâcher la contrainte d’ « isolation », … ce qui permet

une forme de coopération

• Principe Saga = transaction ACD composée de sous-transactions

AID A chaque sous-transaction Ti est associée une transaction

de compensation CTi

Modèles de transactions avancés (SAGAS)



19/60

SAGAs

• R1 L’abandon d’une sous-transaction entraîne l’abandon de la saga (compensation des sous-transactions déjà exécutées)

• R2 La validation d’une sous-transaction n’est pas conditionnée par la validation de la saga

• R3 La transaction racine n’a pas la propriété d’isolation alors que ses sous-transactions l’ont



20/60

SAGAsExécutions autorisées

T1

T

TnTn-1T2 ……..

T1

T

CT1TiT2 ... CT2CTi...



21/60

Modèles de transactions avancés (les + et les -)• Les +

de flexibilité• Les -

pas grand chose d’opérationnel (pas pratique ?) flots de contrôle insuffisants (pour de la coordination

en général) Les transactions ACID restent à la base … on y revient

plus loin !!!


Gestion de workflow



23/60

Workflow (la référence)

• Le concept de « workflow » permet de définir la logique des procédés indépendamment de leur mise en œuvre dans les programmes

• Dans le même esprit que le concept de « base de données » met en œuvre l’indépendance entre les programmes et des données

• WfMC (Workflow Management Coalition)http://www.wfmc.org



24/60

Workflow concepts

Control flowconnector

Conditiontransition

Activity

Datacontainer

Out

OutIn

In



25/60

Hypothèse

• Les activités s’exécutent comme des transactions• (sinon la cohérence est à la charge des

programmeurs d’application et on n’a plus de garantie implicite donnée par le modèle)



26/60

Workflow (les + et les -)

• Les + Indépendance logique des procédés/programmes Contrôle de l’utilisateur, équilibrage de charge … Flots de contrôle et flots de données Systèmes opérationnels

• Les - Structures de contrôle de flot de contrôle et de flot de

données trop rigides pour les applications les plus créatives


SynthèseModèles de Transactions Avancés/

Workflow classique



29/60

Les MTA comme des workflows ?

T1Activité 1

T2Activité 2

T3Activité 3

CT3Activité 4

CT2Activité 5

CT1Activité 6

RC_1 = 0 RC_2 = 0

RC_4 = 0 RC_5 = 0

RC_FB <> 0

State_1 State_2 State_3

Bloc de travail

Bloc de compensation

NOPState_1 <> 0State_3 <> 0 State_2 <> 0

[Alonso1996]



30/60

Le Workflow est-il l’aboutissement du transactionnel ?• Dans les applications « traditionnelles », peut-être,

mais cela reste à prouver …• Dans les applications créatives certainement pas :

Si on suppose que l’on peut connaître les briques ACID :

• Trop complexe, ne passe pas à l’échelle [Godart1999]

Et dans les applications les plus créatives, on ne connaît pas les briques ACID (développement incertain)


31/60

T2

T1

Patron « Client/Serveur »

read(m1)

Modify(m)

m1

Intermediate

read(mf)

mf

write(mf)

Final value

r

Ecrire(r)

Compensation

read(mn)

write(m1)

mn

write(mn)

m2

write(m2)

Write(r1)

r1



32/60

Quel modèle pour décrire les procédés coopératif ?• Dépasser la vision des activités comme des

transactions ACID Modèle de transaction ouvertes, interactives, ou

d’activité• Dépasser la rigidité des opérateurs de la WfMC

Modèle de workflow avancé, ou de procédé



33/60

Modèles de procédé(workflow avancé)• Le modèle comme une ressource pour l’action, pas

comme une contrainte d’exécution pas satisfaisant, peu de contrôle [Agostini96]

• Le modèle est classique, contraint l’exécution, mais peut évoluer dynamiquement en cours d’exécution (ajout, suppression, décalage … d’une activité, modification des flots de contrôle …) des bases théoriques plus saines, mais peu pratique [Casati 96,

Reichert98, Weske96]



34/60

Modèles de procédés

• Le modèle est étendu pour permettre une modélisation plus souple et intégrer les comportements coopératifs : Collaborative Management Infrastructure [Schuster2000a]

• group activities, optional activity, inhibor primitive, window of opportunity, synchrony primitives

Coo_operator [Godart1999]

• Le modèle est classique, mais son interprétation est différente COO-flow [Grigori01]



35/60

UN exemple : COO-Flow

• Flexibilité du flot de contrôle Anticipation sur flot de contrôle (anticipation libre,

dictée par le flot de contrôle, dictée par le flot de données)

• Flexibilité du flot de donnée : Les activités comme des COO-transactions Anticipation sur flot de données



36/60

COO-transactions

• Synthèse « Copy/Modify/Merge » et Transaction • Echange contrôlé de résultats intermédiaires

(client/serveur, rédacteur/relecteur, écriture coopératives)

• COO-sérialisabilité et COO-protocole• Une transaction ACID est une COO-transaction

qui ne rend pas visible de résultats intermédiaires



37/60

Y a-t-il besoin d’un nouveau modèle de description ?

B

C

A B C ...

Même modèle de description,

CB

A

Interprétationcompétitive

Interprétationcoopérative

Mais une interprétation différente

A



38/60

Anticipation

AE

D

B C

• Flexibilité du flot de contrôle :- Workflow traditionnel : une activité ne peut pas démarrerson exécution si la précédente n’a pas terminé la sienne- Workflow coopératif : une activité peut anticiper sonexécution même si toutes les conditions ne sont pas remplies



39/60

Les activités comme desCOO-transactions

• Flexibilité du flot de données :- Workflow traditionnel : seulement les activités connectées directement par le flot de contrôle échangent des données(ou alors sans garantie)- Workflow coopératif : anticipation dictée par les données,Les activités s’exécutent comme des COO-transactions

AE

D

B C



40/60

Procédés (Perspectives)

• Encore plus de flexibilité, plus d’extensibilité• Intégration de la dimension « workflow » aux

autres dimensions de la coopération Process awareness, context aware process management

…• Dans une application complexe, il n’existe pas un,

mais des procédés, qui peuvent être de nature différente et qui interagissent entre eux (multi-procédés)



41/60

Multi-procédés

• Modèle générique de description des multi-procédés

• Découverte des multi-procédés (analyse des traces d’exécution, analyse des conflits d’accès aux ressource)

• Multi-procédés transactionnels



42/60

Multi-procédés (Modèle générique)

• Collaborative Management Infrastructure [Schuster2000a] fournit des primitives de synchronisation multi-procédés qui définissent: Quoi synchroniser : quelles transitions d’état de quels procédés Quand synchroniser : quelles sont les conditions de

synchronisation ? Comment synchroniser : quel type de supervision ? Que faire quand une synchronisation échoue : comment compenser

• Procédés cross-organisationnel [Schuster2000b]



43/60

• Les interactions entre les procédés impliquent des interactions « cachées » entre activités qui peuvent échouer (compensables ou pas) et des activités « pivot » (non compensables)

• [Schuldt02] propose une nouvelle théorie pour la synchronisation de procédés transactionnels multi-synchrones … mais toujours fondée sur l’atomicité et de l’isolation, qu’en est-il des procédés créatifs ?

Transactional Multi-processes



45/60

Découverte de procédés

• Analyse de traces d’exécution• Analyse des conflits (accès aux ressources

partagées)• …


Editeurs synchrones



47/60

Problématique

• Modification simultanée des copies• Exigence :

Haute réactivité : effet des opérations visibles le plus rapidement possible (travail synchrone)

• Assurer la cohérence des copies [Vidot2000]



48/60

Approche

• Objets répliqués sur chaque site…• Les opérations exécutées sur un site sont diffusées

sur les autres sites…• Construire une histoire équivalente sur chaque

copie locale



49/60

Usager 1 Usager 2pas pas

op1=insérer(3,'i') op2=insérer(3,'r')

pais pars

insérer(3,'r') insérer(3,'i')

pairsparis

Problématique•Problématique•Gestion de versions•Gestion de transactions•Gestion de workflow•Editeurs synchrones•Conclusion


50/60

Approche

• Opération sur objets typés String: InsertCar, DeleteCar Calendar: InsertEvent, DeleteEvent XML: AddNode, DeleteNode, ChangeAttr

• Transformer les opérations (transformées opérationnelles) pour obtenir des histoires équivalentes correctes : qui vérifient Causalité Préservation de l’intention. Conditions de convergence



51/60

Transposée en avant qui ne respecte pas la condition 1• Transpose_av(insérer(p1,c1), insérer(p2,c2))=cas p1 ? p2 dep1 < p2 alors insérer(p2+1,c2)p1 > p2 alors insérer(p2, c2)p1 = p2 alors insérer si c1 = c2 alors Id

sinon insérer(p2,c2)




pais parsT(op2,op1)=insérer(3,'r') T(op1,op2)=

insérer(3,'i')

pairsparisNe vérifie pas la

Condition 1:Oi.op1.T(op2,op1) = Oi.op2.T(op1,op2)


52/60

Transposée en avant qui respecte la condition 1• Transpose_av(insérer(p1,c1), insérer(p2,c2))=cas p1 ? p2 dep1 < p2 alors insérer(p2+1,c2)p2 > p1 alors insérer(p2,c2)p1 = p2 alors insérer si c1 = c2 alors Id

sinon si code(c2) > code(c1)alors insérer(p2,c2)sinon insérer(p2+1,c2)




pais pars

T(op2,op1)=insérer(3,'r') T(op1,op2)=

insérer(4,'i')

parisparisVérifie la

Condition 1:Oi.op1.T(op2,op1) = Oi.op2.T(op1,op2)


53/60

• Les + Bien fondé

• Les - Transformées opérationnelles trop primaires (choix

arbitraire) pour les applications créatives Difficulté d’écrire les transformées opérationnelles

pour respecter les propriétés de convergence• Conditions 1 et Condition 2 (Condition1 appliquée à une

séquence d’opérations)

Editeurs synchrones



54/60

Editeurs synchrones (perspectives)• Gestion interactive des conflits plutôt que prise de

décision automatique• Relation synchrone/asynchrone

• 2 personnes en synchrone et une 3ème déconnectée Éditeur SAMS (Synchrone/Asynchrone/Multi-synchrone) (

http://woinville.loria.fr/simu/) [Jourdain2002]

• …


http://woinville.loria.fr/simu/










55/60

Autres dimensions ?

• Fouille de données (Découverte de procédés, Context-based awareness …)

• Visualisation de grandes quantités d’information (TreeMap, Arbre hyperbolique…)

• Mobilité

• Mais y a-t-il une problématique propre au CSCW ?



56/60

Conclusion

• Un problème difficile et encore très ouvert Plus de flexibilité Plus d’interactivité

• Plus d’intégration : Formel/informel Synchrone/asynchrone Haute interactivité


Questions ?


58/60

Références (1)

• [Agostin1996] Agostini, A. and G. De Michelis, Modeling the Document Flow within a Cooperative Process as a Resource for Action, . 1996, University of Milano.

• [Alonso1996] Gustavo, A, Divyakant, A, Al Abbadi, A, Mohan, K, Günthör, R, Mohan, C. Advanced Transaction Models in Workflow Contexts. ICDE 1996

• [Bouazza2000] Bouazza, A, and Molli, P. Unifying coupled and uncoupled collaborative work in virtual teams. In ACM CSCW'2000 workshop on collaborative editing systems. (Philadelphia, Pennsylvania, USA). 2000.

• [Canals1998] Canals, G, and Godart, C, and Molli, P, and Munier, M. A Criterion to Enforce Correctness of Indirectly Cooperating Applications. Information Sciences. Elsevier, 1998. vol 110. pp.279-302.

• [Casati1996] Casati, F., et al. Workflow Evolution. in 15th Int. Conf. On Conceptual Modeling (ER'96). 1996.


59/60

Références (2)

• [Godart1999] Godart, C, Perrin, O, and Skaf, H. COO: a Workflow Operator to Improve Cooperation Modeling in Virtual Processes. International Workshop on Research Issues on Data Engineering. Information Technology for Virtual Enterprises, RIDE-VE'99, Sydney, Australia. 1999

• [Grigori2001] Grigori, D, and Charoy, F, and Godart, C. Flexible Data Management and Execution to Support Cooperative Workflow: the COO approach. In CODAS. 2001.Beijing

• [Jajodia1997] Jajodia, S, Kerschberg, L, Advanced Transaction Models and ArchitecturesKluwer Academic Publishers, ISBN 0-7923-9737-1

• [Jourdain2002] Jourdain, S, Molli, P, Oster, G. SAMS : Synchronous, Asynchronous, Multi-synchronous Environment, CSCWD, Rio DeJaneiro, 2002

• [Molli2002] Molli, P, and Skaf-Molli, H, and Oster, G. Divergence Awareness for Virtual Team through the Web. In IDPT'2002. (Pasadena, CA, USA). 2002.

• [Reichert1998] Reichert, M. and P. Dadam, ADEPTflex - Supporting dynamic Changes of Workflows Without Losing Control. Journal of Intelligent Information Systems, 1998. 10.


60/60

Références (3)

• [Schuldt2002] Schuldt, H, Alonso, G, Beeri, C, and Scheck, HS. Atomicity and isolation for transactional processes. ACM TODS, 27 (1), 2002

• [Schuster2000a] Schuster, H, Baker, D, Cichocki, A, Georgakopoulos, D, and Rusinkiewicz, M. The Collaboration Management Infrastructure. ICDE 2000

• [Schuster2000b] Schuster, H, Georgakopoulos, D, Cichocki, A, and Baker, D. Modeling and Composing Service-Based nd Reference Process-Based Multi-enterprise Processes. CAiSE 2000: 247-263

• [Tata2001] Tata, S, et Canals, G, et Godart, C. Un modèle d'interaction pour les équipes virtuelles coopérantes. Réseaux et systèmes répartis - calculateurs parallèles . 2001. vol 13. n° 2-3. pp.267-294

• [Vidot2000] Vidot, N, Cart, M, Ferrié, J, and Suleiman, M. Copies convergence in a distributed real-time collaborative environment. CSCW 2000: 171-180

• [Weske2003] Weske, M. Flexible Modeling and Execution of Workflow Activities. in 31st Hawaii International Conference on System Sciences, Software Technology Track (Vol VII). 1996

Les outils du travail coopératif La cohérence des données coopératives

Documents

Transcript of Les outils du travail coopératif La cohérence des données coopératives