Fondements scientifiques

Transactions coopératives

Résumé : 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.

Les problèmes

L'extension du concept de transaction au domaine choisi pose plusieurs problèmes nouveaux liés à la nature des applications considérées :

La nature coopérative remet en cause le principe d'isolation généralement utilisée pour assurer l'atomicité à la concurrence (les états intermédiaires d'une transaction ne sont pas visibles par d'autres transactions). En effet, et presque en opposition, nous définissons la coopération comme la volonté de s'échanger des résultats intermédiaires. Elle ébranle aussi la notion de consistance individuelle des transactions, puisque nous définissons un résultat intermédiaire comme un résultat potentiellement incohérent. De plus, les tâches peuvent coopérer pour valider une contrainte. Enfin, le programme d'une transaction peut être (re)défini dynamiquement.
La longue durée des tâches remet en cause la technique du tout ou rien utilisée pour assurer l'atomicité aux défaillances. Il n'est pas acceptable de perdre tout le travail réalisé pendant plusieurs minutes, heures, voir plusieurs jours pour des raisons liées au contrôle des interactions avec d'autres.

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.

ECOO et les transactions coopératives

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 (cf. ) / consistance individuelle (cf. ) 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 : définition de primitives de gestion de transactions dans un langage objets persistants ...Nous pensons en effet que beaucoup est à faire dans le domaine.

Analyse des usages

Résumé : Une analyse structurée des usages courants est intéressante pour les raisons suivantes : - les applications coopératives sont fortement interactives et cette analyse est un garant d'acceptation des logiciels développés, - si l'usage des nouvelles technologies est à inventer, les nouveaux usages sont souvent le fruit d'une hybridation d'usages existants.

Généralités

Du fait de la variété des applications coopératives, il est actuellement illusoire de vouloir développer une plate-forme universelle. Des choix de domaines d'application et architecturaux sont inévitables et il est nécessaire de situer ces choix par rapport aux pratiques effectives de coopération.

D'autre part, plus qu'une nécessité technique, il s'agit d'un choix stratégique afin, d'une part espérer une meilleure acceptation des services dévelloppés, mais aussi de susciter de nouveaux usages : si l'usage des nouvelles technologies est à inventer, les nouveaux usages sont souvent le fruit d'une hybridation d'usages existants [Tel97].

ECOO et les usages

La recherche sur les usages relève plus du domaine des sciences sociales que de celui des sciences informatiques. Notre objectif est de nous entourer de collaborateurs nous permettant de mieux connaitre les usages courants de façon à les intégrer très tôt dans nos réflexions, en particulier en ce qui concerne l'action aide à la prise de décisions collectives (cf. ). Nous comptons en particulier ici sur nos implications industrielles (cf. ).

Analyse globale et évaluation partielle

La compilation globale ou plus généralement, l'analyse globale d'un logiciel, est une technique qui prend à contre-pied la technique classique de compilation séparée. Comme son nom l'indique, le principe d'analyse globale consiste à considerer l'ensemble du système afin de valider, traduire, ou encore optimiser.

Considérons par exemple que la fonction doive être vérifiée pour ensuite donner lieu à une traduction en langage machine. En compilation séparée, la seule information dont on dispose est la définition de la fonction elle-même: aucune supposition ne peut être faite en ce qui concerne le contexte d'appel de la fonction . Inversement, l'analyse globale permet de recenser tous les sites d'appel de la fonction . Ce faisant, certains sites d'appels peuvent donner lieu à une évaluation partielle: par exemple lorsque la fonction prend un argument entier et qu'un site d'appel correspond à . Bien entendu, pour un site d'appel avec quelconque, aucune évaluation partielle n'est possible.

Dans le cadre des langages à objets, le type dynamique du receveur est une information essentielle en terme de vérification comme en terme d'optimisation.

Précédent : Présentation générale et objectifs Remonter : ACTION ECOO, Environnements pour la Suivant : Grands domaines d'application