I.6.2. La communication synchrone
On attend par « communication » tout
procédé qui permet d'exécuter une section de code distant
de la même manière que si l'appel était local.
L'exécution se fait de façon séquentielle vis-à-vis
du programme.
Figure I.1. Communication synchrone
9
10
I.6.3. RMI (Remote Method Invocator)
RMI permet, contrairement aux RPC, d'invoquer une
méthode distante en passant en paramètres des objets complets.
L'invocation des méthodes distantes passe par un système
d'assemblage et de dessablage pris en charge par les « stubs » et les
« squelettes ». Le « stub » est implanté coté
client et crée un paquet contenant le nom de la méthode à
appeler ainsi que les paramètres associés. Cette opération
est baptisée « assemblage ». Le squelette reçoit les
demandes venant des « stubs ». Il est chargé du
désassemble des paquets et appelle la méthode demandée par
le client. Enfin, il assemble la valeur de retour (ou éventuellement une
exception) et la transmet au client. Les « stubs » et les «
squelettes » sont des entités complètement transparentes
pour le programmeur JAVA. Lorsque les paramètres sont des objets locaux,
ils sont passés par copie. Cette opération se nomme «
sérialisation d'objet ». Si un objet distant est passé en
paramètre, le stub client passera la référence sur cet
objet. Cela permettra au serveur d'invoquer à son tour des
méthodes de l'objet distant. Pour qu'une méthode puisse
être invoquée en distance, celle-ci doit être
enregistrée dans un catalogue global nommée « RMI registry
».
La recherche d'un objet distant se fait la
concaténation du nom de l'hôte (ou l'adresse IP) et du nom de la
méthode cherchée :
« rmi://nom_hote/nom_methode ».
Cette méthode sous-entend que le programmeur connait
le ou les noms des machines qui exportent les objets. Les méthodes
inscrites dans les systèmes RMI peuvent être
déclarées « synchronized ». Cela permet de gérer
simplement l'accès concurrent de plusieurs threads sur une
méthode. Pour gérer le « stub » et le « squelette
», il faut utiliser le RMI compilé « RMIC ». Les RMI sont
une technologie JAVA vers JAVA, cela signifie qu'une application
distribuée reposant sur les RMI est forcément
développée avec le langage JAVA.
Figure I.2. Fonctionnement RMI
I.6.4. CORBA (Common Object Request Broker
Architecture)
CORBA est un « middleware » (couche logicielle
intermédiaire) orienté objets, qui a pour objectif
l'intégration d'application distribuées
hétérogènes à partir des technologies objet
indépendamment :
? Des moyens de communication réseaux ? Des langages de
programmation
? Des systèmes d'exploitation
Toutes les requetes à des objets distants passent par
un ORB (Object Request Brocker). L'ORB d'un client doit trouver l'objet distant
dans le système distribué ; il communique avec l'ORB serveur.
L'ORB est appelé « Bus logiciel ».
Comme pour les RMI, les objets s'inscrivent dans un catalogue
global au système. Pour pouvoir communiquer avec un objet distant, un
client doit au préalable trouver le nom de l'objet dans le catalogue.
Un système CORBA fonctionne de la façon suivante
:
Dès qu'un client a obtenu une référence
à un objet distant, toutes les invocations aux méthodes de cet
objet passent par l'ORB (via le stub client). Lorsque l'ORB du serveur
reçoit une requête, il appelle le squelette approprié ;
celui-ci invoque à son tour la méthode demandée. Des
valeurs de retour peuvent être renvoyées par ce même canal
de communication.
| 
