FR2862830A1 - Dispositif et procede asynchrones et automatiques de transmission de resultats entre objets communicants. - Google Patents

Abstract

L'invention concerne un procédé de gestion d'appel de méthodes à distance en langage orienté objet, par une communication asynchrone, entre un processus local d'une station et un processus distant d'une autre station, un tel appel comprenant une requête de l'un des processus, suivie d'une réponse de l'autre processus. Ce procédé consistea- à détecter la transmission d'un objet vide comme paramètre d'une requête ou d'une réponse avant son envoi d'un processus local à un processus distant (710), le calcul du contenu de cet objet vide et sa mise à disposition ayant été demandés à un processus sachant,b- à traiter l'objet vide en vue de mettre à disposition le contenu de cet objet (712) au processus distant,c- à poursuivre l'envoi de ladite requête ou de ladite réponse sur une condition de traitement satisfaite.

Description

inria74.FRD.wpd

Dispositif et procédé asynchrones et automatiques de transmission de résultats entre objets communicants L'invention concerne le domaine des communications par appels de procédures à distance (de type RPC pour Remote Procedure Call) entre un processus local et un processus distant.

Ces communications de type RPC peuvent utiliser des objets au sens du langage orienté- objet. Dans le cadre des communications de type RPC synchrone, un processus dit appelant envoie une requête à un processus appelé, le processus appelant bloquant son exécution jusqu'à recevoir le résultat de sa requête par le processus appelé.

