Précédent : Fondements scientifiques Remonter : Fondements scientifiques Suivant : Modèles de coordination de tâches
Précédent : Fondements scientifiques Remonter :
Fondements scientifiques Suivant :
Modèles de coordination de tâches
L'objectif des transactions est de simplifier la programmation des applications en cachant au maximum la complexité du parallélisme d'exécution des tâches. Cela est encore plus vrai lorsque les interactions se multiplient comme c'est le cas dans les applications coopératives et le choix de l'approche semble donc judicieux. Mais la coopération induit de nouveaux problèmes, en particulier dûs à la rupture du principe d'isolation à la base de la plupart des modèles de transactions traditionnels.
Pour organiser nos réflexions, nous considérons qu'une application coopérative est un ensemble de tâches qui inter-agissent par échange d'informations au travers d'espaces de travail communs et nous ramenons le problème de la correction de leurs exécutions entremêlées à la synchronisation de leurs accès aux informations partagées. Le problème ainsi posé met en évidence les relations avec le domaine du contrôle de la concurrence d'accès et de la gestion de transactions. Aussi, nous avons choisi de résoudre le problème de la correction des applications coopératives en nous appuyant sur le concept de transaction.
L'extension du concept de transaction au domaine choisi pose plusieurs problèmes nouveaux liés à la nature des applications considérées :
D'autre part, une transaction coopérative est généralement une transaction distribuée et les modèles mis en oeuvre utilisent des algorithmes du type atomic commit, consensus ... eux mêmes compliqués, en particulier sur des réseaux peu fiables.
On peut bien sûr s'interroger sur le fait de fonder la correction des applications coopératives sur le concept de transaction alors que la nature même de la coopération remet en cause bon nombre des fondements des modèles de transactions mis en oeuvre dans les applications traditionnelles. A l'opposé, nous pensons que le principe à la base des modèles transactionnels (simplifier la programmation des applications en cachant au maximum la complexité du parallélisme d'exécution des tâches) est encore plus efficace lorsque les interactions se multiplient. C'est en particulier le cas dans le cadre d'une entreprise-projet sur Internet qui peut rapprocher des partenaires possédant une faible infrastructure informatique.
On retrouve donc dans notre approche la dualité atomicité à la concurrence / cohérence individuelle des modèles de transaction.
Comme introduit ci-dessus, on s'intéresse principalement au problème dans deux directions. Une direction algorithmique, avec la définition d'un (de) critère(s) de correction (la COO-sérialisabilité en est un exemple) et d'un (de) protocole(s) validant ce critère (par exemple le protocole COO pour la COO-sérialisabilité). Une direction système avec une mise en oeuvre réaliste de ce protocole (si de nombreux critères existent, en particulier pour relâcher la sérialisabilité, extrêmement peu sont mis en oeuvre pour des raisons de complexité). Finalement, nous démarrons une réflexion dans la direction langage en relation avec 5.1 : définition de primitives de gestion de transactions dans un langage à objets persistants ...Nous pensons en effet que beaucoup est à faire dans le domaine.