Brevet FR2834095A1 — publié le 20030627

Procédé de gestion d'une session collaborative synchrone mise en oeuvre au sein d'une architecture distribuée et supervisée. Le domaine de l'invention est celui du travail collaboratif assisté par ordinateur (TCAO), ou CSCW (pour Computer Supported Cooperative Work en anglais). D'après la définition communément retenue et donnée par Clarence Ellis, les applications relevant du CSCW, communément dénommées applications collaboratives, sont des applications par lesquelles plusieurs utilisateurs interagissent simultanément (travail synchrone) et/ou en différé (travail asynchrone), dans un même lieu, ou depuis des lieux différents . Dans le cadre de la présente invention, on s'intéresse à l'accroissement de la sûreté de fonctionnement dans les applications collaboratives synchrones. On rappelle que ces dernières permettent aux utilisateurs distants de travailler ensemble, de manière simultanée et avec un fort couplage ou niveau d'interactivité, sur des documents multimédia (texte, vidéo, son, etc. ) au moyen de terminaux (ordinateurs, assistants personnels digitaux ( PDA ), ordinateurs de poche ( pocket PC ), téléphones mobiles, consoles de jeu, etc.). Dans la suite de la description, on utilise parfois le raccourci terminologique suivant : on entend par architecture collaborative synchrone une architecture distribuée dédiée au support d'applications collaboratives synchrones , c'est-à-dire permettant de distribuer des applications sur différents sites et autorisant des utilisateurs distants à travailler ensemble et simultanément sur des données multimédias. On connaît trois grandes catégories d'architectures distribuées, pouvant servir de support aux applications collaboratives synchrones. La première, ou architecture totalement distribuée, est caractérisée par une interconnexion directe (mode point-àpoint ) entre les applications distantes impliquées dans la collaboration. La seconde, ou architecture supervisée, se distingue par l'utilisation d'une application, dite superviseur , sur laquelle sont interconnectées toutes les applications clientes impliquées dans la collaboration et dont le rôle consiste à gérer les communications et la cohérence d'état entre les applications distantes. La troisième, ou architecture hybride, est une combinaison des deux précédentes. Plus précisément, l'invention concerne un procédé de gestion d'une session collaborative synchrone mise en oeuvre au sein d'une architecture distribuée et supervisée (seconde catégorie précitée). On suppose en outre, dans le cadre de la présente invention, que chacun des terminaux impliqués dans la collaboration exécute une même application cliente. Cette approche s'oppose à d'autres architectures distribuées pour lesquelles une seule application (dite maître ) est réellement exécutée, les autres applications clientes (dites esclaves ) affichant aux utilisateurs une vue miroir (image) de l'application réellement exécutée. Par exemple, le partage d'applications dans Microsoft Netmeeting (marque déposée) s'appuie sur ce dernier type de fonctionnement, et plus précisément sur le principe du bitmap différentiel . Cependant, celui-ci permet difficilement de travailler efficacement à distance sur des données multimédias (de type vidéo, par exemple), en particulier sur des réseaux à qualité de service variable. La présente invention peut être utilisée dans n'importe quel type d'application collaborative synchrone, et notamment, mais non exclusivement, en télémédecine, téléenseignement, pour du travail collaboratif, de la téléexpertise, du jeu en réseaux, ou encore dans un contexte de télévision numérique interactive, etc. Plus généralement, elle peut s'appliquer dans tout domaine mettant en jeu un moyen informatisé (terminal) autorisant un travail ou une activité synchrone entre personnes distantes. En outre, l'arrivée prochaine de la nouvelle norme de téléphonie mobile UMTS (Universal Mobile Télécommunications Systems), ainsi que les nouvelles technologies émergentes destinées à favoriser l'interopérabilité entre les services de téléphonie mobile et les services multimédia type IP, laissent présager de la naissance de nouveaux services destinés au support d'activités collaboratives synchrones et embarqués sur des systèmes miniaturisés de nouvelle génération. De tels services seront également confrontés au problème de la sûreté de fonctionnement (lié notamment à la concurrence d'actions). En effet, ils devront s'appuyer sur des architectures distribuées (parfois centralisées), mais aussi sur des réseaux mobiles à qualité de service variable (couverture réseau, déplacement des appareils). Un parcours relativement exhaustif de la littérature associée au domaine du travail collaboratif assisté par ordinateur (TCAO) met en exergue le fait que très peu de travaux s'intéressent à la problématique de la sûreté de fonctionnement dans les architectures collaboratives synchrones utilisant des réseaux de communication à qualité de service variable et non garantie pour les communications inter-processus. Or, il existe un besoin de garantir le maintien de la cohérence d'état entre les applications distantes, même en présence de conflits d'actions (concurrence entre processus devant accéder à des ressources communes) qui peuvent survenir lorsque plusieurs utilisateurs agissent de manière antagoniste sur leurs interfaces logicielles. Le traitement de ce problème est particulièrement sensible lorsque les architectures doivent autoriser un maximum d'interactivité entre les utilisateurs distants et leur utilisation la plus naturelle possible de l'application supportée. On rappelle en effet, concernant la cohérence d'état dans les applications collaboratives synchrones, que ces dernières reposent généralement sur des architectures distribuées, dont le rôle principal est : de permettre aux processus distants impliqués dans la collaboration de pouvoir communiquer entre eux ; d'assurer le maintien de la cohérence d'état entre les applications clientes, pour qu'elles respectent la contrainte ce que tu vois est ce que je vois (ou WYSIWIS , pour What You See Is What 1 See en anglais) imposée par le niveau d'interactivité élevé requis par les utilisateurs. Or, cette dernière contrainte ne sera respectée que si l'application collaborative est capable d'offrir à tout moment aux utilisateurs une vue cohérente de l'état des informations manipulées et partagées, et de l'ensemble des actions effectuées par les individus au travers de leur application cliente. Ainsi, toute action effectuée par un collaborateur au travers de son application devra être immédiatement reproduite de la même manière, au travers des autres applications (travail synchrone). On rappelle maintenant brièvement le lien entre cohérence d'état et gestion de la concurrence. Dans les systèmes informatiques distribués dédiés au support d'activités collaboratives, des processus distants peuvent avoir besoin d'accéder au même moment à des ressources partagées. Sous certaines conditions, ceci peut induire une situation de concurrence qui peut paralyser le système. Ce type de problème correspond à des situations d'interblocage (ou deadlocks en anglais). L'interblocage est bien connu par les concepteurs de systèmes distribués. Le problème de la concurrence d'actions peut survenir dans une application collaborative synchrone lorsque des actions utilisateur sont effectuées dans un intervalle de temps très court, conduisant ainsi, selon le mode de communication choisi (messages synchrones versus asynchrones), vers un blocage ou un interblocage, suivi d'une perte de la cohérence d'état entre les applications distantes. La littérature associée au travail collaboratif assisté par ordinateur (CSCW) montre que la grande majorité des applications développées s'appuient sur un mode de collaboration de type maître/esc1ave . Afin de garantir le maintien de la cohérence d'état entre les applications distantes, ce mode de collaboration est basé sur des mécanismes de type verrouillage. Ces mécanismes peuvent être à niveau de granularité différents : objets manipulés, individus eux-mêmes, en fonction des rôles qui leur ont été affectés. Leur inconvénient majeur est qu'ils constituent une entrave à l'interactivité entre les utilisateurs et à l'utilisation naturelle du système. Dans la plupart des systèmes existants basés sur une collaboration de type maître/esc1ave , la gestion des mécanismes de verrouillage est réalisée, soit par un individu ayant la charge de l'animation et de la coordination de l'activité collaborative distribuée, soit directement au niveau applicatif. Dans le premier cas, le coordinateur de la session collaborative délivre des droits différents aux participants à la session collaborative (prendre la parole, effectuer des actions, etc. ) qui peuvent alors intervenir ou simplement assister à la session collaborative. Les droits délivrés sont souvent associés à différents degrés de verrouillage dans les applications logicielles clientes. Cette première technique connue de gestion des mécanismes de verrouillage constitue une entrave à l'interactivité entre les utilisateurs et à l'utilisation naturelle de l'application collaborative. En effet, les droits des participants à la session collaborative sont figés, et l'intervention du coordinateur de la session ralentit le processus. Dans le second cas, les mécanismes de verrouillage sont directement déportés au niveau de l'interface utilisateur de chacune des applications clientes impliquées dans la session collaborative. Par exemple, pour effectuer une ou plusieurs actions, un individu devra préalablement cliquer sur un bouton prendre la main , ce qui aura pour conséquence le verrouillage de toutes les autres applications clientes distantes. Dans la majorité des cas, lorsqu'un utilisateur a pris la main sur le système, les autres utilisateurs doivent alors attendre la libération du système pour pouvoir à leur tour effectuer des actions. Cette seconde technique connue de gestion des mécanismes de verrouillage pose également un certain nombre de problèmes : entrave à l'interactivité entre les utilisateurs et à l'utilisation naturelle de l'application collaborative ; libération de la main au bon vouloir des utilisateurs ; problème de la concurrence d'actions non résolu, celui-ci pouvant toujours survenir si deux utilisateurs souhaitent prendre le contrôle du système simultanément. D'une façon générale, le problème de la concurrence d'actions peut affecter le maintien de la cohérence d'état et favoriser l'occurrence de situations de blocage et d'interblocage dans les architectures collaboratives synchrones supervisées. Son occurrence conduit dans la majorité des cas à l'arrêt global d'une session collaborative en cours. L'invention a notamment pour objectif de pallier ces différents inconvénients de l'état de la technique. Plus précisément, l'un des objectifs de la présente invention est de fournir un procédé de gestion d'une session collaborative synchrone mise en oeuvre au sein d'une architecture distribuée et supervisée, ledit procédé permettant d'assurer qu'aucune situation de blocage ou d'interblocage ne puisse survenir en cours de session collaborative à cause des conflits d'actions. En d'autres termes, la cohérence d'état doit toujours être maintenue entre les applications clientes, et la continuité de la session collaborative doit être assurée, même en présence de concurrence d'actions. L'invention a également pour objectif de fournir un tel procédé permettant de rendre la gestion de la concurrence d'actions totalement automatique et transparente pour les utilisateurs. Un autre objectif de l'invention est de fournir un tel procédé qui n'entrave pas le niveau d'interactivité entre les utilisateurs. Un objectif complémentaire de l'invention est de fournir un tel procédé favorisant l'utilisation naturelle de l'application collaborative. Encore un autre objectif de l'invention est de fournir un tel procédé qui permette à tous les participants à la session collaborative d'intervenir et agir sur leur interface logicielle, sans aucune restriction particulière ou gestion de rôle. Un objectif complémentaire de l'invention est de fournir un tel procédé qui soit indépendant du réseau de communication (reliant l'application superviseur et les applications clientes), du type de terminal, du système d'exploitation exécuté sur ce terminal, etc. Ces différents objectifs, ainsi que d'autres qui apparaîtront par la suite, sont atteints selon l'invention à l'aide d'un procédé de gestion d'une session collaborative synchrone mise en oeuvre au sein d'une architecture distribuée et supervisée, dans laquelle chacun des terminaux impliqués dans la session collaborative exécute une application cliente. Selon l'invention, ledit procédé met en oeuvre un mécanisme d'inhibition comprenant les étapes suivantes, lors de l'occurrence d'une action utilisateur sur une application cliente Ck : on établit de façon automatique une communication entre l'application cliente Ck et une application superviseur, de façon que l'application cliente Ck effectue un test de la disponibilité de l'application superviseur ; si l'application superviseur est disponible, alors l'application cliente Ck rend effective ladite action utilisateur et l'application superviseur met à jour l'ensemble des autres applications clientes en fonction de ladite action utilisateur ; si l'application superviseur est indisponible, ladite action utilisateur est inhibée et n'est pas rendue effective par l'application cliente Ck ; de façon à garantir le maintien de la cohérence d'état entre les applications clientes, même en cas de concurrence d'actions utilisateurs. Le principe général de l'invention consiste donc, de façon totalement automatique et transparente pour les utilisateurs, à rendre une action non effective (inhibée) si l'application superviseur est déjà occupée à traiter une autre action. Ainsi, la cohérence d'état est toujours maintenue et la continuité de la session collaborative assurée, même en présence de conflits d'actions. L'invention repose sur l'hypothèse suivante : il existe toujours un décalage temporel ôt, même très petit, entre deux messages arrivant au niveau d'une même application (cliente ou superviseur). En d'autres termes, la probabilité de voir deux messages (codant des actions concurrentes) arriver exactement au même instant, soit au niveau des applications clientes Ci, soit au niveau de l'application superviseur, est considérée comme nulle. La présente invention possède de nombreux autres avantages, et notamment : le processus d'inhibition est automatique et très court (quelques centaines de millisecondes au maximum, correspondant au temps de mise à jour de l'ensemble des applications clientes distribuées, suite à une action utilisateur rendue effective) et n'entrave donc en aucun cas le niveau d'interactivité entre les utilisateurs ; l'utilisation naturelle de l'application collaborative est favorisée : il n'est plus nécessaire de délivrer aux utilisateurs des fonctionnalités leur permettant de prendre la main sur le système en verrouillant les autres applications ; les participants à la session collaborative peuvent tous intervenir et agir sur leur interface logicielle, sans aucune restriction particulière ou gestion de rôle. Ils peuvent désormais se concentrer sur la réalisation de leur activité conjointe et distante. Par ailleurs, le procédé selon l'invention est indépendant du réseau de communication, du type de terminal, du système d'exploitation exécuté sur ce terminal, etc. Son fonctionnement est générique. Il peut être utilisé dans n'importe quel type d'application collaborative synchrone. Préférentiellement, ladite architecture distribuée et supervisée, comprenant l'application superviseur et les applications clientes, est basée sur un modèle de Petri enrichi résultant de la mise en oeuvre des étapes suivantes : élaboration d'un modèle de ladite architecture distribuée et supervisée, dit modèle de Petri, au moyen d'un réseau de Petri ; analyse formelle du comportement du modèle de Petri, en des situations de concurrence d'actions utilisateurs, de façon à définir des paramètres de mise en oeuvre dudit mécanisme d'inhibition ; enrichissement du modèle de Petri avec ledit mécanisme d'inhibition, de façon à obtenir un modèle de Petri enrichi permettant de détecter, prendre en compte et contrôler des situations de concurrence d'actions utilisateurs. De cette façon, on peut s'assurer et formellement prouver, par l'analyse mathématique du modèle de Petri, qu'aucune situation de blocage ou d'interblocage ne peut plus survenir en cours de session collaborative à cause des conflits d'actions. De façon préférentielle, ladite architecture distribuée et supervisée, comprenant l'application superviseur et les applications clientes, possède une structure en deux couches : une couche d'application logicielle, sur laquelle les utilisateurs des applications clientes et de l'application superviseur agissent ; une couche de réseau de Petri, basée sur ledit modèle de Petri enrichi, et permettant, de manière automatique et transparente pour les utilisateurs des applications clientes, de détecter, prendre en compte et contrôler des situations de concurrence d'actions utilisateurs ; et la couche de réseau de Petri contrôle la couche d'application logicielle. De façon avantageuse, les processus ("méthodes logicielles") associés à la couche d'application logicielle sont également associés aux transitions de la couche de réseau de Petri. En outre, chacun des processus associés à la couche d'application logicielle ne peut s'exécuter que si le marquage de la couche de réseau de Petri sensibilise la transition correspondante, cette exécution conduisant à l'évolution de la couche d'application logicielle et à l'évolution du marquage de la couche de réseau de Petri. Ce principe de contrôle de la couche d'application logicielle par la couche de réseau de Petri est générique. Avantageusement, la couche de réseau de Petri est déportée dans un réseau d'objets permettant de masquer et déléguer des contrôles présents dans le code de la couche d'application logicielle. De cette façon, on facilite la tâche d'un informaticien, peu familier des réseaux de Petri, désireux de mettre en oeuvre la présente invention. Selon une caractéristique avantageuse, le modèle de Petri enrichi possède une forme généralisée comprenant une première partie propre à l'application superviseur et plusieurs secondes parties propres chacune à l'une des applications clientes, et ledit mécanisme d'inhibition est introduit dans la première partie du modèle de Petri enrichi, propre à l'application superviseur. De façon préférentielle, le modèle de Petri enrichi est implémenté dans un langage orienté-objet, avec au moins les deux classes d'objet suivantes : une classe d'objet"place"et une classe d'objet"transition". Avantageusement, le modèle de Petri enrichi possède une forme généralisée comprenant une première partie propre à l'application superviseur et plusieurs secondes parties propres chacune à l'une des applications clientes. En outre, la première partie du modèle de Petri enrichi, propre à l'application superviseur, comprend au moins un vecteur de places et/ou au moins un vecteur de transitions, qui sont reliés à au moins certaines places et/ou transitions correspondantes des secondes parties du modèle de Petri enrichi, propres aux applications clientes. A partir de cette forme généralisée du réseau de Petri, l'implémentation du modèle de Petri enrichi (préférentiellement dans la couche de réseau de Petri), dans n'importe quel langage orienté-objes, est facilitée. En effet, dans les langages orientés objets, il existe des classes prédéfinies qui permettent de gérer dynamiquement des listes ou vecteurs d'objets (insertion d'un objet à une place particulière, retrait d'un objet, ..., avec une gestion automatique des indices et de la mémoire). Selon une caractéristique avantageuse, l'interconnexion d'une nouvelle application cliente avec l'application superviseur comprend au moins une des étapes suivantes : insertion de nouvelles places dans lesdits vecteurs de places ; insertion de nouvelles transitions dans lesdits vecteurs de transitions. L'invention concerne également un programme d'ordinateur comprenant des séquences d'instructions adaptées à la mise en oeuvre du procédé précité, lorsque ledit programme est exécuté sur un ordinateur. L'invention concerne aussi un produit programme d'ordinateur de gestion d'une session collaborative synchrone mise en oeuvre au sein d'une architecture distribuée et supervisée, dans laquelle chacun des terminaux impliqués dans la session collaborative exécute une application cliente. Ledit produit programme d'ordinateur comprend des instructions de code de programme enregistré sur un support utilisable dans un ordinateur comprenant des moyens de programmation lisibles par ordinateur pour effectuer, lors de l'occurrence d'une action utilisateur sur une application c1iente Ck, un mécanisme d'inhibition comprenant les étapes suivantes : on établit de façon automatique une communication entre l'application cliente ci et une application superviseur, de façon que l'application c1iente Ck effectue un test de la disponibilité de l'application superviseur ; si l'application superviseur est disponible, alors l'application cliente Ck rend effective ladite action utilisateur et l'application superviseur met à jour l'ensemble des autres applications clientes en fonction de ladite action utilisateur ; si l'application superviseur est indisponible, ladite action utilisateur est inhibée et n'est pas rendue effective par l'application cliente Ck ; de façon à garantir le maintien de la cohérence d'état entre les applications clientes, même en cas de concurrence d'actions utilisateurs. D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description suivante d'un mode de réalisation préférentiel de l'invention, donné à titre d'exemple indicatif et non limitatif, et des dessins annexés, dans lesquels : - la figure 1 présente un exemple d'une architecture distribuée et supervisée au sein de laquelle peut être mise en oeuvre une session collaborative synchrone gérée selon le procédé de l'invention ; - la figure 2 présente une architecture distribuée et supervisée, présentant une structure en deux couches selon l'invention ; - la figure 3 présente un exemple de modèle de Petri enrichi selon l'invention, généralisé à N applications clientes et gérant la concurrence d'actions ; la figure 4 présente l'arbre de couverture construit pour le réseau de Petri enrichi contrôlant la concurrence d'actions et illustré sur la figure 3 ; - la figure 5 illustre le principe de contrôle de la couche d'application logicielle par la couche de réseau de Petri, avec l'exemple d'une application collaborative dédiée à la visualisation conjointe de vidéos médicales. L'invention concerne donc un procédé de gestion d'une session collaborative synchrone mise en oeuvre au sein d'une architecture distribuée et supervisée, dans laquelle chacun des terminaux impliqués dans la session collaborative exécute une application cliente. Dans l'exemple illustré sur la figure 1, cette architecture distribuée et supervisée comprend une application superviseur S et trois applications clientes CI à C3. Chacune des applications clientes est exécutée par un terminal (non représenté) et l'application superviseur est exécutée par un serveur (non représenté). Chacune des applications clientes est reliée à l'application superviseur S par une paire de liens bidirectionnels (la, lob), (2a, 2b), (3a, 3b) d'un ou plusieurs réseaux quelconque (s), par exemple de type Internet. Dans un mode de réalisation particulier de la présente invention, et comme illustré sur la figure 2, l'architecture distribuée et supervisée est d'un nouveau type dit basée modèle et présente une structure en deux couches : une couche d'application logicielle 21, sur laquelle les utilisateurs des applications clientes CI à C3 et de l'application superviseur S agissent ; une couche de réseau de Petri 22, basée sur un modèle de Petri enrichi (voir explications détaillées ci-après), et permettant, de manière automatique et transparente pour les utilisateurs des applications clientes, de détecter, prendre en compte et contrôler des situations de concurrence d'actions utilisateurs. Chacune des couches 21,22 comprend une première partie 21s, 22s propre à l'application superviseur S, et plusieurs secondes parties propres chacune à l'une des applications clientes. Dans un souci de simplification, on suppose dans l'exemple illustré sur la figure 2 que l'architecture implique seulement deux applications clientes CI, C2. Chacune des couches 21,22 comprend donc dans ce cas deux secondes parties 21ci, 22cj, et 21C2, 22, propres chacune à l'une de ces deux applications clientes CI, C2. La couche de réseau de Petri 22 résulte de la mise en oeuvre des étapes suivantes : élaboration d'un modèle de l'architecture distribuée et supervisée, dit modèle de Petri, au moyen d'un réseau de Petri ; analyse formelle (mathématique) du comportement du modèle de Petri, en des situations de concurrence d'actions utilisateurs, de façon à définir des paramètres de mise en oeuvre d'un mécanisme d'inhibition (voir détails ci-après) ; enrichissement du modèle de Petri avec ce mécanisme d'inhibition, de façon à obtenir un modèle de Petri enrichi permettant de détecter, prendre en compte et contrôler des situations de concurrence d'actions utilisateurs. La couche de réseau de Petri 22 contrôle la couche d'application logicielle 21. Elle met en oeuvre un mécanisme d'inhibition, de façon à gérer de manière transparente et automatique les situations de concurrence d'actions, et prévenir les situations d'interblocage et/ou de perte de cohérence. En d'autres termes, le comportement global de la couche de réseau de Petri 22 correspond à l'objectif suivant : assurer, après chaque action, la cohérence d'état entre les applications clientes, tout en préservant le niveau d'interactivité entre les utilisateurs, même dans des situations de concurrence d'actions. Le principe général de fonctionnement est le suivant : l'occurrence d'un événement (action utilisateur) ek, j=1.. x, sur une application cliente Ck ne conduit à la k mise à jour de cette dernière Ck que sous une condition préalable de disponibilité de l'application superviseur S. Sous cette condition, les autres applications clientes seront subséquemment mises à jour. L'application superviseur S est dite disponible si elle n'est pas déjà en cours de traitement d'une autre action. Elle est dite indisponible dans le cas contraire. Dans le respect du principe énoncé ci-dessus, lorsqu'une action utilisateur est effectuée sur une application cliente Ck, une communication préalable est établie entre l'application cliente Ck et l'application superviseur S, afin de tester la disponibilité de cette dernière. Si l'application superviseur est disponible , alors l'action est rendue effective. Elle conduit à la mise à jour identique de toutes les applications clientes C,, i=1.. n (cohérence d'état), puis au retour du modèle global dans son marquage initial Mo correspondant à l'attente d'évènements externes (actions utilisateurs). Dans le cas contraire, l'indisponibilité de l'application superviseur S signifie qu'elle est déjà en cours de traitement d'un autre message (encodant une action précédente). L'action effectuée sur l'application cliente Ck est alors inhibée (elle n'est pas rendue effective) et l'application cliente Ck est contrainte à retrouver son état initial. On rappelle que la présente invention repose sur l'hypothèse suivante : il existe toujours un décalage temporel ôt, même très petit, entre deux messages arrivant au niveau d'une même application. En d'autres termes, la probabilité de voir deux messages (codant des actions concurrentes) arriver exactement au même instant, soit au niveau des applications clientes C,, soit au niveau de l'application superviseur S, peut être considérée comme nulle. On présente maintenant, en relation avec la figure 3, un exemple de modèle de Petri enrichi implémenté au niveau de la couche de réseau de Petri 22. Il est généralisé à N applications clientes, C, à CN et comprend donc une première partie 22s, propre à l'application superviseur S, et N secondes parties 22ci à 22CN, propres chacune à l'une des N applications clientes. Dans la suite de la description, on présente un mode de réalisation particulier de l'invention, dans lequel le modèle de Petri enrichi est implémenté dans un langage orienté-objet, avec au moins les deux classes d'objet suivantes : une classe d'objet "place"et une classe d'objet"transition". Les classes d'objet Place et Transition possèdent exactement la même sémantique que celle utilisée dans la théorie de Petri. La classe d'objet"place"possède un seul processus ("méthode logicielle") permettant sa création (instanciation). Elle possède en outre les attributs suivants : - un nom ; un vecteur de toutes ses transitions situées en amont ; un vecteur de toutes ses transitions situées en aval ; - un booléen de marquage. La classe d'objet"transition"possède un seul processus ("méthode logicielle") permettant sa création (instanciation). Elle possède outre les attributs suivants : un nom ; un vecteur de toutes ses places situées en amont ; un vecteur de toutes ses places situées en aval ; un booléen de sensibilisation. On trouvera en annexe 1 une description détaillée des places et des transitions de l'exemple de modèle de Petri enrichi illustré sur la figure 3 (applications clientes et superviseur). Plus précisément : le tableau 1 présente de façon détaillée les places d'une des secondes parties 22c,, modélisant une application cliente C,, du modèle de réseau de Petri enrichi ; le tableau 2 présente de façon détaillée les transitions d'une des secondes parties 22C1, modélisant une application cliente Ci, du modèle de réseau de Petri enrichi ; le tableau 3 présente de façon détaillée les places de la première partie 22s, modélisant l'application superviseur S, du modèle de réseau de Petri enrichi ; le tableau 4 présente de façon détaillée les transitions de la première partie 22s, modélisant l'application superviseur S, du modèle de réseau de Petri enrichi. Dans l'exemple présenté sur la figure 3, la première partie 22s du modèle de Petri enrichi, propre à l'application superviseur S constitue une classe d'objet, notée RdPComSuperviseur , qui comprend : les places génériques suivantes : * une place Rs pour traiter l'attente d'actions utilisateurs ; * une place PEnS~émisssion pour indiquer que l'application superviseur est indisponible et en cours de traitement d'un message encodant une action rendue effective ; * une place Pg, ffusion pour indiquer le début de la phase de ré-émission d'un message encodant une action rendue effective par l'application superviseur ; * une place Rediffusion pour indiquer la fin de la phase de ré-émission d'un message encodant une action rendue effective par l'application superviseur, vers toutes les applications clientes impliquées dans la session collaborative ; les transitions génériques suivantes : * une transition Ton pour transmettre un message encodant une action rendue effective vers chaque application cliente C., i=l.. n, i ; z ! k ; * une transition Télédiffusion pour la fin du processus de ré-émission d'un message encodant une action vers toutes les applications clientes impliquées dans la session collaborative ; les vecteurs de places suivants : * un vecteur de places (Places~demande~disponibilite) pour traiter l'arrivée des tests de disponibilité effectués par les applications clientes : PRes~@S ; * un vecteur de places (Places~attente~msg) pour traiter l'attente de messages encodant les actions utilisateurs rendues effectives pour les applications clientes, sur disponibilité du superviseur : tmsgi * un vecteur de places (Placesnotificationarriveemsg) pour traiter l'arrivée de messages encodant les actions utilisateurs rendues effectives pour les applications clientes : Pg~i ; 1 * un vecteur de places (Places~attente~acq) pour traiter l'attente d'acquittements envoyés par les applications clientes suite à l'envoi d'un message par l'application superviseur : P tUcq~i ; * un vecteur de places (Places~notification~arrivee~acq) pour traiter l'arrivée d'acquittements envoyés par les applications clientes suite à l'envoi d'un message par l'application superviseur : PR~acq~iS ; les vecteurs de transitions suivants : * un vecteur de transitions (Transitions~disponibilité) pour rendre effective une action utilisateur effectuée sur l'une des applications clientes Ci et rendre l'application superviseur indisponible pour les autres applications clientes : TRes~i~OK S ; * un vecteur de transitions (Transitions~indisponibilité) pour demander à une application cliente Ci d'inhiber une action utilisateur si l'application superviseur est indisponible : Tps , e~i-nonOK 9 * un vecteur de transitions (Transition~diffusion~msg) pour transmettre un message encodant une action effective de l'une des applications clientes C, vers les autres applications clientes : TMmsg. ; * un vecteur de transitions (Transition~fin~diffusion~msg) pour terminer la transmission d'un message encodant une action effective de l'une des applications clientes Ci vers les autres applications clientes, l'application superviseur retournant dans un état initial traduisant la disponibilité : TS FF~diffmsgi avec i E {1, N} et N 0 le nombre d'applications clientes connectées à l'application superviseur. Dans les deux classes RdP~Com~Superviseur et RdP~Com~Client , sont prévues des processus ( méthodes logicielles ) permettant aux instances de s'interconnecter. Ainsi, deux processus sont définis à l'intérieur de la classe RdPComSuperviseur . La première instancie les places et les transitions génériques de la partie du modèle de Petri enrichi propre à l'application superviseur, crée ensuite les arcs orientés entre ces dernières et initialise le marquage du réseau de Petri en déposant un jeton dans la place P (booléen de marquage de R à 1). La seconde gère la croissance/décroissance automatique de la partie du réseau de Petri associée à l'application superviseur, au fur et à mesure des connexions/déconnexions des applications clientes. Ainsi, lorsqu'une nouvelle application cliente. se connecte au superviseur, les cinq nouvelles places (Pk, PA,ttm. g Pgk, Pittacq~k et PR acq k) et les Ts quatre nouvelles transitions (Ton TL.k~nonOK 1fmsgk etiffg~k) sont créées (instanciées et ajoutées aux vecteurs listés ci-après), puis câblées avec les places et les transitions génériques du réseau de Petri global"RdP~ComSuperviseur". Ce câblage est réalisé par l'ajout de places dans les vecteurs des places amonts ou avales appartenant à certaines transitions, ou par l'ajout de transitions dans les vecteurs des transitions amonts ou avales associés à certaines places du modèle. Dans l'exemple présenté sur la figure 3, chaque seconde partie 22ci du modèle de Petri enrichi, propre à l'une des applications clientes Ci constitue une classe d'objet, notée RdPComClient , qui comprend : les places suivantes : * une place P pour traiter l'attente des actions utilisateurs ou des messages provenant de l'application superviseur ; * une place Pi pour traiter l'arrivée d'un message reçu de l'application superviseur ; * une p1ace Pltt~rep pour traiter l'attente d'une réponse sur la disponibilité ou indisponibilité de l'application superviseur ; * une place LNonOK pour traiter l'arrivée d'une réponse négative sur la disponibilité de l'application superviseur, l'action utilisateur devant être inhibée ; * une place PRes OK pour traiter l'arrivée d'une réponse positive sur la disponibilité de l'application superviseur, l'action utilisateur devant être rendue effective ; * une p1ace Pl pour indiquer que l'application cliente C, est en phase de traitement local de l'action rendue effective par l'application superviseur ; * une place P pour indiquer que l'application cliente C, est en phase de traitement d'un message provenant de l'application superviseur ; * une p1ace Pl pour indiquer qu'une mise à jour locale a été effectuée ; * une place Pi pour indiquer le début d'une phase d'émission vers l'application superviseur d'un message encodant une action utilisateur ; * une place Pg pour indiquer que l'application cliente Ci est en phase d'émission et en attente d'un acquittement de l'application superviseur ; * une place P pour indiquer que l'application cliente C, a terminé la phase d'émission et a reçu un acquittement de l'application superviseur ; les transitions suivantes : * une transition Td pour tester la disponibilité de l'application superviseur, en vue d'inhiber ou rendre effective une action utilisateur effectuée sur l'application cliente C, ; * une transition Trois pour inhiber une action utilisateur et ramener l'application cliente Cl dans son dans son état initial d'attente d'actions utilisateurs, en cas d'indisponibilité de l'application superviseur ; * une transition Ti pour décoder puis exécuter un message reçu de l'application superviseur ; * une transition T pour exécuter localement une action utilisateur rendue effective par la disponibilité de l'application superviseur ; * une transition T pour envoyer un acquittement à l'application superviseur suite au traitement local du message reçu, puis ramener l'application cliente Ci dans son état initial d'attente d'actions utilisateurs ; * une transition H pour encoder une action utilisateur effective sous la forme d'un message ; * une transition Ti pour transmettre à l'application superviseur un message encodant une action utilisateur effective ; * une transition 1 pour ramener l'application cliente C, dans son état initial d'attente d'actions utilisateurs. Le processus ( méthode logicielle ) d'instanciation de la classe RdPComClient crée le réseau de Petri associé à l'application cliente exécutée. Il initialise le marquage de l'instance du réseau de Petri associée à l'application cliente exécutée en"déposant un jeton"dans la place P (booléen de marquage de R ; à 1). Le modèle généralisé de la figure 3 fait apparaître une vectorisation des places et des transitions de l'application superviseur, qui sont reliées à celles des applications clientes, celles-ci pouvant, dynamiquement, se connecter/déconnecter. Ceci facilite la programmation orientée-objet qui favorise une gestion dynamique des indices. A partir de cette forme généralisée du modèle de Petri enrichi, l'implémentation de la couche réseau de Petri, dans n'importe quel langage orienté-objet, est facilitée. En effet, dans les langages orientés objets, il existe des classes prédéfinies qui permettent de gérer dynamiquement des listes ou vecteurs d'objets (insertion d'un objet à une place particulière, retrait d'un objet,..., avec une gestion automatique des indices et de la mémoire). L'interconnexion d'une nouvelle application cliente Ckavec l'application ps superviseur S implique l'insertion de nouvelles places : Pes~k'PXtt~msÛ'PSlLk'PXtucq~k et Ptacq~k, dans 1es vecteurs de places précités (Places~demande~disponibilite, Places~attente~msg, Places~notification~arri vee~msg, P1aces~attente~acq, P1aces~notification~arrivee ~acq). Elle provoque également l'insertion de nouvelles transitions TeskoK L'analyse structurelle et l'analyse énumérative ont été appliquées à ce modèle. Les résultats obtenus prouvent que : il existe toujours une séquence de transitions conduisant à la mise à jour identique des N applications clientes C,... CN, même en la présence d'un conflit d'actions, puis au retour de l'architecture dans un état d'attente d'évènements extérieurs ; il n'existe plus aucune classe d'état représentative de situations de blocage et d'interblocage ; tout conflit d'actions est désormais détecté, puis traité par un mécanisme d'inhibition introduit dans le modèle de Petri de l'application superviseur. Ce mécanisme d'inhibition vise à rendre une action non effective si l'application superviseur est déjà occupée à traiter une autre action. En résumé, le mécanisme d'inhibition propre à la présente invention s'appuie sur l'enrichissement du modèle de Petri (de base) avec les places et transitions suivantes : en ce qui concerne une application cliente Ci : : Pp PRLNon~OK. RLoK. et Refus (cf. tableaux 1 et 2 en annexe 1) ; en ce qui concerne l'application superviseurS:R,j,PAttmsgi.Pg: Paeqi. - Att~msg~i e pmsg~i i PAStt~arq-i PRacqi Enmission'TResLOK!TResinonOK?Tr)fffmsgi et TFmdiffmsg i (cf. tableaux 3 et 4 en annexe 1). La figure 4 présente l'arbre de couverture construit pour le réseau de Petri enrichi contrôlant la concurrence d'actions et illustré sur la figure 3. Il prouve les trois points mentionnés ci-dessus, qui peuvent être généralisés pour N applications clientes. Le détail des calculs de l'analyse énumérative permettant sa construction est donné est annexe 2 du présent document. Les séquences de transitions identifiées par les arcs orientés en trait gras correspondent aux situations décrivant le fonctionnement normal de l'architecture distribuée et supervisée, sans situation de concurrence. Les séquences de transitions identifiées par les arcs en trait pointillé correspondent à l'inhibition d'une ou plusieurs actions concurrentes. Les séquences de transitions représentées par des arcs en trait fin représentent le fonctionnement de l'architecture impliquant le traitement d'une ou plusieurs actions concurrentes. On décrit maintenant, en relation avec la figure 5, le principe de contrôle de la couche d'application logicielle 21 par la couche de réseau de Petri 22, avec l'exemple d'une application collaborative dédiée à la visualisation conjointe de vidéos médicales. Les mécanismes de ce contrôle, symbolisés sur la figure 2 par des flèches en trait plein ou pointillé, ont pour objets de contraindre les processus ( méthodes logicielles ) appartenant aux objets de la couche d'application logicielle 21 à s'exécuter dans un ordre imposé par le marquage du réseau de Petri distribué sous-jacent (couche de réseau de Petri 22). Les transitions du modèle de Petri enrichi considéré possèdent une sémantique parfaitement identifiée qui permet de les associer à l'exécution de certaines méthodes logicielles . A titre d'exemple, la transition Tu est rattachée à une méthode logicielle appelée encoderMessageQ contenue dans chaque application logicielle cliente. Dans l'architecture à deux couches, celle-ci ne pourra alors s'exécuter que si le marquage courant de la couche de réseau de Petri 22 sensibilise la transition H (marquage des places P et P). Dans le cas contraire, une exception logicielle devra être traitée. La présente approche s'appuie sur le principe général suivant. Les méthodes logicielles de la couche d'application logicielle 21 sont d'abord associées aux transitions de la couche de réseau de Petri 22. Pour pouvoir s'exécuter, celles-ci doivent préalablement interroger le marquage de la couche de réseau de Petri 22 sous-jacente. Si cette dernière sensibilise la transition correspondante, alors la méthode logicielle pourra s'exécuter, son exécution conduisant alors à l'évolution de la couche d'application logicielle 21 et à celle du marquage de la couche de réseau de Pétri 22. Ce nouveau marquage servira à son tour de pré-condition à l'exécution d'autres méthodes logicielles . Désormais, la séquentialité dans l'exécution des méthodes de la couche application logicielle est totalement contrôlée par l'évolution du marquage de la couche réseau de Petri sous-jacente. Ce principe est générique. Il permet le contrôle de la couche d'application logicielle 21 par la couche de réseau de Petri 22 tolérante à la concurrence d'actions. Ce principe de contrôle de l'exécution des processus ( méthodes logicielles ) de la couche d'application logicielle 21 imposé par le marquage de la couche de réseau de Petri 22, est illustré à titre d'exemple sur la figure 5. La partie droite de cette figure 5 présente le début de code informatique exécuté lorsqu'un utilisateur appuie sur le bouton PLAY de la barre de navigation proposée par une application (cliente) de vidéo collaborative et la partie gauche illustre l'évolution parallèle du marquage de la couche de réseau de Petri sous-jacente. Le marquage du réseau de Petri sous-jacent est considéré comme pré-condition à l'exécution de certaines méthodes logicielles . Optionnellement, on peut déporter la couche de réseau de Petri 22 dans un réseau d'objets de type RdPContrôleur , permettant de masquer et déléguer des contrôles (de type {If [RdP~Com~C1ient. T4 isEnabled]...}) présents dans le code de la couche d'application logicielle 21 (c'est-à-dire dans le code des applications clientes et superviseur). Ceci permet de faciliter la tâche d'un informaticien, peu familier des Réseaux de Petri et désireux néanmoins de mettre en oeuvre le procédé selon l'invention décrit ci-dessus. Ce réseau d'objets peut aiguiller le comportement de l'architecture distribuée et supervisée, soit vers une évolution normale , soit vers le traitement des exceptions. Dans cette nouvelle configuration, toutes les actions effectuées par un utilisateur sur l'interface logicielle de son application (évènements souris sur des boutons, etc. ) ne seront plus directement transmises aux méthodes logicielles de l'application logicielle, mais capturées par chaque objet RdPContrôleur qui décidera (ou non) de la mise à jour locale de cette dernière, puis de la transmission du message correspondant vers l'objet RdPContrôleur , contenu dans l'application superviseur. Ce dernier effectue également les contrôles nécessaires sur le réseau de Petri, avant de retransmettre le message vers tous les autres objets RdPContrôleurs instanciés par les autres applications clientes. ANNEXE 1 Description détaillée des places et des transitions de l'exemple de modèle de Petri enrichi illustré sur la figure 3 (applications clientes et superviseur) P01 En attente d'événement externe : action utilisateur ou réception de message P11 Message reçu de l'application superviseur Pi Action utilisateur a=l.. 2, jE[1, 00] effectuée ; application en attente de la réponse sur la disponibilité ou non disponibilité du superviseur PRes-Non-oK Réponse négative sur la disponibilité du superviseur-l'action doit être inhibée PRes~OK Réponse positive sur la disponibilité du superviseur-l'action est rendue effective Pi En hase de traitement local de l'action rendue effective par le superviseur P En phase de traitement d'un message provenant du superviseur Pi Mise à jour locale effectuée Action encodée sous la forme d'un message - Début de la phase d'émission du P51 message vers le superviseur ? 6 En phase d'émission-attente de l'acquittement du superviseur Pl Fin de la phase d'émission-acquittement du superviseur reçu Tableau 1 : Places du modèle de réseau de Pétri enrichi modélisant une application cliente Ci. 2 A1o de reseau Tableau 1 : Places uu fIXVU TOI Tester la disponibilité du superviseur pour inhiber ou rendre effective l'action utilisateur effectuée sur C, Tiefus Inhiber l'action utilisateur et ramener C, dans son marquage initial sur indisponibilité du superviseur T1i Décoder puis exécuter un message reçu du superviseur Ti Exécuter localement l'action utilisateur rendue effective par la disponibilité du 2 superviseur T, Envoyer un acquittement au superviseur suite au traitement local du message reçu puis ramener C, dans son marquage état initial T Encoder l'action effective sous la forme d'un message Tg Transmettre le message encodant l'action effective au superviseur Ti Ramener l'application cliente C, dans son état initial d'attente d'événement 6 externe Tableau 2 : Transitions du modèle de réseau de Petri enrichi modélisant une application cliente Ci. n ps Attente d'événements externes : tests de disponibilité effectués par les application clientes Ci, i=l.. n Ps Indisponible - en cours de traitement d'un message encodant une action PEDS~émission rendue effective Ps Fin de la ré-émission d'un message vers toutes les applications clientes Ci, @ Fin~émission i=1..n Début de la phase de ré-émission d'un message encodant une action rendue PDiffusionS effective par le superviseur Fin de la phase de ré-émission d'un message encodant une action rendue mdiffusion effective par le superviseur, vers toutes les applications clientes impliquées dans la session collaborative. PRes~iS Test de disponibilité exécuté par l'application cliente Ci, i+l..n Ps En attente de la réception du message encodant l'action rendue effective pour Alt~msg~t Ci i=l.. n PMsg~iS Message encodant l'action rendue effective pour Ci bien reçu (i=l.. n) Pttacqi En attente de l'acquittement de Ci suite à l'envoi d'un message (i=l.. n) PR~acq-@S Acquittement attendu de C, bien reçu Tableau 3 : Places du modèle de réseau de Petri enrichi modélisant l'application superviseur. TRes-I-nonOKS Inhiber l'action demandée par l'application cliente C,, i=l..n rps Rendre effective l'action effectuée sur Ci, il n, et se rendre indisponible pour pourC,, i, Débuter la transmission d'un d'un message rendu effectif pour l'application cliente TDiffusion~msg~iS Ci, i=1..n, vers les autres applications clientes K#i TFin~diffusion~msg~@S Terminer la rediffusion du message vers l'application cliente C,, i=l.. n, i k Tlffuslon Transmettre un message encodant une action rendue effective vers chaque Diffusion application Ci, i=1.. n, i k Ts Fin du processus de ré-émission d'un message encodant une action vers Fin-diffusion toutes les applications clientes impliquées dans la session collaborative Tableau 4 : Transitions du modèle de réseau de Petri enrichi modélisant l'application superviseur. ANNEXE t : Analyse énumérative du modèle de Petri de l'architecture collaborative synchrone supervisée tolérante à la concurrence d'actions (réduite à l'interconnexion de 2 applications clientes au superviseur) : p', p\ p 0 0 {J'0'0 D TI -7 E Etat 0 initial T * E 0 2 E M pl, p2, pS, pS ! ! mRep 0 0 Rej : - D T"--- > E r'- T 2 E 0 4 Franchissement de TI. 0 E M pl, p2, ps, pS 2 2 0 A'Rep 0 Res~2 D TI -7 E 2 0 5 TS -7 E RM2 6 Franchissement de T2. 0 E M : pl, pl, P', P, pS 3 : TI -7 E 3 2 7 D 2 7 0 8 T2 E rr. Franchissement de TS Re, ~I~OK Pl p Ps ps ps 4 3 AfRep 0 Res tJ Res~2 D : TS -7 E Concurrence d'actions identifiée, mais l'hypothèse Re ; !) o 9 permet de franchir l'une ou l'autre des Ts -7 E transitions Ts ou Ts Rc. 2, o '-LO R Franchissement de T Re, ~I~OK E = E 4 5 E M : pl, p', p', pS, 6 6 0 Ait-Rp Re,-OK'Ail-mg-2' 6 To E M pl, pl, p2, pS, pS.. 7 7 2 4 0 A H ; sg ! & 2 E M : p', ?', p', p', p, p E m : Pl 8 S/)Anf~Rep Ret0/t 0 Pl P2 ps ps, ps E M : p', ?', p', p, p, p 9 9 Au~Rep Res~OK At/~Rep Att~msg... I Res~2 En~etnfSSlOn D Tl 2 M : P', P\, P 13 13 S 0/ 4 E M : pl pl p2 p5 5 E m : Pl'Pl'Pl, PS ps ps 14 14 Res D : ---7 E , 'e 14 4 25 Ts ---7 E Re~2~nonOK 26 Franchissement de T2. 0 E =E ]5 14 m : Pl Pl P2 ps p s ps E M pl pl p2 pS pS pS 6) 6 jM ; tp ReOA/ifftp Ret2non0 '"Uj ! & ! 2 E = E 21 20 : P', P\P'', P' 22 22 0 S.'f"'g2 ) Mtton D : T X E D raze 22 0)) T2 -7 E 5 34 2 Franchissement de T2. 4 E M pl pZ pS pS pS 23 M : p' p p p P 23 23 6 0 A/l~msg I msg~l En~emiszfon D TS -7 E 2 : Dll ~mog ~ i 35 O.//m. i 3 ; T2 -7 E 0 36 Franchissement de TI. 5 E M : ?', ?', P, P", P 24 24 5 (ffq) ('m & - En E E = F 24 M. P', P', P', ?', p, P' M 2f. 2 4. 4n~ : rp > Re X nollOK All~ g I Ez D. 26 TI -7 E 4 39 r'- Re/m 40 Franchissement de T Res--OK E E 27 26 E =E 28 3 E E 29 6 E M : ?', ?', P\P\ P', P' 30 30 t7 Re. tnon0 2 4/ - E ReL"o"C' 43 r'- > E 32 43 T 2 E 5 44 2 Franchissement de T2. 4 E =E 33 32 E M : pl p2 pS ps 5 M : p', p\p, p, ?' D : T'E 34 0 45 TS -7 E D" !. !) ; 2 46 Franchissement de Tu. 5 3S 3S 6 0) ) C2 E = E 37 36 E M : P', p, P p pS 38 38"'w E 38 38 3, 4/f Rc/) C'' f//nt f D Tl 0 E =E 39 38 E -E 40 7 E =E 41 12 E M : P'Pl p2 pS p5 42 42 : , p p, D TI E D : T' E 42 Repus 53 Ré/m H 5 54 S M Franchissement de T. 4 E = E 43 42 E M : pl p2 pS pS pS pS , ', \',, ", , '' D : ' 44 Re 4 E =E 45 44 E M : pl p2 pS ps 46 46 0 16 Ali-ACQ-1 En--im, o D tizzy ' 0 57 T'E 1 58 Franchissement de Ts o. ym M : P', P', P', P' P' 47 47 6 3 4 f ;. 4C6 ! & 1 AI E M : P', P', P\ P P, P 47 4S 47 6 l, q . !' 2 En E =E 49 48 E50 M50 P6 > PAn wzp > PRe nollOK) Arr~mzg~l > mJg~l > Cn e ion M : P'P P P P P 50 50 6 Ait-"p 5Re, -,, OK'A ( (-., g-, D TS -7 E T Dml E r'- F Relus 62 Franchissement de ? Res~2~nonOK E =E 51 50 E =E 52 13 E =E 53 22 E M : pl pl p2 pS pS pS M : P', P', P', P', P', P' S4 M 5 E = E 55 54 : P', ', P\P', P', P' M M K ! 6 n. 4CgJ N) H\um) Rc'J D : -7 E 16, Ait D T"E 56 Re.) ~Î~l1onOK 65 Franchissement de tus y."2 E =E 57 56 E M : pl, , P\P, ?' 58 58 3 4 6 Au~ACQ~1 En~etmsslQn - 58 3 66 58 3 66 Franchissement de TI. E M : pl p 2 p 5 p 5 E M : p', p\ p, p, p 59 59 6 .'ACg2 K/ ! CQ2 Enemission D TS -7 E ''''f"''"J 67 Te -7 E 0 68 2 Franchissement de T2. 3 E M pl, pz, p2, pl, pS, pS 60 59 6 Au Re. n0 2 ; Cp2 & t (-m, M D : E Re 69 Franchissement de TS Res~2~l1oIl0K E =E 6i 60 E E 62 23 E E 63 34 E m : Pl'Pl p1 &commat; &commat;p2&commat; pS ps E M : pi, p', p', p\P', pS 64 64 1, 4tl~n ! p Re. \~nonOK (, Al/~ACQ~I EIt~elfll. çslon D Ti ---7 E Re7 70 Franchissement de Ts ox-2 = E =E 65 64 E M pi p2, P\P', P', P' 66 66 0 6 AfCSJ R~ACQJ & -mMHfM D Ti ---7 E 66 0 7i Ts E Fin dif). 2 72 W 72 Franchissement de Ti. 3 E M : pl P', P\P 67 67 6 7 0 0 D -F'- E Retour dans l'état initial par 67 6 0 6 Franchissement de Ts Fi dij E M : P', f', P', P'', P, pS 68 68 6 All~ltp R~ACQ~2 Arr~ACQ~2 En~eml : J. \UJ ! 1 Re : > ~2 D : asz E Ts franchi en priorité 68 Res~2onOK 73 Res~2~nonOK 2 Franchissement de T. 0 E =E 69 35 E =E 70 46 E M : p2, P\P", P, 7, 7 71 71 En Aii-rep 6 Ait-ACQJ R-ACQ-1 Resj D TS ---7 E tus franchi en priorité 'ResL"onOK 73 RMtnonO Franchissement de TO. E M : p2 p2 pS 72 72 0 6 7 0 D T2 ---7 E Retour dans l'état initial par T2 72 6 0 6 Franchissement de Ts FinMW' 2 E M pi, p2, p2, pS, pS., pó" 71 73 6 K ; tp Rt :'. n 1 Franchissement de TS Res !~"mOK E M pl pl p2 pS pS pS 74 7) Alt~rt ! f)' Rc~n (JnOK' 6'Atl~ACQ~" R~ACQ~l'L'1I~el11f. \lOn - "f"'jM :,-2 76 Franchissement de TS ResLnonOK E M : P', P', P\ PS 75 75 6'7'0'0 D F' Retour dans l'état initial par T' 75 6 0 6 Franchissement de T Fi dif E M : P' p p p 76 76 0'6'7'0 ,, r F Retour dans l'état initial par T2 76 6 0 6 Franchissement de T Fin jiff ~msg ~2 REVENDICATIONS 1. Procédé de gestion d'une session collaborative synchrone mise en oeuvre au sein d'une architecture distribuée et supervisée, dans laquelle chacun des terminaux impliqués dans la session collaborative exécute une application cliente, caractérisé en ce que ledit procédé met en oeuvre un mécanisme d'inhibition comprenant les étapes suivantes, lors de l'occurrence d'une action utilisateur sur une application cliente Ck : on établit de façon automatique une communication entre l'application cliente Ck et une application superviseur, de façon que l'application cliente Ck effectue un test de la disponibilité de l'application superviseur ; si l'application superviseur est disponible, alors l'application cliente Ck rend effective ladite action utilisateur et l'application superviseur met à jour l'ensemble des autres applications clientes en fonction de ladite action utilisateur ; si l'application superviseur est indisponible, ladite action utilisateur est inhibée et n'est pas rendue effective par l'application cliente Ck ; de façon à garantir le maintien de la cohérence d'état entre les applications clientes, même en cas de concurrence d'actions utilisateurs. 2. Procédé selon la revendication 1, caractérisé en ce que ladite architecture distribuée et supervisée, comprenant l'application superviseur et les applications clientes, est basée sur un modèle de Petri enrichi résultant de la mise en oeuvre des étapes suivantes : élaboration d'un modèle de ladite architecture distribuée et supervisée, dit modèle de Petri, au moyen d'un réseau de Petri ; analyse formelle du comportement du modèle de Petri, en des situations de concurrence d'actions utilisateurs, de façon à définir des paramètres de mise en oeuvre dudit mécanisme d'inhibition ; enrichissement du modèle de Petri avec ledit mécanisme d'inhibition, de façon à obtenir un modèle de Petri enrichi permettant de détecter, prendre en compte et contrôler des situations de concurrence d'actions utilisateurs. 3. Procédé selon la revendication 2, caractérisé en ce que ladite architecture distribuée et supervisée, comprenant l'application superviseur et les applications clientes, possède une structure en deux couches : une couche d'application logicielle, sur laquelle les utilisateurs des applications clientes et de l'application superviseur agissent ; une couche de réseau de Petri, basée sur ledit modèle de Petri enrichi, et permettant, de manière automatique et transparente pour les utilisateurs des applications clientes, de détecter, prendre en compte et contrôler des situations de concurrence d'actions utilisateurs ; et en ce que la couche de réseau de Petri contrôle la couche d'application logicielle. 4. Procédé selon la revendication 3, caractérisé en ce que les processus ("méthodes logicielles") associés à la couche d'application logicielle sont également associés aux transitions de la couche de réseau de Petri, et en ce que chacun des processus associés à la couche d'application logicielle ne peut s'exécuter que si le marquage de la couche de réseau de Petri sensibilise la transition correspondante, cette exécution conduisant à l'évolution de la couche d'application logicielle et à l'évolution du marquage de la couche de réseau de Petri. 5. Procédé selon l'une quelconque des revendications 3 et 4, caractérisé en ce que la couche de réseau de Petri est déportée dans un réseau d'objets permettant de masquer et déléguer des contrôles présents dans le code de la couche d'application logicielle. 6. Procédé selon l'une quelconque des revendications 2 à 5, caractérisé en ce que le modèle de Petri enrichi possède une forme généralisée comprenant : une première partie propre à l'application superviseur ; plusieurs secondes parties propres chacune à l'une des applications clientes, et en ce que ledit mécanisme d'inhibition est introduit dans la première partie du modèle de Petri enrichi, propre à l'application superviseur. 7. Procédé selon l'une quelconque des revendications 2 à 6, caractérisé en ce que le modèle de Petri enrichi est implémenté dans un langage orienté-objet. 8. Procédé selon la revendication 7, caractérisé en ce que le modèle de Petri enrichi est implémenté avec au moins les deux classes d'objet suivantes : une classe d'objet "place"et une classe d'objet"transition". 9. Procédé selon la revendication 8, caractérisé en ce que la classe d'objet"place" possède au moins un des attributs appartenant au groupe comprenant : - un nom ; un vecteur de toutes ses transitions situées en amont ; un vecteur de toutes ses transitions situées en aval ; un booléen de marquage ; et possède un seul processus ("méthode logicielle") permettant sa création (instanciation). 10. Procédé selon l'une quelconque des revendications 8 et 9, caractérisé en ce que la classe d'objet"transition"possède au moins un des attributs appartenant au groupe comprenant : - un nom ; un vecteur de toutes ses places situées en amont ; un vecteur de toutes ses places situées en aval ; - un booléen de sensibilisation ; et possède un seul processus ("méthode logicielle") permettant sa création (instanciation). 11. Procédé selon l'une quelconque des revendications 8 à 10, caractérisé en ce que le modèle de Petri enrichi possède une forme généralisée comprenant : une première partie propre à l'application superviseur ; plusieurs secondes parties propres chacune à l'une des applications clientes, et en ce que la première partie du modèle de Petri enrichi, propre à l'application superviseur, comprend au moins un vecteur de places et/ou au moins un vecteur de transitions, qui sont reliés à au moins certaines places et/ou transitions correspondantes des secondes parties du modèle de Petri enrichi, propres aux applications clientes. 12. Procédé selon la revendication 11, caractérisé en ce que l'interconnexion d'une nouvelle application cliente avec l'application superviseur comprend au moins une des étapes suivantes : insertion de nouvelles places dans lesdits vecteurs de place ; insertion de nouvelles transitions dans lesdits vecteurs de transitions. 13. Procédé selon l'une quelconque des revendications 8 à 12, caractérisé en ce que le modèle de Petri enrichi possède une forme généralisée comprenant une première partie, propre à l'application superviseur, et plusieurs secondes parties, propres chacune à l'une des applications clientes, et en ce que la première partie du modèle de Petri enrichi, propre à l'application superviseur, comprend : au moins une des places génériques appartenant au groupe comprenant : * une place P pour traiter l'attente d'actions utilisateurs ; * une p1ace Pn~émisssion pour indiquer que l'application superviseur est indisponible et en cours de traitement d'un message encodant une action rendue effective ; * une place Fusion pour indiquer le début de la phase de ré-émission d'un message encodant une action rendue effective par l'application superviseur ; * une p1ace PmdediffuslOn pour indiquer la fin de la phase de ré-émission d'un message encodant une action rendue effective par l'application superviseur, vers toutes les applications clientes impliquées dans la session collaborative ; au moins une des transitions génériques appartenant au groupe comprenant : * une transition Ton pour transmettre un message encodant une action rendue effective vers chaque application cliente CI, i=1.. n, i ; z ! k ; * une transition Tndediffusion pour la fin du processus de ré-émission d'un message encodant une action vers toutes les applications clientes impliquées dans la session collaborative ; au moins un des vecteurs de places appartenant au groupe comprenant : * un vecteur de places (Places~demande~disponibilite) pour traiter l'arrivée des tests de disponibilité effectués par les applications clientes : PRes~@S ; * un vecteur de places (Places~attente~msg) pour traiter l'attente de messages encodant les actions utilisateurs rendues effectives pour les applications clientes, sur disponibilité du superviseur : Ptmsg i ; un vecteur de places (Places noti * un vecteur de places (Places~notification~arrivee~msg) pour traiter l'arrivée de messages encodant les actions utilisateurs rendues effectives pour les applications clientes : P,g i ; sg-i 5 * un vecteur de places (Places~attente~acq) pour traiter l'attente d'acquittements envoyés par les applications clientes suite à l'envoi d'un message par l'application superviseur : Ptacqi ; un vecteur de places (Places noti * un vecteur de p1aces (Places~notijication~arrivee~acq) pour traiter l'arrivée d'acquittements envoyés par les applications clientes suite à l'envoi d'un message par l'application superviseur : PR acq i ; au moins un des vecteurs de transitions appartenant au groupe comprenant : * un vecteur de transitions (Transitions-disponibilite) pour rendre effective une action utilisateur effectuée sur l'une des applications clientes CI et rendre l'application superviseur indisponible pour les autres applications clientes @ Ts 'ResLOK ; * un vecteur de transitions (Transitions~indisponibilite) pour demander à une application cliente Ci d'inhiber une action utilisateur si l'application superviseur est indisponible : TjsjnonOK ! ,, ~i-nc) ilOK * un vecteur de transitions (Transition-diffusion-msg) pour transmettre un message encodant une action effective de l'une des applications clientes C, vers les autres applications clientes : TDiff~msg~@S ; * un vecteur de transitions (TransitionJin~diffusion~msg) pour terminer 1a - fusion-msg) pour terminer la transmission d'un message encodant une action effective de l'une des applications clientes C, vers les autres applications clientes, l'application superviseur retournant dans un état initial traduisant la disponibilité : nrs TFindiffmsgi ; avec i C {l, n} et n s : 0 le nombre d'applications clientes connectées à l'application superviseur. 14. Procédé selon l'une quelconque des revendications 8 à 13, caractérisé en ce que le modèle de Petri enrichi possède une forme généralisée comprenant une première partie, propre à l'application superviseur, et plusieurs secondes parties, propres chacune à l'une des applications clientes, et en ce que chaque seconde partie du modèle de Petri enrichi, propre à l'une des applications clientes CI, comprend : au moins une des places appartenant au groupe comprenant : * une place P pour traiter l'attente des actions utilisateurs ou des messages provenant de l'application superviseur ; une place Pi pour traiter l'arrivée d'un message reçu de l'application superviseur ; * une p1ace P tuep pour traiter l'attente d'une réponse sur la disponibilité ou indisponibilité de l'application superviseur ; * une place PResi~Non-OK pour traiter l'arrivée d'une réponse négative sur la disponibilité de l'application superviseur, l'action utilisateur devant être inhibée ; * une p1ace P es~OK pour traiter l'arrivée d'une réponse positive sur la disponibilité de l'application superviseur, l'action utilisateur devant être rendue effective ; une place Pi pour indiquer que l'application cliente Ci est en phase de traitement local de l'action rendue effective par l'application superviseur ; * une place P pour indiquer que l'application cliente C, est en phase de traitement d'un message provenant de l'application superviseur ; * une place Pi pour indiquer qu'une mise à jour locale a été effectuée ; * une p1ace PJ pour indiquer le début d'une phase d'émission vers l'application superviseur d'un message encodant une action utilisateur ; * une p1ace PJ pour indiquer que l'application cliente Cl est en phase d'émission et en attente d'un acquittement de l'application superviseur ; * une place P pour indiquer que l'application cliente C, a terminé la phase d'émission et a reçu un acquittement de l'application superviseur ; au moins une des transitions appartenant au groupe comprenant : * une transition Ti pour tester la disponibilité de l'application superviseur, en vue d'inhiber ou rendre effective une action utilisateur effectuée sur l'application cliente C, ; une transition TRi, * une transition T pour inhiber une action utilisateur et ramener l'application cliente CI dans son dans son état initial d'attente d'actions utilisateurs, en cas d'indisponibilité de l'application superviseur ; * une transition 1 ; 1 pour décoder puis exécuter un message reçu de l'application superviseur ; * une transition T pour exécuter localement une action utilisateur rendue effective par la disponibilité de l'application superviseur ; * une transition T pour envoyer un acquittement à l'application superviseur suite au traitement local du message reçu, puis ramener l'application cliente C, dans son état initial d'attente d'actions utilisateurs ; * une transition Te pour encoder une action utilisateur effective sous la forme d'un message ; * une transition T pour transmettre à l'application superviseur un message encodant une action utilisateur effective ; * une transition TJ pour ramener l'application cliente C, dans son état initial d'attente d'actions utilisateurs. 15. Programme d'ordinateur, caractérisé en ce que ledit programme comprend des séquences d'instructions adaptées à la mise en oeuvre d'un procédé selon l'une quelconque des revendications 1 à 14 lorsque ledit programme est exécuté sur un ordinateur. 16. Produit programme d'ordinateur de gestion d'une session collaborative synchrone mise en oeuvre au sein d'une architecture distribuée et supervisée, dans laquelle chacun des terminaux impliqués dans la session collaborative exécute une application cliente, ledit produit programme d'ordinateur comprenant des instructions de code de programme enregistré sur un support utilisable dans un ordinateur comprenant des moyens de programmation lisibles par ordinateur pour effectuer, lors de l'occurrence d'une action utilisateur sur une application cliente Ck, un mécanisme d'inhibition comprenant les étapes suivantes : on établit de façon automatique une communication entre l'application cliente Ck et une application superviseur, de façon que l'application cliente Ck effectue un test de la disponibilité de l'application superviseur ; si l'application superviseur est disponible, alors l'application cliente Ck rend effective ladite action utilisateur et l'application superviseur met à jour l'ensemble des autres applications clientes en fonction de ladite action utilisateur 9 si l'application superviseur est indisponible, ladite action utilisateur est inhibée et n'est pas rendue effective par l'application cliente ci ; de façon à garantir le maintien de la cohérence d'état entre les applications clientes, même en cas de concurrence d'actions utilisateurs.