Dans le cadre de l'invention, les communications établies entre les processus sont de type RPC asynchrone, c'est-à-dire que le processus source poursuit son exécution après l'envoi (ou dépôt) d'une requête (dit message d'appel). Ainsi, dans le cas d'une requête, le processus cible finit d'abord l'exécution de ses tâches en cours puis exécute la méthode distante en parallèle avec l'exécution du processus source et met à disposition les paramètres de la réponse en fin d'exécution de la méthode distante. Le processus source peut ainsi obtenir ses 2 0 paramètres de réponse.

Toutefois, ce type de communication RPC asynchrone ne prévoit pas de gestion de communication de ces résultats entre processus, ce qui peut entraîner des blocages lorsque l'exécution d'opérations ou l'envoi de messages nécessite ces résultats.

L'invention vient améliorer la situation.

L'invention concerne un procédé de gestion d'appel de méthodes à distance en langage orienté objet, par une communication asynchrone, entre un processus local d'une station et 3 0 un processus distant d'une autre station, un tel appel comprenant une requête de l'un des processus, suivie d'une réponse de l'autre processus, ce procédé consistant à a- à détecter la transmission d'un objet vide comme paramètre d'une requête ou d'une réponse avant son envoi d'un processus local à un processus distant, le calcul du contenu de cet objet vide et sa mise à disposition ayant été demandés à un processus sachant, b- à traiter l'objet vide en vue de mettre à disposition le contenu de cet objet au processus distant, c- à poursuivre l'envoi de ladite requête ou de ladite réponse sur une condition de traitement satisfaite.

L'invention concerne également une station informatique, comprenant - un environnement, capable d'exécuter un ou des processus locaux en langage orienté-objet, - un module de protocole, capable de traiter, par une communication asynchrone, des appels de méthodes à distance entre un processus local et un processus distant d'une autre station, un tel appel comprenant une requête de l'un des processus, suivie d'une réponse de l'autre processus.

Selon une caractéristique de l'invention, la station informatique comprend: un moniteur apte, sur une détection de l'événement qu'un objet vide intervient comme paramètre d'une requête ou d'une réponse à envoyer par le processus local au processus distant, le calcul du contenu de cet objet vide et sa mise à disposition ayant été demandés à un processus sachant, à traiter l'objet vide en vue de mettre à disposition le contenu de cet objet au processus distant, 2 0. poursuivre l'envoi de la requête ou de la réponse sur une condition de traitement satisfaite.

Le dispositif informatique selon l'invention peut comprendre de nombreuses caractéristiques supplémentaires qui pourront être prises séparément et/ou en combinaison et qui seront 2 5 exposés dans la description détaillée.

D'autres caractéristiques et avantages de l'invention apparaîtront à l'examen de la description détaillée ci-après, ainsi que des dessins annexés sur lesquels: - la figure 1 représente un réseau de stations communicant par appels de méthodes ou de procédures à distance (RPC) asynchrone, - la figure 2 illustre la communication entre deux stations de la figure 1 utilisant l'appel de procédure à distance RPC asynchrone, - la figure 3-1 illustre un réseau de stations utilisant l'appel de procédure à distance RPC asynchrone avec retour de résultats selon l'invention, - la figure 3-2 illustre en détail des composants d'une station selon l'invention, - la figure 4 est un ordinogramme illustrant le procédé d'envoi de requête ou de résultat pour 5 des communications RPC asynchrones, - la figure 5 est un ordinogramme détaillant une première réalisation d'un procédé associé à l'envoi et appelé à l'étape 702 de la figure 4, - la figure 6 est un ordinogramme détaillant une première réalisation d'un procédé de continuation automatique de résultats associée à la première réalisation du procédé de la 10 figure 5, - la figure 7 est un ordinogramme détaillant une deuxième et une troisième réalisation du procédé associé à l'envoi et appelé à l'étape 702 de la figure 4, - la figure 8 est un ordinogramme détaillant une deuxième réalisation du procédé de continuation automatique de résultats associée à la deuxième réalisation du procédé de la 15 figure 7, - la figure 9 est un ordinogramme détaillant une troisième réalisation du procédé de continuation automatique de résultats associée à la troisième réalisation du procédé de la figure 7, - la figure 10 est un ordinogramme détaillant un procédé d'attente par nécessité de résultat 2 0 selon l'invention, - la figure 11 illustre un procédé de réception de message après envoi de message de l'étape 708 de la figure 10, - la figure 12 est un ordinogramme détaillant une quatrième réalisation du procédé de continuation automatique de résultats associée aux procédés des figures 10 et 11. 25 Les dessins contiennent, pour l'essentiel, des éléments de caractère certain. Ils pourront donc non seulement servir à mieux faire comprendre la description, mais aussi contribuer à la définition de l'invention, le cas échéant.

3 0 La figure 1 représente un réseau de stations communicants entre-elles. On entend par "station informatique" tout élément informatique capable d'échanger des données. Ainsi, cet élément pourra être un terminal de communication mobile comme un téléphone mobile ou un ordinateur portable, ou au contraire un terminal de communication fixe comme un ordinateur de type PC. Chaque station ST1, ST2, STO comprend un système d'exploitation ST1-2, ST2-2, STO-2, une mémoire ST1-4, ST2-4, STO-4 non partagée, un processus P1, P2, PO travaillant en langage orienté-objet, et un module de protocole de communications ST1-6, ST2-6, STO-6 de type communications par appels de méthodes ou de procédures à distance de type RPC (pour Remote Procedure Call) asynchrone capable de travailler avec des objets au sens du langage orienté objet. Ce module de protocole est capable de traiter, par une communication asynchrone, des appels de méthodes à distance RPC entre un processus local et un processus distant d'une autre station. Le module de protocole comprend une bibliothèque d'objets comprenant des méthodes ou fonctions qui permettent l'appel de méthodes à distance. Le terme "processus" désigne un programme d'instructions qui peut comprendre des appels de méthodes, des opérations à titre d'exemple. L'environnement constitué par un système d'exploitation ST1-2, une mémoire non partagée ST1-4, et un module de protocole de communications ST1-6 permet d'exécuter des processus locaaux comme Pl en langage orienté- objet.

Chaque station est reliée aux autres stations par un lien qui peut être physique ou virtuel, par exemple des câbles, des fibres optiques ou des ondes radio. De façon plus précise et à titre d'exemple, chaque station peut être reliée à un réseau 10 par un lien 10-ST1, 10-ST2, 10-STO, les stations étant ainsi reliées entre-elles.

Comme illustré sur la figure 2, le module de protocole de type RPC asynchrone permet pour un processus P1 dit client d'appeler une méthode du processus P2 dit serveur situé à distance dans la station ST2. Cet appel A est appelé aussi requête et comprend des paramètres Pa. Au sens du langage orienté-objet, une requête est un objet représentant un appel de méthode et comprenant la méthode et les paramètres d'appels. Pour que l'appel de cette méthode ressemble à un appel d'une méthode locale, le processus client P1 comprend un objet ayant une méthode locale de même nom que la méthode distante à appeler. Cette méthode locale de la station ST1 appelle certaines méthodes dans la bibliothèque d'objet du module de protocole, par exemple une bibliothèque de type Java . Ces dernières prennent en charge 3 0 les connexions réseaux, le passage des paramètres Pa et le retour des résultats appelé aussi réponse RES. Lors d'un appel de type RPC asynchrone, le processus client P1 dépose la requête avec ses paramètres d'appel dans la station ST2 puis continue son exécution. Du côté de la station ST2, le processus serveur P2 finit l'exécution de ses tâches en cours avant d'appeler la méthode locale de la station ST2 avec les paramètres d'appel et de retourner la réponse R-A, c'est-à-dire le résultat à la station ST1.

Ainsi, le processus client P1 n'appelle pas la méthode locale mais dépose seulement une 5 requête du côté de la station ST2 puis continue son exécution. De façon parallèle, le processus serveur P2 continue son exécution en cours lors du dépôt de la requête puis répond à la requête en renvoyant une réponse au processus client P1.

Bien évidemment, tout processus du réseau utilise la bibliothèque du module de protocole de type RPC asynchrone pour établir des communications par appels de méthodes à distance. De manière générale, tout processus peut être à la fois client et serveur, à savoir émettre une requête et en recevoir. On parlera donc de processus source ou local lorsque le processus envoie des requêtes ou des réponses, de processus cible ou distant lorsque le processus reçoit des requêtes ou des réponses.

Les communications établies entre les processus sont de type asynchrone, c'est-à-dire que le processus source poursuit son exécution après l'envoi (ou dépôt) d'une requête (message d'appel) ou d'une réponse. Ainsi, dans le cas d'une requête, le processus cible finit d'abord l'exécution de ses tâches en cours puis exécute la méthode distante en parallèle avec 2 0 l'exécution du processus source et met à disposition les paramètres de la réponse en fin d'exécution de la méthode distante. Le processus source peut ainsi obtenir ses paramètres de réponse.

Dans le cadre de communications de type RPC asynchrone utilisant des objets au sens du 2 5 langage orienté-objet, lorsqu'un processus envoie une requête, la réponse peut tarder ce qui peut bloquer l'exécution du processus. Un processus peut ne pas attendre la réponse à une requête et se servir de la représentation de cette réponse non encore déterminée. De manière générale, un objet est identifié par un identifiant et comprend une structure qui peut soit être vide, soit comprendre un contenu (valeurs de paramètres, méthodes). Ainsi, la représentation d'une réponse non encore déterminée peut être un identifiant d'objet indiqué comme vide ou partiellement vide. Cet objet est lié à un drapeau (flag) indiquant que cet objet est vide ou partiellement vide. L'objet peut être complètement vide, c'est-à-dire un objet dont le contenu est encore inconnu, soit comme partiellement vide, c'est-à-dire un objet dont le contenu n'est que partiellement connu. Cet identifiant d'objet vide nomme un objet dont le contenu, ou au moins une partie de celui-ci, sera la réponse à une requête donnée.

