Annexe B
Accueil Remonter Annexe A Annexe B Annexe C Annexe D Annexe E

Mes projets : Labyrinthe 3D  Zoom Magazine  PFE - Back Orifice ENSI MAIL - SamiComputer - SQL Generator - Virtual Conference - SamiNavigator - Taquin - STP - Livre d'or - Mon diplôme - Lettre de Motivation - News - ENSI

Téléchargez notre video de promotion 

Tous ces liens sont sponsorisés par:

Bab el WEB

Comment ça Marche

guill.Net

 

ANNEXE B

 

 

                                                             Initiation à RMI

 

1     Présentation de RMI

RMI (Remote Method Invocation) est une API Java permettant de manipuler des objets distants (c'est-à-dire un objet instancié sur une autre machine virtuelle, éventuellement sur une autre machine du réseau) de manière transparente pour l'utilisateur [17], c'est-à-dire de la même façon que si l'objet était sur la machine virtuelle (JVM) de la machine locale. Ainsi un serveur permet à un client d'invoquer des méthodes à distance sur un objet qu'il instancie. Deux machines virtuelles sont donc nécessaires (une sur le serveur et une sur le client) et l'ensemble des communications se fait en Java.

On dit généralement que RMI est une solution "tout Java", contrairement à la norme Corba de l'OMG (Object Management Group) permettant de manipuler des objets à distance avec n'importe quel langage. Corba est toutefois beaucoup plus compliqué à mettre en oeuvre, c'est la raison pour laquelle de nombreux développeurs se tournent généralement vers RMI.

 2         Structure des couches RMI 

Les connexions et les transferts de données dans RMI sont effectuées par Java sur TCP/IP grâce à un protocole propriétaire (JRMP, Java Remote Method Control Protocol) sur le port 1099. A partir de Java 2 version 1.3, les communications entre client et serveur s'effectuent grâce au protocole RMI-IIOP (Internet Inter-Orb Protocol), un protocole normalisé par l'OMG (Object Management Group) et utilisé dans l'architecture CORBA. La transmission de données se fait à travers un système de couches, basées sur le modèle OSI (Fig. B.1) afin de garantir une interopérabilité entre les programmes et les versions de Java.

 

Fig. B.1 -  Structure des couches RMI

 

La Fig. B.1 met en œuvre les composants suivants :

·         Le stub (traduisez souche) et le skeleton (traduisez squelette), respectivement sur le client et le serveur, assurent la conversion des communications avec l'objet distant.

·         La couche de référence (RRL, Remote Reference Layer) est chargée du système de localisation afin de fournir un moyen aux objets d'obtenir une référence à l'objet distant. Elle est assurée par le package java.rmi.Naming. On l'appelle généralement registre RMI car elle référence les objets.

·         La couche de transport permet d'écouter les appels entrants ainsi que d'établir les connexions et le transport des données sur le réseau par l'intermédiaire du protocole TCP. Les packages java.net.Socket et java.net.SocketServer assurent implicitement cette fonction.

Ainsi, une application client-serveur basée sur RMI met ainsi en oeuvre trois composantes :

une application cliente implémentant le stub
une application serveur implémentant le skeleton (squelette)
une application médiatrice (le registre RMI) servie par un processus tiers (rmiregistry)

3        Architecture de RMI

L'architecture de RMI est schématisée ci-dessous (Fig. B.2) :

Fig. B.2 - Architecture de RMI.

 

Lorsqu'un objet instancié sur une machine cliente désire accéder à des méthodes d'un objet distant, il effectue les opérations suivantes :

  1. Il localise l'objet distant grâce à un service de désignation : le registre RMI
  2. Il obtient dynamiquement une image virtuelle de l'objet distant (appelée stub ou souche en français). Le stub possède exactement la même interface que l'objet distant.
  3. Le stub transforme l'appel de la méthode distante en une suite d'octets, c'est ce que l'on appelle la sérialisation, puis les transmet au serveur instanciant l'objet sous forme de flot de données. On dit que le stub "marshalise" les arguments de la méthode distante.
  4. Le squelette instanciée sur le serveur "désérialise" les données envoyées par le stub (on dit qu'il les "démarshalise"), puis appelle la méthode en local
  5. Le squelette récupère les données renvoyées par la méthode (type de base, objet ou exception) puis les marshalise
  6. le stub démarshalise les données provenant du squelette et les transmet à l'objet faisant l'appel de méthode à distance

4        Mise en œuvre de RMI

Pour créer une application avec RMI il suffit de procéder comme suit :

  1. définir la classe distante. Celle-ci doit dériver de java.rmi.server.UnicastRemoteObject (utilisant elle-même les classes Socket et SocketServer, permettant la communication par protocole TCP) : dans notre application FORUM ça correspond à "ServerImpl.class".
  2. Définir l'interface pour la classe distante. Celle-ci doit implémenter l'interface java.rmi.Remote et déclarer les méthodes publiques globales de l'objet, c'est-à-dire les méthodes partageables. De plus ces méthodes doivent pouvoir lancer une exception de type java.rmi.RemoteException : dans notre application FORUM ça correspond à « Server_Interface.class ».
  3. Créer les classes pour le stub et le squelette grâce à la commande rmic
  4. Lancer le registre RMI et lancer l'application serveur, c'est-à-dire instancier l'objet distant. Celui-ci lors de l'instanciation créera un lien avec le registre.
  5. Créer un programme client capable d'accèder aux méthodes d'un objet sur le serveur grâce à la méthode Naming.lookup() : dans notre application FORUM ça correspond à « Admin_Applet.class » et « Connection_Applet.calss ».
  6. Compiler l'application cliente.
  7. Instancier le client.