Publicités
RMI signifie Remote Method Invocation. C’est un mécanisme qui permet à un objet résidant dans un système (JVM) d’accéder / d’invoquer un objet s’exécutant sur une autre JVM.
RMI est utilisé pour créer des applications distribuées; il fournit une communication à distance entre les programmes Java. Il est fourni dans le package java.rmi.
Architecture d’une application RMI
Dans une application RMI, nous écrivons deux programmes, un programme serveur (réside sur le serveur) et un programme client (réside sur le client).
-
Dans le programme serveur, un objet distant est créé et la référence de cet objet est mise à la disposition du client (à l’aide du registre).
-
Le programme client demande les objets distants sur le serveur et essaie d’appeler ses méthodes.
Le diagramme suivant montre l’architecture d’une application RMI.
Discutons maintenant des composants de cette architecture.
-
Couche de transport – Cette couche connecte le client et le serveur. Il gère la connexion existante et établit également de nouvelles connexions.
-
Stub – Un stub est une représentation (proxy) de l’objet distant chez le client. Il réside dans le système client; il agit comme une passerelle pour le programme client.
-
Squelette – C’est l’objet qui réside côté serveur. stub communique avec ce squelette pour transmettre la requête à l’objet distant.
-
RRL (Remote Reference Layer) − C’est la couche qui gère les références faites par le client à l’objet distant.
Fonctionnement d’une application RMI
Les points suivants résument le fonctionnement d’une application RMI −
-
Lorsque le client fait un appel à l’objet distant, il est reçu par le stub qui transmet finalement cette requête au RRL.
-
Lorsque le RRL côté client reçoit la requête, il appelle une méthode appelée invoke() de l’objet remoteRef. Il transmet la requête au RRL côté serveur.
-
Le RRL côté serveur transmet la requête au Squelette (proxy sur le serveur) qui appelle finalement l’objet requis sur le serveur.
-
Le résultat est transmis au client.
Marshalling et Unmarshalling
Chaque fois qu’un client appelle une méthode qui accepte des paramètres sur un objet distant, les paramètres sont regroupés dans un message avant d’être envoyés sur le réseau. Ces paramètres peuvent être de type primitif ou objets. En cas de type primitif, les paramètres sont assemblés et un en-tête y est attaché. Dans le cas où les paramètres sont des objets, ils sont sérialisés. Ce processus est connu sous le nom de marshalling.
Côté serveur, les paramètres emballés sont dégroupés, puis la méthode requise est appelée. Ce processus est connu comme unmarshalling.
Registre RMI
Le registre RMI est un espace de noms sur lequel tous les objets serveur sont placés. Chaque fois que le serveur crée un objet, il enregistre cet objet avec le RMIregistry (en utilisant les méthodes bind() ou reBind()). Ceux-ci sont enregistrés en utilisant un nom unique appelé nom de liaison.
Pour appeler un objet distant, le client a besoin d’une référence de cet objet. À ce moment-là, le client récupère l’objet dans le registre en utilisant son nom de liaison (en utilisant la méthode lookup()).
L’illustration suivante explique l’ensemble du processus –
Objectifs du RMI
Voici les objectifs du RMI −
- Pour minimiser la complexité de l’application.
- Pour préserver la sécurité du type.
- Collecte de déchets distribuée.
- Minimisez la différence entre travailler avec des objets locaux et distants.
Annonces