Une requête ou une réponse envoyée par un processus local à un processus distant peut avoir des paramètres comprenant un ou plusieurs identifiants d'objets vides. Plus précisément, une requête envoyée par un processus client à un processus serveur peut avoir des paramètres comprenant un ou plusieurs identifiants d'objets vides. De la même manière, une réponse envoyée par un processus serveur à un processus client peut avoir des paramètres comprenant un ou plusieurs identifiants d'objets vides. Dans ces cas, il est important que les processus distants puissent obtenir le contenu de ces objets vides une fois que ceux-ci sont disponibles.

Dans certains cas, connaître le contenu d'un objet vide est indispensable. Par exemple, lorsqu'un identifiant d'objet vide est utilisé par un processus. On entend par "utilisation" d'un identifiant d'objet vide, une opération pour laquelle déterminer le contenu de cet objet est nécessaire. Une opération est dite stricte et peut être à titre non limitatif une addition, une soustraction, une division, une multiplication si l'identifiant de l'objet nomme un objet représentant un nombre. Dans le cas d'une utilisation, il est nécessaire que le processus puisse obtenir le contenu de l'objet vide afin d'exécuter l'opération.

Un mécanisme de gestion de transmission des contenus d'objets vides vers les processus en ayant besoin apparaît nécessaire.

La figure 3-1 illustre le réseau de stations de la figure 1.Les références identiques à celles de 25 la figure 1 désignent les mêmes éléments.

Les communications RPC asynchrones entre les processus P1 et PO décrites maintenant sont représentées par des flèches en traits tiretés.

3 0 Lors d'un appel RPCO-a de type RPC asynchrone, le processus source P1 crée un identifiant d'objet vide ID-01 représentant la réponse à la requête RPCO-a, sérialise la requête comme présenté sur la figure 4 décrite ci-après, dépose dans la station STO la requête RPCOa avec ses paramètres d'appel qui comprennent l'identifiant de l'objet vide ID-01 puis continue son exécution. Dans la station STO, la requête est reçue, désérialisée, puis mise en attente dans une file de requêtes à traiter par le processus cible P0. Ainsi, le calcul du contenu de cet objet vide et sa mise à disposition sont demandés au processus cible appelé aussi processus sachant notamment lors de la création de la requête RPCO-a. Lorsque le contenu de l'objet vide est obtenu par le processus cible P0, le couple de résultat CRES comprenant le contenu CONT-01 et l'identifiant ID-01 de l'objet vide est mis à disposition. Le processus cible PO obtient le contenu CONT-01 de l'objet vide par calcul et est appelé processus sachant.

Le processus PO peut également stocker l'identifiant du processus P1 associé à l'identifiant 10 de l'objet vide afin de renvoyer le résultat au processus P1 par la réponse RO.

Le contenu CONT-01 peut lui-même contenir l'identifiant d'un autre objet vide dont le contenu sera calculé par un autre processus.

Une fois l'objet vide créé dans le processus P1, l'identifiant de cet objet peut être soit utilisé par le processus P1 soit passé en paramètre dans une requête RPC1-a au processus cible P2 comme indiqué sur la figure 3-1.

Lorsque le contenu de l'objet vide est connu du processus Pl, celui-ci met à jour l'objet vide 2 0 en intégrant le contenu dans la structure de l'objet vide.

La figure 3-2 illustre plus en détail les modules aptes à travailler en relation avec le processus P1.

La station comprend les composants suivants: - un détecteur, par exemple un sérialisateur ST1-20, en relation avec le processus P1 et propre à détecter l'événement qu'un identifiant d'objet vide intervient comme paramètre d'une requête ou d'une réponse à envoyer par le processus local P1 à un autre processus P2 distant, 3 0 - un module de mise à jour ST1-16 apte, à partir de l'identifiant d'un objet vide et du contenu déterminé de cet objet vide, à intégrer ce contenu à la structure de l'objet vide, et ainsi mettre à jour l'objet vide - un moniteur ST1-12 en liaison avec le détecteur ST1-20 et le processus local P1 et propre, en réponse à la détection du détecteur, à intercepter l'envoi, à traiter l'objet vide en vue de mettre à disposition le contenu de cet objet au processus distant et à poursuivre l'envoi de la requête ou de la réponse sur une condition de traitement satisfaite.

Le traitement de l'objet vide, qui sera développé plus loin, comprend soit - l'attente du contenu et l'arrêt de l'exécution de l'évênement durant cette attente, la condition de traitement satisfaite correspondant à la réception du contenu ou la mise à jour de l'objet vide par l'intégration de son contenu une fois obtenu, - le stockage de données qui identifient l'objet vide et un processus auquel le contenu de l'objet vide doit être acheminé, l'exécution de l'évênement étant alors poursuivie sans que le contenu de l'objet vide ne soit connu, - le fait de continuer l'exécution de l'évênement.

Dans le cas d'une utilisation d'un identifiant d'objet vide par le processus P1, la détection de cet utilisation est automatiquement réalisée car l'accès à cet objet vide est bloquée de part la sémantique du langage objet. Il sera développé plus loin le traitement réservé après la détection d'une telle utilisation.

2 0 Le moniteur comprend un ensemble de processus appelés processus d'intervention qui sont exécutés selon que le processus est un processus source ou sachant, un processus sachant étant celui qui calcule le contenu d'un objet vide. Le moniteur comprend un processus dit d'attente par nécessité, un processus dit associé à l'envoi de requête/résultat, un processus dit de continuation automatique. L'exécution de ce dernier processus peut être effectuée parallèlement et indépendamment des autres processus. Ce processus de continuation automatique a pour fonction d'acheminer les contenus déterminés d'objets vides vers tous les processus susceptibles d'en avoir besoin.

