programmation objet en java cours 9 : réseau r.m.i : remote method invocation (révision du cours...
TRANSCRIPT
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);