Programmation Objet en JAVA

Cours 9 : Réseau

R.M.I : Remote Method Invocation(révision du cours de Patrick Itey INRIA-Sophia)

Plan

Le morpion en package

moteur ui

PartieMorpion

JoueurHumain

JoueurHumainG

JoueurGeneric

Jeu

Joueur

JoueurMachine

• Au sein d’un package, la

communication avec l’extérieur ne

doit pas présumer de

l’implémentation.

•Les interfaces sont une solution.

interface

abstract class JoueurGeneric implements Joueur

Exemple du morpion (suite)

Partie

Jeu Joueurx2

Peut être un JoueurHumain ou un JoueurIA, via l’implémentation de l’interface Joueur

• L’implémentation du Joueur est fournie par un autre package• Ce package peut être réalisé indépendamment. • Répartition du travail• Intégration du code garantie !

Morpion : Passage au réseau

• Association de deux architecture.

– Moteur/UI VS Client/Server

– Association possible :

• Moteur et Server

• Client et UI

• Le moteur converse avec un joueur, pas avec un server ou un client.

• Du point de vue du moteur, un interlocuteur : le joueur.

• Le joueur masque, englobe le réseau

UI

Morpion architecture « locale »

Partie

Jeu Joueur

Le moteur

JoueurGeneric

JoueurHumain

JoueurHumainG

UI

Morpion architecture réseau

Partie

Jeu Joueur

UI : user interface

Réseau

UIJoueurNetwork

Morpion architecture réseau

UI : user interface

Réseau

UI JoueurNetwork

• JoueurNetwork implémente l’interface Joueur et assure l’interaction utilisateur.

• Relais d’information entre l’utilisateur et le moteur :

• transmets à l’UI le nécessaire à afficher,

• transmets au moteur les «  ordres » de l’utilisateur

• Le réseau est traité dans les classes UI et JoueurNetwork, comment ?

• Le JoueurNetwork attend la connexion de l’ UI avec un ServerSocket.

• La communication peut se faire soit via un flux de caractères (txt, xml, ...),

•soit en serialisant des objets, soit les 2.

Morpion avec des sockets

UI : user interface

Réseau

UI JoueurNetwork

Dépliage

Socket + InputStream

Pliage

Socket + OutputStream

Morpion avec serialization : objet distribué

UI : user interface

Réseau

JoueurHumainG Jeu

Dépliage

Socket + InputStream

Pliage

Socket + OutputStream

Le réseau comme un système distribué

L’idéal serait d’avoir un système distribué utilisant la technologie objet :

• Invoquer une méthode d’un objet se trouvant sur une autre machine

exactement comme s’il se trouvait au sein de la même machine et du même

JRE : objetDistant.methode();

• Utiliser un objet distant (OD), sans savoir où il se trouve :

objetDistant= ServiceDeNoms.recherche("monObjet");

• Pouvoir passer un OD en paramètre à une méthode locale ou distante :

resultat = objetLocal.methode(objetDistant);

resultat = objetDistant.methode(autreOD);

ObjetDistant = ObjetDistant.methode() ;

RMI (Remote Method Invocation)

Un système d’objets distribués performant destiné au développement

d’applications distribuées entièrement en Java.

• RMI est une core API (intégré au JDK 1.1) gratuit (différent de

CORBA) et 100 % Java.

• RMI propose un système d’objets distribués plus simple que CORBA.

• RMI est uniquement réservé aux objets Java.

RMI : présentation

• Mécanisme permettant l’appel de méthodes entre objets Java

s’exécutant sur des machines virtuelles différentes (espaces

d’adressage distincts),

• sur le même ordinateur ou sur des ordinateurs distants reliés par un

réseau;

• utilise directement les sockets, mais c’est déjà fait;

• code ses échanges avec un protocole propriétaire : R.M.P. (Remote

Method Protocol).

RMI : objectifs

• Rendre transparent l’accès aux objets distribués via le réseau

• Faciliter la mise en oeuvre et l’utilisation d’objets distants Java

• Préserver la sécurité (inhérent à l’environnement Java)

– RMISecurityManager

– Distributed Garbage Collector (DGC)

RMI : principes

• Un objet distant (server) : ses méthodes sont invoquées depuis une

autre JVM (autre processus distant ou local)

• L’objet distant est décrit par une interface (ou plus) :

déclaration des méthodes distantes utilisables par le client..

• Une invocation distante (RMI) concerne une méthode d’un objet

distant via l’interface distante.

• Du coté client, un objet distant se manipule comme un objet local.

Distribution d’objets

• Une référence à un OD peut être passée en argument ou retournée en

résultat d’un appel dans toutes les invocations (locales ou distantes).

• Un OD peut être transformé (cast) en n’importe quelles interfaces distantes

supportés par l’implémentation de l’objet.

• Les clients (objets clients) des OD (objets serveurs) interagissent avec des

interfaces distantes, jamais directement avec leurs implémentations.