Le moniteur travaille par ailleurs avec au moins une table dite Table de Contenus à Retransmettre TCR indiquant l'identifiant d'objets vides et l'identifiant d'un processus. Cette table sert à la transmission du contenu de l'objet vide au processus identifié. Un telle table sera utilisée soit dans le processus sachant soit dans tous les processus ayant transmis un identifiant d'objet vide, par exemple un processus source, en fonction du mode de réalisation de l'invention comme développé ci-après.

Dans le cas de la requête RPCO-a de la figure 3-1 par exemple, le processus PO ajoute dans 5 sa Table de Contenus à Retransmettre TCRO le couple comprenant l'identifiant ID-01 de l'objet vide et l'identifiant IDP1 du processus source auquel le contenu de l'objet vide doit être envoyé.

Les fonctions de ces différents composants sont détaillés dans la description des organigram-10 mes des figures 4 à 12 ci-après. La description sera faite en parallèle avec la figure 3-1.

Pour les modes de réalisations des figures 4 à 9, on se place sur la figure 3-1 dans le cas où le processus P1 a envoyé une requête RPCO-a au processus sachant PO et cherche à envoyer au processus P2 une requête RPC1-a comprenant l'identifiant ID-01 de l'objet vide ou dans le cas où le processus P1 a reçu un identifiant d'objet vide ID-01 créé par un autre processus du réseau.

La figure 4 illustre la sérialisation d'une requête ou d'une réponse avant son envoi. A l'étape 702, un premier objet parmi les paramètre de la requête ou de la réponse à envoyer est 2 0 sérialisé. Le mécanisme de la sérialisation, qui permet l'envoi de la requête ou de la réponse après copie de celle-ci, comprend notamment une détection d'un objet vide. A cette détection est ajoutée une gestion de cet objet vide grâce à l'appel d'un procédé associé à l'envoi d'un message selon la figure 5 ou la figure 7 par exemple. Si, à l'étape 704, les paramètres de la requête ou de la réponse comprennent d'autres objets, ceux-ci sont également sérialisés par appel récursif du procédé de la figure 5 ou de la figure 7 avant l'envoi de la requête ou de la réponse.

Les figures 5 et 6 illustrent un premier mode de réalisation du moniteur selon l'invention. Ce mode de réalisation s'applique lors de l'envoi d'objets vides par un processus source à 3 0 travers les paramètres d'une requête ou d'une réponse. Ce mode peut être nommé "Attente sur tentative de transmission".

Lors de la sérialisation de la requête ou de la réponse selon la figure 4, la figure 5 propose un procédé associé à l'envoi d'un message (requête ou réponse) selon un premier mode de réalisation. A titre d'exemple, ce message peut être le message RPC1-a de la figure 3-1 ayant pour paramètre un identifiant d'objet vide ID-01 et envoyé par le processus P1 au processus P2. Dans le message, la structure d'un premier objet est parcourue à l'étape 206. Si la structure de l'objet comprend un contenu connu à l'étape 208, le mécanisme de sérialisation de l'étape 704 de la figure 4 continue. Si la structure de l'objet n'a pas de contenu entièrement connu, par exemple l'objet comprend un drapeau (flag) indiquant que l'objet est vide comme dans le cas de RPC1-a, l'objet est détecté comme un objet vide à l'étape 210.

L'envoi de la requête ou de la réponse est alors suspendu à l'étape 212 et ceci tant que l'objet vide n'est pas mis à jour dans le processus source Pl à l'étape 214. Le procédé retourne à l'étape 704 de la figure 4 pour sérialiser un autre objet de la requête ou de la réponse. Une fois que tous les objets de la requête ou de la réponse ont été sérialisés, l'envoi du message est poursuivi, par exemple l'envoi du message RPC1-a du processus P1 au processus P2.

Dans cette réalisation, le moniteur du processus P1 est apte à attendre la réception d'un message envoyé par le processus sachant, le message comprenant le contenu et l'identifiant de l'objet vide, ladite réception étant la condition de traitement satisfaite.

2 0 La figure 6 illustre un procédé de continuation automatique selon le premier mode de réalisation de l'invention. Sur la figure 3-1, on se place dans le cas du processus source P1 ayant envoyé une requête RPCO-a à un processus sachant PO pour connaître le contenu d'un identifiant d'objet vide ID-01. Lorsque le processus sachant PO se charge de la requête, il vérifie si le contenu de l'objet vide identifié par ID-01 est disponible. Dès que celui-ci est 2 5 disponible à l'étape 220, il est recherché dans la table TCRO du processus sachant P0, l'identifiant du processus source associé à l'identifiant ID-01 de l'objet vide. Ainsi, le contenu et l'identifiant de l'objet vide sont envoyés au processus source P1. Les données de la table TCRO sont effacées au fur et à mesure que le contenu des objet vide est envoyé aux processus répertoriés dans cette table.

Une fois que ce résultat est reçu par le processus P1, son module de mise à jour met à jour l'objet vide en intégrant le contenu dans la structure de l'objet avant de poursuivre l'envoi de la requête RPC1-a au processus P2 comme indiqué par les procédés des figures 4 et 5.

