Note: Descriptions are shown in the official language in which they were submitted.
~~ )~~3~~
1
Procédé de simulation d'une architecture "serveur" à partir d'une
architecture "client".
La présente invention concerne un procédé de simulation) dans un réseau)
s d'une architecture "serveur" à partir d'une architecture "client" d'une
première machine pour l'exécution d'appels de procédure à distance RPC
(Remote Procedure Call) émis par au moins une seconde machine
d'architecture "client".
io De manière générale) le service d'appels de procédure à distance RPC
fournit un langage de niveau élevé et permet aux programmes exécutés
localement d'appeler des procédures installées sur des systèmes à
distance. Ce service constitue un élément fondamental du modèle "client-
serveur". Ce modèle est un modèle informatique asymétrique constitué de
is deux unités séparées et logiques travaillant en coopération. Une machine
d'architecture "client", communément appelée "client", demande des
informations ou des actions qu'une machine d'architecture "serveur" peut
exécuter plus spécifiquement ou dans de meilleures conditions. La machine
d'architecture "serveur") communément appelée "serveur", répond aux
Zo demandes du "client" et exécute des tâches lourdes ou spécialisées.
Dans ce contexte) il peut étre ressenti le besoin d'utiliser une machine
d'architecture exclusivement "client" comme "serveur". La solution à ce
problème consistait) jusqu'à présent) à porter une partie "serveur" sur la
Zs machine "client", c'est-à-dire à reproduire l'intégralité du code source
d'une
partie "serveur". Une telle solution est longue et fastidieuse et par
conséquent co0teuse et ceci d'autant plus que plusieurs versions peuvent
se succéder à brève échéance et que de plus le code peut étre malaisé à
porter sur des systèmes propriétaires.
La présente invention a pour but de remédier aux inconvénients précités et
propose un procédé de simulation d'une architecture "serveur" à partir
d'une architecture "client" qui ne nécessite pas une recopie d'une partie
"serveur" et qui par conséquent est peu onéreux et rapide à mettre en
3s oeuvre.
Pour cela le procédé de simulation mentionné dans le préambule est
remarquable en ce que la première machine émet préalablement un appel
213~~?(~
2
RPC vers une troisième machine d'architecture "serveur" utilisée entre la
première et la deuxième machines et pour cela appelée machine relais, cet
appel RPC ouvrant un contexte de communication (appelé "client context"
par l'homme du métier dans un environnement d'information répartie et
s selon la sémantique de DCE, DCE (Distributed Computing Environment)
étant une marque déposée par Open Software Foundation) pour la suite
des échanges alors que ladite première machine se bloque sur ledit appel
dans l'attente de son retour, puis lorsque la seconde machine émet un
appel RPC représentatif d'une fonction déterminée à exécuter par la
io première machine) cet appel est transmis vers la machine relais qui après
reconnaissance de la fonction à exécuter fe retransmet vers la première
machine par retour de l'appel RPC bloqué, la première machine demandant
alors les paramètres d'entrée de la fonction à exécuter présents dans la
machine relais puis exécutant ladite fonction après réception desdits
is paramètres d'entrée et enfin fournissant, comme paramètre de sortie, le
résultat à la seconde machine via la machine relais.
Ainsi grâce au procédé de simulation selon l'invention, dans un réseau, une
machine "client" peut lancer des appels de procédure RPC vers une autre
Zo machine "client" utilisée comme "serveur' ("pseudo-serveur' et ceci sans
modification ou recopie du code source d'une partie "serveur"; le code
"client" est standard, il suffit pour cela de sélectionner un "serveur" du
réseau qui servira alors de machine relais et autorisera le dialogue entre la
machine "client" et fe "pseudo-serveur". En effet, ta machine "client" voit
Zs alors le couple "senreur"P'pseudo-serveur" comme une machine "serveur"
homogène. Dans ces conditions tout appel RPC avec tout type de
paramètre peut être exécuté. En outre, de manière générale fintertace de
la procédure est décrite dans un langage de description d'intertace (IDL).
Cette interface est compilée en deux talons (appelés "stubs" par l'homme
3o du métier), un pour le cSté "client", l'autre pour le c8té "serveur" du
RPC,
les talons étant compilés avec les programmes "client" et "serveur"
respectivement pour donner les deux exécutables "client" et "serveur". Le
talon "client" est une fonction dont l'interface respecte fintertace décrite
en
IDL et qui a pour but de transformer les paramètres d'appel de la
ss représentation propre à la machine "client" en une représentation
universelle dite représentation de réseau. Le but du talon "serveur" est de
transformer les paramètres d'appel de la représentation réseau en la
représentation propre à la machine senneur et d'appeler ensuite la fonction
213720
3
effectivement demandée. Selon l'invention, le fonctionnement est
automatique et conforme à la représentation réseau, toutes les conversions
étant réalisées au niveau du NDR (Network Data Representation). Les
talons, qui sont générés par le langage de description de l'interface, sont
s donc standards. De plus) en ce qui concerne les services de sécurité, les
mécanismes de protection éventuels sont également standards.
De manière remarquable, selon le présent procédé de simulation, les
étapes suivantes sont chronologiquement parcourues
io
- la première machine émet vers une première unité d'exécution de la
machine relais un appel RPC (1 ) signifiant qu'elle est préte pour l'exécution
de fonctions, l'unité d'exécution de la machine relais qui gère cet appel
RPC (1 ) se met alors en attente d'un signal de réveil et bloque ainsi la
~s première machine sur cet appel RPC (1))
- la machine relais informe le service de nommage que la première
machine est préte à exécuter une fonction désirée,
zo - la seconde machine va chercher dans un répertoire du service de
nommage l'adresse de la fonction à exécuter,
- la seconde machine émet alors un appel RPC (2), conforme à la
représentation réseau, correspondant à la fonction à exécuter et
Zs comportant les paramètres d'entrée et de sortie de ladite fonction, vers
une
seconde unité d'exécution de la machine relais, cette unité d'exécution se
mettant en attente d'un signal de réveil et bloquant ainsi la seconde
machine sur cet appel RPC(2) après avoir elle-méme émis un signal de
réveil vers la première unité d'exécution en attente,
- la première machine est renseignée, par retour de l'appel RPC(1 ) ainsi
débloqué, sur le type de fonction à exécuter,
- la première machine émet un nouvel appel RPC(3), vers la première unité
3s d'exécution de la machine relais, pour demander les paramètres d'entrée
de la fonction à exécuter, cette unité d'exécution demandant lesdits
paramètres à la seconde unité d'exécution de la machine relais via un
mécanisme de communication interprocessus ("sockets", mémoire
~137~2U
4
partagée avec sémaphores, files de messages, tube de communication
appelé également "pipe",...) ou intraprocessus (mémoire globale protégée
par des verrous par exemple).
s - après obtention des paramètres d'entrée de la fonction à exécuter, la
première unité d'exécution de la machine relais transmet lesdits
paramètres, par retour de l'appel RPC(3), à la première machine qui
exécute la fonction,
io - la première machine transmet le résultat de la fonction exécutée à la
première unité d'exécution de la machine relais qui d'une part le
communique à la seconde unité d'exécution via un mécanisme de
communication interprocessus ("sockets", mémoire partagée avec
sémaphores, files de messages, tube de communication appelé également
~s "pipe",...) ou intraprocessus (mémoire globale protégée par des verrous par
exemple) et d'autre part émet un signal de réveil vers cette seconde unité
d'exécution,
- la seconde unité d'exécution de la machine relais, par retour de l'appel
ao RPC (2) ainsi débloqué, transmet comme paramètre de sortie ie résultat
de la fonction exécutée vers la seconde machine.
De cette manière, le procédé selon l'invention peut s'appliquer à l'évidence
à une pluralité de machines "client" émettant des appels RPC vers un
Zs "pseudo-serveur", chaque machine "client" voyant le couple
"serveur"~'pseudo-serveur" comme une machine "serveur". Le dialogue
entre la machine "client" et le "pseudo-serveur" est alors autorisé par
l'intermédiaire de différentes unités d'exécution de la machine relais.
3o La description suivante en regard du dessin annexé, le tout donné à titre
d'exemple non limitatif, fera bien comprendre comment l'invention peut être
réalisée.
La figure unique présente de manière schématique, un exemple de
3s dialogue élaboré dans un réseau autour d'appels RPC) entre une première
machine "client" utilisée en "serveur" et une seconde machine "client" par
l'intermédiaire d'une troisième machine "serveur" utilisée comme relais.
21a7~20
Sur la figure, une première machine PS d'architecture uniquement "client"
est désirée étre utilisée comme "serveur RPC" ("pseudo-serveur"} par une
seconde machine CL d'architecture "client". Conformément à l'idée de
l'invention, les différents appels RPC sont émis d'abord vers une troisième
s machine RE dite machine relais, cette machine ayant une architecture
"serveur".
De préférence, les machines PS, RE) CL sont des machines de type DCE
(DCE est une marque déposée par Open Software Fou~dation).
io
De méme) de manière préférée mais non limitative, les appels de
procédure à distance sont de type standard DCEIRPC. II est cependant
rappelé qu'avantageusement tout type d'appel RPC avec tout autre type de
paramètre peut étre utilisé selon le présent procédé et par exemple un
is RPC selon la technologie de Sun Microsystems) un RPC NCS 1.5
ApoIlo/Hewlett.Packard (NCS : Network Computing System), un RPC selon
Netwise, etc...).
Pour une meilleure appréhension du procédé selon l'invention) un exemple
2o simple est ci-après décrit. Dans cet exemple la machine CL demande à la
machine PS d'exécuter une fonction d'addition en prenant comme
paramètres d'entrée) les paramètres a et b à additionner et comme
paramètre de sortie, le paramètre c représentant le résultat de l'addition a
et b.
2s
Selon le présent procédé de simulation) dans cet exemple précis)
différentes étapes seront parcourues avant d'aboutir au résultat c.
Ainsi, à l'étape 1, la première machine PS émet vers une premiére unité
so d'exécution TH1 de la machine relais RE, un appel RPC 1 (représenté par
une flèche en trait plein)) par exemple du type "I am ready(f nb)",
signifiant qu'elle est prête pour l'exécution de fonctions (dont la fonction
"add"). L'unité d'exécution TH1 de la machine RE qui reçoit et va donc
gérer cet appel RPC1, se met alors en attente d'un signal de réveil qui peut
3s être une variable de condition du type (pthread_cond_wait
(tond var work)), ce qui a pour effet de bloquer la première machine PS
sur l'appel RPC 1.
21~7~~0
6
Lors d'une seconde étape 2, la machine relais RE informe le service de
nommage NS que la première machine PS est préte à exécuter la fonction
désirée par la seconde machine CL, en l'occurrence ce sera la fonction
d'addition "add". Sur la figure, le service de nommage NS est représenté à
s l'extérieur des machines PS, RE ou CL, cependant il peut être localisé dans
l'une quelconque des machines "serveur" du réseau et donc par exemple
dans RE.
La seconde machine CL) lors de l'étape 3, va chercher dans un répertoire
io du service de nommage, couramment appelé CDSD ("Cell Directory Server
Daemon") l'adresse (par exemple une adresse Internet) de la fonction à
exécuter, dans le cas présent la fonction "add".
Lors de l'étape 4) la seconde machine CL émet à son tour, vers une
is seconde unité d'exécution TH2 de la machine RE, un appel RPC 2
(représenté par une flèche en trait plein), conforme à la représentation
réseau grâce aux talons standards) cet appel correspondant à la fonction à
exécuter et comportant les paramètres d'entrée (a) b) et de sortie (c) de
ladite fonction. L'appel RPC 2 peut être par exemple du type "add" (a [in],
2o b [in]) c [out])". L'unité d'exécution TH2 émet le signal de réveil attendu
par
la première machine PS (pthread_cond signal (tond var work)) puis se
met en attente d'un signal de réveil qui peut être une variable de condition
du type (pthread_cond_wait(cond var arg) ce qui a pour effet de bloquer la
seconde machine CL sur l'appel RPC 2.
La premiëre machine PS est, lors de l'étape 5) renseignée sur le type de
fonction à exécuter par retour de l'appel RPC 1 (représenté par une flèche
en trait pointillé) ainsi débloqué) le numéro de la fonction, correspondant
ici
à la fonction "add", lui étant transmis. C'est donc lors de cette étape) que
la
3o machine PS sait quelle fonction doit être exécutée, en l'occurrence la
fonction "add" et par là même le type de paramètres à demander.
A l'étape 6, la première machine PS émet vers l'unité d'exécution TH1 de la
machine RE, un nouvel appel RPC 3 (représenté par une flèche en trait
3s plein) par exemple du type "get add ([out]a,[out]b)", pour demander les
paramètres d'entrée (a,b) de la fonction "add" à exécuter. L'unité
d'exécution TH1 demande alors lesdits paramètres à la seconde unité
d'exécution TH2 et les obtient via un mécanisme de communication
~1~"~~~~1
interprocessus du genre "sockets") mémoire partagée avec sémaphores,
files de messages) tube de communication appelé également "pipe",... ou
intraprocessus par exemple du genre mémoire globale protégée par des
verrous.
s
Lorsque l'unité d'exécution TH 1 de la machine RE a obtenu les paramètres
d'entrée (a,b) de la fonction "add" à exécuter, elle transmet vers la première
machine PS, lors de l'étape 7) lesdits paramètres (a,b) par retour de l'appel
RPC 3 (représenté par une flèche en trait pointillé). La machine PS connaît
à présent la fonction à exécuter "add" et les paramètres d'entrée a et b et
elle exécute l'addition de a et b pour donner le résultat c=a+b.
La première machine PS transmet à l'unité d'exécution TH1 de la machine
RE, lors de l'étape 8) le résultat c de la fonction ainsi exécutée) au moyen
is par exemple de la fonction "set add {[in]c). L'unité d'exécution TH1 qui
connaiï à présent le résultat c, le communique à l'unité d'exécution TH2 via
un mécanisme de communication interprocessus ("sockets", mémoire
partagée avec sémaphores) files de messages, tube de communication
appelé également "pipe",...) ou intraprocessus (mémoire globale protégée
ao par des verrous par exemple) puis émet vers ladite unité TH2 le signal de
réveil attendu du type (pthread_cond signal(cond var arg)), ce qui aura
pour effet de débloquer l'appel RPC 2.
Enfin) lors de l'étape 9) la seconde unité d'exécution TH2 de la machine
Zs RE, par retour de l'appel RPC 2 (représenté par une flèche en trait
pointillé)
ainsi débloqué, transmet, vers la seconde machine CL) comme paramètre
de sortie le résultat c=a+b de la fonction "add" exécutée.
En conclusion, comme cela vient d'étre vu) le présent procédé qui permet
3o de simuler avantageusement une architecture "serveur" à partir d'une
architecture "client" peut être mis en oeuvre de manière aisée et rapide et
par conséquent son application est peu onéreuse.