• Les arguments locaux et les résultats d’une invocation distante sont toujours

passés par copie et non par référence

– leurs classes doivent implémentés Serializable.

RMI : le passage des paramètres

• L’argument ou la valeur de retour d’une méthode distante peut être de

n’importe quel type « Java » (types primitifs, classes locales ou distantes).

• Si jamais le type n’est pas disponible localement, il est chargé

dynamiquement (RMIClassLoader)

• pour les paramètres locaux, le transfert se fait nécessairement par copie.

• Pour un objet, l’ensemble de ses variables est « sérilializé » (Serializable).

• Pour les références d’un OD, l’objet amorce (Stub) est passé.

RMI : usage des interfaces

• L’interface est le contrat (abstrait) liant objets serveurs et clients.

• Elle est destinée à être implémentée par l’OD et constitue la base

d’appel pour les objets clients.

• Elle définie les signatures (noms, types de retours, paramètres) d’un

ensemble de méthodes et seules ces méthodes seront accessibles

par un objet client.

• Pour RMI, l’interface de départ est java.rmi.Remote : Héritons

pour définir nos interfaces !

RMI : Exception

• L’exception RemoteException

• Les objets clients doivent traiter des exceptions supplémentaires

comme RemoteException.

• Toute invocation distante de méthode doit lever ou traiter cette

exception.

– Peut se produire si la connexion a été interrompue

– ou si le serveur distant ne peut être trouvé.

RMI : architecture

Réseau

Client Server

Stub / Amorce

Couche de références des objets (rmiregister)

Stub /(Skeleton)

Couche de transport (connexion des JVMs)

JVM1 JVM2

Objets Amorces

• Programmes adaptateurs pour le transport des appels distants

– Réalisent les appels sur la couche réseau

– pliage / dépliage des paramètres

• A une référence d’OD manipulée par un client correspond une

référence d’amorce

• Les amorces sont générées par le compilateur d’amorces : rmic

• Deux types d’amorces pour l’interface avec le réseau (sérialisation):

– stub : représentant local (chez le client) de l’objet distant.

– skeleton : adaptateur coté server.

Couches « réseau »

La couche des références distantes :

• Permet l’obtention d’une référence d’objet distant à partir de la référence

locale au Stub

• Ce service est assuré par le lancement du programme rmiregister.

• Lancer qu’une fois par JVM, pour tous les objets à distribuer

• une sorte d’annuaire/connecteur de service distants.

La couche de transport

• Connecte les 2 espaces d’adressage (JVM)

• Suit les connexions en cours : écoute et répond aux invocations.

• Construit une table des OD disponibles et réalise l’aiguillage des invocations.

Etapes de développement

1. Définir une interface Java pour l’objet distant

2. Créer et compiler une classe implémentant cette interface

3. Créer et compiler une application serveur RMI

4. Créer les classes Stub (et Skeleton) (rmic)

5. Démarrer rmiregister et lancer l’application serveur RMI.

6. Créer, compiler et lancer le client accédant à des OD du serveur

Un exemple : l’echo

• Un objet permettant de faire l’echo au message qu’on lui envoie : Echo ec;ec.echo(‘’coucou’’);

Echo : coucou

• L’objet de type Echo est distant, l’évocation de la méthode (et de l’objet) et distante.

• 4 classes sont nécessaires :

– Echo: l’interface décrivant l’objet distant

– EchoDistant : l’implémentation de l’objet distant

– EchoServer : une application serveur RMI

– MainClient : l’application cliente utilisant

Interface Echo

• Attention à : java.rmi.RemoteException

EchoDistant, implémentation de Echo.

• Après la compilation, il faut générer le stub (et Skeleton) :

rmic echo.EchoDistant;//dans le repertoire au-dessus

• On obtient alors le fichier : echo.EchoDistant_Stub.class

• On peut spécifier un autre répertoire «  -d »

• Compiler pour l’ancienne version (avec Skeleton)

• ... regarder man rmic.

Application server pour l’objet Distant

• Le programme qui est à l’écoute des demandes des clients.

• Il lui faut un SecurityManager spécifique : RMISecurityManager

• Pour rendre l’objet disponible, il faut l’enregistrer dans le RMIregistry via la

méthode statique :

Naming.rebind("echo", od);

• Par la suite, cet objet distant est accessible en indiquant son URL

– String url= "rmi://nomServeurRMI:port/nomOD"

– String url= "rmi://leo.inria.fr/echo"

• Pour interroger le serveur : Naming.lookup(url);

Lancer le server et le service d’annuaire

> rmiregistery &

> java demo.rmi.EchoServer

• Le serveur est désormais disponible pour de futurs clients ... .

• Attention à l’ordre et au « & » !

Le client

Remarquons :

• Ce code manipule l’objet distant comme s’il était local.

• Après avoir installé un RMISecurityManager, le client recherche

l’objet distant en interrogeant le service d’annuaire RMI par :

Naming.lookup(url);