Pour chaque objet de la requête ou de la réponse, la figure 7 propose une deuxième et une troisième réalisation du procédé associé à l'envoi d'un message (requête ou réponse). La deuxième réalisation peut être intitulée "Transmission des résultats par les processus transmetteurs d'objets vides" et la troisième réalisation peut être intitulée " Passage avec ordre de retransmission par les processus transmetteurs d'objets vides". On se place dans le cas du message RPC1-a comprenant un identifiant d'objet vide ID-01 et envoyé du processus Pl au processus P2. La structure d'un objet du message est parcouru à l'étape 706 par le sérialisateur du processus Pl. Si la structure de l'objet comprend un contenu connu à l'étape 708, le mécanisme de sérialisation de l'étape 704 de la figure 7 continue. Si la structure de l'objet n'a pas de contenu connu ou a un contenu partiellement connu, par exemple l'objet comprend un drapeau (flag) indiquant que l'objet est vide, l'objet est détecté comme un objet vide à l'étape 710. On parle alors d'interception de l'envoi dans le cas d'un envoi d'une requête ou d'une réponse. L'objet vide est alors traité à l'étape 712 par le moniteur ST1-12. Ce traitement comprend plusieurs possibilités selon la réalisation du procédé - soit, à l'étape 712-2, le stockage dans une table ou une liste locale appelée Table des Contenus à Retransmettre TCR, par exemple TRC1 lié au processus P1, de l'identifiant de l'objet vide et de l'identifiant du processus de destination, par exemple ID-P2, auquel le contenu de cet objet doit être envoyé, - soit, à l'étape 712-3, à partir de l'identifiant de l'objet vide, par exemple ID-01, l'extraction 2 0 de l'identifiant du processus sachant, par exemple PO (appelé sachant) , propre à calculer le contenu de cet objet vide et l'ajout dans la table TCR du processus sachant, par exemple TCRO du processus P0, de l'identifiant de l'objet vide et de l'identifiant du processus de destination auquel le contenu de cet objet doit être envoyé. Cet ajout peut se réaliser après l'envoi d'un message du processus source au processus sachant, par exemple du processus 2 5 P1 au processus P0, demandant au processus sachant de transmettre le contenu de l'objet au processus de destination, par exemple P2.

Dans le cas de l'étape 712-2, la Table des Contenus à Retransmettre TCR du processus source P1 contient les couples d'identifiants d'objets vides ID-OBJ-VID associés aux identifiants de processus cibles ID-P auxquels le contenu d'au moins un objet vide doit être retransmis. Le moniteur ST1-12 ajoute le couple (ID-P2, ID-01) à la table TCR1 du processus source Pl. Cet ajout correspond à une condition de traitement satisfaite, ce qui déclenche l'envoi de la requête RPC1 au processus cible P2.

Dans le cas de l'étape 712-3, l'identifiant du processus sachant PO est extrait de l'identifiant de l'objet vide ID-01. Le couple (ID-01, ID-P2) est ajouté dans la Table des Contenus à Retransmettre TCRO du processus sachant P0. Pour cela, le processus source P1 peut envoyer un message au processus sachant PO demandant la retransmission du résultat comprenant l'identifiant et le contenu de l'objet vide au processus cible P2. Sur une condition de traitement satisfaite qui peut être l'extraction de l'identifiant du processus sachant pour un objet vide donné, l'envoi du message demandant la retransmission, l'ajout dans la table TCRO du couple (ID-01, ID-P2), le processus source P1 envoie la requête RPC1 au processus cible P2.

Au moment de l'extraction de l'identifiant du processus sachant P0, le processus source P1 peut informer le processus cible P2 de l'identifiant du processus sachant PO si celui-ci n'a pas de procédé d'extraction. Ainsi, si l'identifiant de l'objet vide est utilisé comme paramètre d'une requête par le processus P2, ce dernier pourra demander au processus sachant la transmission directe du contenu de l'objet vide au prochain processus cible.

La figure 8 illustre un deuxième mode de réalisation du procédé de continuation automatique lié au procédé associé à l'envoi d'un message réalisant le traitement de l'étape 712-2 de la figure 7.

Ce procédé est effectué pour chaque processus Px, x étant un entier pouvant désigner le processus sachant PO et tout processus ayant retransmis l'objet vide ID-01, c'est-à-dire un processus P1, P2.

2 5 A l'étape 412, le moniteur du processus Px est en phase d'attente de disponibilité du résultat comprenant l'identifiant et le contenu de l'objet vide (ID-01, CONT-01). Une fois que ce résultat est disponible dans le processus Px, le module de mise à jour de ce dernier met à jour l'objet en intégrant le contenu à la structure de l'objet et envoie par un message (par exemple le message R1 entre le processus P1 et le processus P2 sur la figure 3-1) cet objet mis à jour à tous les processus cibles c'est-à-dire les processus dont les identifiants ID-P dans la table TCRxsont associés à l'identifiant de l'objet vide ID-01 à l'étape 414. Ainsi, à l'étape 416, le résultat devient disponible dans tous les processus cibles.

De manière itérative, les processus cibles ayant retransmis l'objet vide attendent le résultat à l'étape 412, c'est-à-dire l'objet vide mis à jour. Dès que ces processus cibles reçoivent ce résultat, ils deviennent processus sources en effectuant l'étape 414, c'est-à-dire qu'ils retransmettent par un message l'objet vide mis à jour à tous les processus cibles de leur table TCR dont les identifiants ID-P sont associés à l'identifiant de l'objet vide ID-01. Cette itération s'effectue jusqu'à ce que tous les processus ayant retransmis l'objet vide reçoivent l'objet mis à jour.

Le procédé est d'abord effectué par le processus sachant puis, de manière itérative, par tout processus ayant retransmis l'objet vide et recevant l'objet mis à jour.

