Note: Descriptions are shown in the official language in which they were submitted.
CA 02546888 2006-05-19
WO 2005/055060 PCT/FR2004/003005
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 Procédure 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
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
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,
CA 02546888 2009-05-15
2
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,
. poursuivre l'envoi de la requête ou de la réponse sur une condition de
traitement
satisfaite.
L'invention, telle que revendiquée, concerne plus particulièrement un procédé
de
gestion d'appel de méthodes à distance en langage orienté objet, par une
communication asynchrone avec retour de résultats, 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, suivi d'une réponse de l'autre processus,
caractérisé en ce qu'il consiste,
a- à détecter la transmission d'un objet vide comme paramètre d'une requête
CA 02546888 2009-05-15
2a
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 lorsque le contenu de l'objet vide est connu du processus
local, le processus local mettant à jour l'objet vide en intégrant le contenu
dans la
structure de l'objet vide,
c- à poursuivre l'envoi de ladite requête ou de ladite réponse sur une
condition de traitement satisfaite, en se servant d'une représentation de la
réponse.
L'invention revendiquée concerne également une station informatique,
comprenant
un environnement, capable d'exécuter un ou des processus locaux en langage
orienté-objet, caractérisée en ce qu'elle comprend-
- un module de protocole, capable de traiter, par une communication
asynchrone avec retour de résultats, 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, et
- 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, lorsque le contenu de l'objet vide est connu du processus
local,
le processus local mettant à jour l'objet vide en intégrant le contenu dans la
structure de l'objet vide.
. poursuivre l'envoi de la requête ou de la réponse sur une condition de
traitement satisfaite, en se servant d'une représentation de la réponse.
CA 02546888 2009-05-15
2b
De plus, l'invention concerne un réseau de stations informatiques caractérisé
en ce
que chaque station informatique est telle que définie ci-dessus, chaque
station
informatique comprenant un processus local, le module de protocole et le
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.
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 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,
CA 02546888 2006-05-19
WO 2005/055060 PCT/FR2004/003005
3
- 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
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
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
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
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.
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.
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
CA 02546888 2006-05-19
WO 2005/055060 PCT/FR2004/003005
4
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 STl-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 P1 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
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
CA 02546888 2006-05-19
WO 2005/055060 PCT/FR2004/003005
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
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
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
CA 02546888 2006-05-19
WO 2005/055060 PCT/FR2004/003005
6
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
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.
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
CA 02546888 2006-05-19
WO 2005/055060 PCT/FR2004/003005
7
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
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 P1, celui-ci met à
jour l'objet vide
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,
- 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
CA 02546888 2006-05-19
WO 2005/055060 PCT/FR2004/003005
8
- 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.
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
CA 02546888 2006-05-19
WO 2005/055060 PCT/FR2004/003005
9
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
sa Table de Contenus à Retransmettre TCRO le couple comprenant l'identifiant
ID-01 de
l'objet vide et l'identifiant ID-P1 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-
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
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 à
travers les paramètres d'une requête ou d'une réponse. Ce mode peut être nommé
"Attente
sur tentative de transmission".
CA 02546888 2006-05-19
WO 2005/055060 PCT/FR2004/003005
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
5 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.
10 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 P1 à 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.
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
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.
CA 02546888 2006-05-19
WO 2005/055060 PCT/FR2004/003005
11
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
P1 au processus P2. La structure d'un objet du message est parcouru à l'étape
706 par le
sérialisateur du processus P1. 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
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
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 P1. Cet ajout correspond à une condition de traitement
satisfaite, ce qui
déclenche l'envoi de la requête RPC1 au processus cible P2.
CA 02546888 2006-05-19
WO 2005/055060 PCT/FR2004/003005
12
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.
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
TCRx sont 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.
CA 02546888 2006-05-19
WO 2005/055060 PCT/FR2004/003005
13
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
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 à j our devient disponible localement dans
tous ces processus
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
CA 02546888 2006-05-19
WO 2005/055060 PCT/FR2004/003005
14
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
(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.
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 P1 utilisant cet objet.
CA 02546888 2006-05-19
WO 2005/055060 PCT/FR2004/003005
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 (ID-Pl, ID-01) qui a été
passé en
paramètres avec le premier message.
5 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
10 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.
15 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
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
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.
CA 02546888 2006-05-19
WO 2005/055060 PCT/FR2004/003005
16
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.
