Programmation Objet en JAVA Cours 9 : Réseau R. M Programmation Objet en JAVA Cours 9 : Réseau R.M.I : Remote Method Invocation (révision du cours de Patrick Itey INRIA-Sophia)

Plan

abstract class JoueurGeneric implements Joueur Le morpion en package 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. moteur ui PartieMorpion JoueurHumain JoueurHumainG JoueurGeneric Jeu Joueur JoueurMachine interface abstract class JoueurGeneric implements Joueur

Exemple du morpion (suite) Peut être un JoueurHumain ou un JoueurIA, via l’implémentation de l’interface Joueur x2 Jeu Joueur Partie 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

Morpion architecture « locale » UI JoueurHumain UI JoueurGeneric JoueurHumainG Jeu Joueur Partie Le moteur

Morpion architecture réseau UI : user interface UI JoueurNetwork Réseau Jeu Joueur Partie

Morpion architecture réseau UI : user interface UI JoueurNetwork Réseau 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 UI JoueurNetwork Réseau Dépliage Pliage Socket + InputStream Socket + OutputStream

Morpion avec serialization : objet distribué UI : user interface JoueurHumainG Jeu Réseau Dépliage Pliage Socket + InputStream 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 JVM1 JVM2 Client Server Réseau Stub / Amorce Stub /(Skeleton) Couche de références des objets (rmiregister) Couche de transport (connexion des JVMs)

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 Définir une interface Java pour l’objet distant Créer et compiler une classe implémentant cette interface Créer et compiler une application serveur RMI Créer les classes Stub (et Skeleton) (rmic) Démarrer rmiregister et lancer l’application serveur RMI. 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);