Ainsi, ce mode de réalisation permet la retransmission du contenu de l'objet vide par un processus source au processus cible dès que le contenu est disponible dans le processus source et que la mise à jour de l'objet vide a été réalisée par le processus source. Cette retransmission peut se faire de manière itérative et par une communication de type RPC synchrone.

La figure 9 illustre un troisième mode de réalisation du procédé de continuation automatique lié au procédé associé à l'envoi d'un message réalisant le traitement de l'étape 712-3 de la 2 0 figure 7.

Sur la figure 9, à l'étape 612, le moniteur du processus sachant PO est en phase d'attente de mise à disposition du résultat de la requête RPCO-a. Ce résultat comprend l'identifiant et le contenu de l'objet vide (ID-01, CONT-01). Une fois que ce résultat est disponible dans le processus sachant P0, le module de mise à jour de ce dernier met à jour l'objet vide en intégrant le contenu à la structure de l'objet et le moniteur envoie cet objet mis à jour par un message R2 à tous les processus cibles c'est-à-dire à tous les processus dont les identifiants ID-P dans la table TCRO sont associés à l'identifiant de l'objet vide ID-01 à l'étape 614. Ainsi, à l'étape 616, l'objet mis à jour devient disponible localement dans tous ces processus 3 0 cibles.

Dans ce mode de réalisation de l'invention, le moniteur de la station informatique du processus local est propre, après exécution de l'envoi de la requête ou de la réponse et une fois le contenu de l'objet vide disponible dans le processus local, à envoyer l'identifiant de l'objet vide associé à son contenu aux processus dont les identifiants dans la table sont associés à l'identifiant de l'objet vide.

Les figures 10, 11 et 12 illustrent un quatrième mode de réalisation de l'invention qui s'applique à la détection de l'utilisation d'un objet vide par le processus P1 à titre d'exemple. Dans ce mode de réalisation, le procédé associé à l'envoi d'un message (requête ou réponse) ne nécessite pas de traitement particulier et l'envoi est effectué en présence ou non d'objet vide détecté.

La figure 10 illustre un procédé d'attente par nécessité selon le quatrième mode de réalisation de l'invention. A l'étape 702, l'utilisation par un processus P1 d'un objet vide identifié par ID-01 est détecté. A l'étape 704, l'exécution du processus P1 est suspendu. A l'étape 706, le moniteur du processus P1 extrait à partir de l'identifiant ID-01 de l'objet vide, l'identifiant du processus sachant ID-PO apte à calculer et à mettre à disposition le contenu de l'objet vide. A l'étape 708, le moniteur du processus P1 émet au processus sachant PO un premier message Transmettre(ID-01, ID-PI) avec l'identifiant ID-01 de l'objet vide et l'identifiant ID-P1 du processus P1. Ce message requiert, une fois le contenu de l'objet vide mis à disposition, la transmission par le processus PO au processus P1 d'un second message 2 0 (ID-01, CONT-01) avec l'identifiant et le contenu de l'objet vide. A l'étape 710, le moniteur du processus P1 attend que l'objet vide soit mis à jour par le module de mise à jour du processus P1. Cette mise à jour de l'objet vide correspond à une condition de traitement satisfaite que le moniteur détecte pour poursuivre l'exécution de l'utilisation faite de l'objet identifié à l'étape 712.

Sur la figure 11 illustre le procédé de réception du premier message de l'étape 708 par le processus sachant P0. A l'étape 716, le moniteur du processus PO vérifie si le contenu CONT-01 de l'objet identifié ID-01 dans le premier message reçu existe dans la Table des Contenus Calculés TCC tenue par le processus sachant PO comme indiqué sur la figure 12.

3 0 Si c'est le cas, le moniteur récupère le contenu de l'objet vide et son identifiant dans la table TCC et, à l'étape 718, envoie un second message comprenant l'identifiant et le contenu de l'objet vide (ID-01, CONT-01) au processus Pl utilisant cet objet.

Si ce n'est pas le cas, à l'étape 717, le moniteur du processus PO ajoute, dans sa Table de Contenus à Retransmettre TCRO, le couple de données (IDPI, ID-01) qui a été passé en paramètres avec le premier message.

La figure 12 illustre un procédé de continuation automatique selon le quatrième mode de réalisation de l'invention. Ainsi, à l'étape 720, le moniteur de processus sachant PO attend que le résultat (ID-01, CONT-01) comprenant l'identifiant et le contenu de l'objet vide soit disponible. Une fois ce résultat disponible, il est ajouté dans la table TCC du processus sachant PO à l'étape 722 puis envoyé à tous les processus de la table TCRO de PO pour lesquels les identifiants sont associés à l'identifiant de l'objet vide. En d'autres termes, le processus PO calcule en une fois le contenu de l'objet vide puis envoie le couple identifiant-contenu de l'objet vide à tous les processus en attente de résultat grâce aux tables TCC et TCRO tenues en mémoire par le processus sachant P0.

Ainsi, le moniteur de la station informatique du processus sachant est propre à travailler avec une première table TCRO comprenant des couples de données associant des identifiants d'objets vides et des identifiants de processus et une seconde table TCC comprenant des couples de données associant des identifiants d'objets vides et les contenus de ces objets. Le moniteur de la station informatique du processus sachant est également propre, une fois 2 0 avoir ajouté dans la deuxième table l'identifiant de l'objet vide et son contenu calculé, à émettre un message comprenant l'identifiant et le contenu de l'objet vide au processus local après avoir vérifié que l'identifiant de l'objet vide est dans la seconde table et aux processus dont l'identifiant dans la première table est associé à l'identifiant de l'objet 25 vide, identifiants qui ont été ajoutés dans la première table sur un message du processus P1.

Cette réalisation du moniteur de l'invention utilisant les tables TCC et TCR permet une gestion globale des processus en attente d'un même contenu d'objet vide identifié pour l'utilisation de cet objet.

Bien qu'il soit fait mention de tables de données, le terme "table" peut tout aussi bien désigner une liste de données associées entre-elles et le terme "liste" peut tout aussi bien désigner une table de données.

Ainsi, ces mode de réalisation permettent la retransmission du contenu associé à un objet vide à tous les processus ayant un identifiant de cet objet vide dès que le contenu a été calculé par le processus sachant.

Les processus d'intervention des premier, deuxième et troisième modes de réalisation de l'invention sont accompagnés d'un processus assurant la cohérence de la mise à jour automatique du contenu de l'objet vide lorsque l'identifiant d'un objet vide est utilisé par le processus P dans une station, à savoir un processus d'attente par nécessité qui suspend l'exécution en cours et ne la reprend qu'une fois le contenu de l'objet vide connu.

Chaque station informatique comprend un processus local, un module de protocole et un moniteur de sorte que chaque processus local puisse être local, distant par rapport à un autre processus d'une autre station ou sachant pour le calcul du contenu d'un objet vide. Chaque station informatique peut comprendre un ou plusieurs processus locaux, chaque processus ayant un module de protocole et un moniteur.

L' invention n' est pas limitée aux mode de réalisation décrit ci-dessus mais s' étend à d'autres modes de réalisation. Ainsi, les procédés développés peuvent être utilisés alternativement ou en combinaison en fonction des performances souhaitées.

Claims (20)

Revendications

1. Procédé de gestion d'appel de méthodes à distance en langage orienté objet, par une communication asynchrone, entre un processus local d'une station et un processus distant d'une autre station, un tel appel comprenant une requête (RPC) de l'un des processus (P1; P2), suivie d'une réponse (R-A) de l'autre processus (P2; Pl), caractérisé en ce qu'il consiste, a- à détecter la transmission d'un objet vide comme paramètre d'une requête ou d'une réponse avant son envoi d'un processus local à un processus distant (210, 710), le calcul du contenu de cet objet vide et sa mise à disposition ayant été demandés à un processus sachant, b- à traiter l'objet vide en vue de mettre à disposition le contenu de cet objet (212,712) au processus distant, c- à poursuivre l'envoi de ladite requête ou de ladite réponse (108) sur une condition de traitement satisfaite.

2. Procédé selon la revendication 1, caractérisé en ce que le procédé consiste à a- détecter l'événement qu'un objet vide doit être utilisé par un processus local (702), et suspendre l'exécution de l'utilisation de l'objet vide par le processus local (704) b- b1- à extraire de l'objet vide comprenant un identifiant, l'identifiant du processus 2 0 sachant apte à calculer et mettre à disposition le contenu de l'objet vide (706), b2- à émettre au processus sachant un premier message ayant des premières données comprenant l'identifiant de l'objet vide et l'identifiant du processus local et requérant la transmission au processus local d'un second message ayant des secondes données comprenant le contenu et l'identifiant de l'objet vide (708), 2 5 c- à attendre la réception dudit second message par le processus local et une fois ce second message reçu, à mettre à jour l'objet vide et à continuer l'exécution de l'utilisation.

3. Procédé selon la revendication 2, caractérisé en ce que l'étape b2consiste en outre, b2-1 sur réception du premier message par le processus sachant, à vérifier si l'identifiant de l'objet vide est dans une seconde table comprenant des couples de données associant des identifiants d'objets vides et le contenu de ces objets(716), b2-2-i dans l'affirmative, à émettre au processus local le second message (718) b2-2ii dans la négative, 2862830 18 - à ajouter les premières données dans une première table comprenant des couples de données associant des identifiants d'objets vides et des identifiants de processus (717).

4. Procédé selon la revendication 3, caractérisé en ce que l'étape b2-2ii consiste en outre, une fois le contenu de l'objet vide mis à disposition (720), - à ajouter les secondes données dans la seconde table (722), - à émettre le second message aux processus dont les identifiants dans la première table sont associés à l'identifiant de l'objet vide (724).

5. Procédé selon la revendication 1, caractérisé en ce que l'étape bconsiste en outre, par le processus local, à attendre la réception d'un message envoyé par le processus sachant (212), le message comprenant le contenu et l'identifiant de l'objet vide, et sur réception dudit message, à continuer à l'étape c avec l'objet vide mis à jour.

6. Procédé selon la revendication 1, caractérisé en ce que l'étape bconsiste en outre, par le processus local, à ajouter l'identifiant de l'objet vide associé à l'identifiant du processus distant dans une table comprenant des couples de données associant des identifiants d'objets vides et des identifiants de processus (712-2) et à continuer à l'étape c.

7. Procédé selon la revendication 6, caractérisé en ce que l'étape c. consiste, une fois l'envoi exécuté, à cl- attendre que le contenu de l'objet vide est disponible dans le processus local (412), c2- une fois le contenu disponible, envoyer le contenu et l'identifiant de l'objet vide aux processus dont les identifiants dans ladite table sont associés à l'identifiant de l'objet vide (414).

8. Procédé selon la revendication 1, caractérisé en ce que l'étape bconsiste en outre, par le processus local, 3 0 bl- à extraire de l'objet vide comprenant un identifiant, l'identifiant du processus sachant apte à calculer et à mettre à disposition le contenu de l'objet vide, b2- à émettre au processus sachant un premier message ayant des premières données comprenant l'identifiant de l'objet vide associé à l'identifiant du processus distant, ce message requérant que le processus sachant transmette au processus distant un second message ayant des secondes données comprenant l'identifiant de l'objet vide associé à son contenu (712-3).

9. Procédé selon la revendication 8, caractérisé en ce que l'étape c consiste également, par le processus sachant et sur réception du premier message, à cl- à ajouter les premières données dans une table comprenant des couples de données associant des identifiants d'objets vides et des identifiants de processus (712-3).

10. Procédé selon l'une des revendications 8 et 9, caractérisé en ce que l'étape c consiste de plus, par le processus local et après l'envoi exécuté, à cl- attendre que le contenu de l'objet vide est disponible dans le processus local (612), d2- une fois le contenu disponible, envoyer l'identifiant de l'objet vide associé à son contenu aux processus dont les identifiants dans ladite table sont associés à l'identifiant de l'objet vide (614).

11. Station informatique, comprenant - un environnement (ST1-2, ST1-4, ST1-6), capable d'exécuter un ou des processus locaux (P1) en langage orienté-objet, 2 0 - un module de protocole (ST1-6), capable de traiter, par une communication asynchrone, des appels de méthodes à distance (RPC) entre un processus local (P1) et un processus distant (P2) d'une autre station, un tel appel (RPC) comprenant une requête (A) de l'un des processus (P1; P2), suivie d'une réponse (R-A) de l'autre processus (P2; P1), caractérisée en ce qu'elle comprend: 2 5 un moniteur(ST1-12) apte, sur une détection de l'événement qu'un objet vide intervient comme paramètre d'une requête ou d'une réponse à envoyer par le processus local (P1) au processus distant (P2), le calcul du contenu de cet objet vide et sa mise à disposition ayant été demandés à un processus sachant, à traiter l'objet vide en vue de mettre à disposition le contenu de cet objet au 3 0 processus distant, poursuivre l'envoi de la requête ou de la réponse sur une condition de traitement satisfaite.

12. Station informatique selon la revendication 11, caractérisé en ce que le moniteur(ST1-12) est en outre apte, sur une détection de l'événement qu'un objet vide doit être utilisé par le processus local, - à extraire de l'objet vide comprenant un identifiant, l'identifiant d'un processus sachant apte à calculer et mettre à disposition le contenu de l'objet vide, - à émettre au processus sachant un premier message ayant des premières données comprenant l'identifiant de l'objet vide et l'identifiant du processus local et requérant la transmission au processus local d'un second message ayant des secondes données comprenant le contenu et l'identifiant de l'objet vide, - à attendre la réception dudit second message par le processus local, ladite réception étant la condition de traitement satisfaite.

13. Station informatique selon la revendication 12, caractérisé en ce que le moniteur(ST1-12) de la station informatique du processus sachant étant propre - à travailler avec une première table comprenant des couples de données associant des identifiants d'objets vides et des identifiants de processus et une seconde table comprenant des couples de données associant des identifiants d'objets vides et les contenus de ces objets, - à émettre le second message au processus local après avoir vérifié que l'identifiant de l'objet vide du premier 2 0 message est dans la seconde table aux processus dont l'identifiant dans la première table est associé à l'identifiant de l'objet vide après avoir ajouté les premières données dans la première table et une fois avoir ajouté les secondes données dans la seconde table après calcul du contenu de l'objet vide.

14. Station informatique selon la revendication 11, caractérisé en ce que le moniteur(ST1-12) est apte à attendre la réception d'un message envoyé par le processus sachant, le message comprenant le contenu et l'identifiant de l'objet vide, ladite réception étant la condition de traitement satisfaite.

15. Station informatique selon la revendication 11, caractérisé en ce que le moniteur(ST1-12) est apte à ajouter l'identifiant de l'objet vide associé à l'identifiant du processus distant dans une table comprenant des couples de données associant des identifiants d'objets vides et des identifiants de processus, cet ajout étant la condition de traitement satisfaite.

16. Station informatique selon la revendication 15, caractérisé en ce qu'une fois le contenu de l'objet vide disponible dans le processus local, le moniteur(ST1-12) est propre à transmettre l'identifiant et le contenu de l'objet vide à des processus dont les identifiants dans ladite table sont associés à l'identifiant de l'objet vide.

17. Station informatique selon la revendication 11, caractérisé en ce que le moniteur(ST1-12) 10 est apte à - à extraire de l'objet vide comprenant un identifiant, l'identifiant d'un processus sachant apte à calculer et à mettre à disposition le contenu de l'objet vide, - à émettre au processus sachant un premier message ayant des premières données comprenant l'identifiant de l'objet vide associé à l'identifiant du processus distant, ce premier message requérant la transmission au processus distant d'un second message ayant des secondes données comprenant le contenu et l'identifiant de l'objet vide, l'émission du premier message étant la condition de traitement satisfaite.

18. Station informatique selon la revendication 17, caractérisé en ce que le moniteur(ST1-12) 2 0 de la station informatique du processus sachant étant propre, sur réception du premier message, - à ajouter les premières données dans une table comprenant des couples de données associant des identifiants d'objets vides et des identifiants de processus.

19. Station informatique selon l'une des revendications 17 et 18, caractérisé en ce que le moniteur de la station informatique du processus local est propre, après exécution de l'envoi de la requête ou de la réponse et une fois le contenu de l'objet vide disponible dans le processus local, à envoyer l'identifiant de l'objet vide associé à son contenu aux processus dont les identifiants dans la table sont associés à l'identifiant de l'objet vide (614).

20. Réseau de stations informatiques selon l'une des revendications 11 à 19, chaque station informatique comprenant un processus local, un module de protocole et un moniteur de sorte que chaque processus local puisse être local, distant par rapport à un autre processus d'une autre station ou sachant pour le calcul du contenu d'un objet vide.