Techniques de programmation Java par objets distribués

Java RMI Y. Laborde Cours LOO - TOA
1
TECHNIQUES DE PROGRAMMATION JAVA
PAR OBJETS DISTRIBUES
 DÉFINITIONS :
Objet Distribué (OD) : c’est un objet à exécution distante rendu accessible à des
applications clientes (OD-clients) par le biais d’une interface depuis un serveur (OD-
serveur).
Plus techniquement, c’est une appellation abstraite qui rassemble plusieurs entités :
- Côté serveur : un objet physique (l’Objet métier Distribué)
un serveur proxy (Skeleton = amorce serveur ou squelette)
- Côté client : une interface de l’objet physique (l’Interface métier Distribuée)
un client proxy (Stub = amorce cliente, souche ou talon)
Attention : les termes client et serveur ne réfèrent pas aux appellations classiques de
programme client ou programme serveur.
OD-client : c’est un programme, une classe ou un objet en relation avec des OD.
OD-serveur : c’est un programme, une classe ou un objet fournissant des OD.
Comme il arrive souvent que des programmes (i.e. des objets) aient à s’échanger
mutuellement des objets, chacun des programmes (i.e. des objets) est souvent à la
fois OD-client et OD-serveur.
On peut également parler d’OD-classe, d’OD-objet, d’OD-méthode, d’OD-interface,
d’OD-référence, d’OD-exception, etc. Les appellations ne sont pas limitées.
 LA PROGRAMMATION DISTRIBUÉE PERMET :
- Côté client : - de récupérer des OD-références depuis un ou plusieurs OD-serveurs,
- de faire s’exécuter les OD-méthodes distantes sur les OD-serveurs,
- de passer les paramètres des OD-méthodes distantes en tant que :
- OD (passés par référence),
- types primitifs (passés par valeur),
- objets (passés par valeur).
- de récupérer localement les valeurs de retour des OD-méthodes
distantes en tant que :
- OD (reçus en passage par référence),
- types primitifs (reçus en passage par valeur),
- objets (reçus en passage par valeur).
- Côté serveur : - de déclarer l’exportation des OD instanciés sur le serveur,
- de procéder à l’exécution locale des OD-méthodes par appel distant,
- de retourner les valeurs de retours des OD-méthodes à l’appelant
distant.

Java RMI Y. Laborde Cours LOO - TOA
2
En Java, il existe 2 manières principales d’implémenter des objets distribués :
- à l’aide de CORBA* (de OMG®) : destiné à des applications distribuées faisant interagir
des objets Java avec d’autres objets d’autres langages (C, C++, Java, COBOL, Smalltalk, Ada,
Lisp, Python et IDLscript). Il utilise un langage de définition d’interface (IDL) qui définit les
OD indépendamment des langages d’origine.
- à l’aide de RMI* (core API Java depuis le JDK 1.1) : système d’objets distribués destiné
aux applications distribuées entièrement en Java.
Du fait qu’il est purement Java, RMI est plus simple et plus performant que CORBA.
RMI est développé par JavaSoft® (et non SunSoft®), il est gratuit et 100% Java.
- il existe aussi d’autres implémentations alternatives (souvent open-source) : NinjaRMI
(de Berkley®) ou Jeremy (de ObjectWeb®).
* CORBA = Common Object Request Broker Architecture
* RMI = Remote Method Invocation

Java RMI Y. Laborde Cours LOO - TOA
3
LE FRAMEWORK : REMOTE METHOD INVOCATION
 LE FRAMEWORK RMI : C’est un système d’objets et d’outils permettant l’appel de
méthodes entre objets Java s’exécutant sur des Machines Virtuelles Java (JVM)
différentes.
 INFORMATIONS GÉNÉRALES :
- un couple (OD-client, OD-serveur) communique par l’intermédiaire de :
- deux instances de JVM sur une même machine (processus différents),
- deux instances de JVM sur 2 machines distantes (via un réseau) ;
- les espaces d’adressage des JVM sont distincts (gestion mémoire et GC distincts) ;
- les échanges réseau se font à l’aide d’un protocole propriétaire qui utilise la
sérialisation sur le port 1099 : JRMP (Java Remote Method Protocol) ;
- RMI utilise directement les sockets ; les communications sont acheminées via des
url spécifiques dites url-RMI (syntaxe : rmi://<nomServeurRMI>:<port> (par défaut : 1099)
 LA SUITE DE DÉVELOPPEMENT RMI :
- le Framework RMI :
- java.rmi (classes et une interface pour les OD-clients – accès aux OD)
- java.rmi.server (classes et interfaces pour les OD-serveurs – création des OD)
- java.rmi.activation (classes et interfaces pour l’activation d’OD)
- java.rmi.dgc (ramasse-miettes réparti qui tient compte des OD client et serveur)
- java.rmi.registry (classes et interfaces pour le service de résolution de noms –
enregistrement et localisation des OD)
- outils et services du Framework RMI :
Principalement :
- un générateur d’amorces (rmic) (outils qui génère des amorces de classes pour les
OD ; ces amorces sont des serveurs proxy qui encapsulent les OD-objets)
- un serveur de noms (rmiregistry) (outils et service de résolution de noms qui
enregistre, maintien et fournit les références distantes aux OD)
- un démon d’activation (rmid) (service d’activation d’OD, démon qui permet de
n’activer des OD qu’au moment où leurs OD-méthodes sont invoquées par un OD-client)
- un RMI garbage collector (dgc) (service de ramasse-miettes étendu aux OD, démon
qui permet de maintenir les objets en vie tant qu’il existe au moins une référence soit du côté
OD-serveur, soit du côté OD-client)
et aussi :
- un protocole réseau RMI (JMRP) (service de protocole pour les échanges réseau RMI ;
utilise le protocole propriétaire (Java Remote Method Protocol) sur le port 1099 par défaut)
- une architecture de liaison RMI (UnicastRemoteObject) (architecture RMI qui
supporte la liaison de type POINT à POINT, i.e. unicast)
- un service de sécurité RMI (RMISecurityManager) (service qui gère la sécurité
des accès aux OD-objets)
- un service de téléchargement RMI (RMIClassLoader) (service de téléchargement
dynamique de byte-code depuis les OD-serveurs vers les OD-clients)

Java RMI Y. Laborde Cours LOO - TOA
4
Les amorces (Stub/Skeleton)
 Pour chaque OD, elles définissent les SERVICES NÉCESSAIRES À L’OBJET
DISTANT, ce qui incorpore les propriétés de son OD-interface et de leurs
implémentations :
- Côté client : le Stub est un serveur proxy qui :
- représente la classe vraie de l’OD (invisible du client car l’OD ne peut être vu
qu’au travers de son OD-interface),
- permet que soit invoqué une OD-méthode sur lui-même avec une
signature identique à celle de l’objet métier,
- effectue le pliage (marshalling) des paramètres d’appel de l’OD-méthode,
- transmet l’appel distant via java.lang.reflect.Method,
- retourne le résultat via un ObjectInput après dépliage,
- peut générer des exceptions RemoteException (NoSuchMethodException,
UnexpectedException ou UnmarshalException).
- Côté serveur : le Skeleton est un serveur proxy qui :
- représente une classe intermédiaire d’invocation de l’OD-méthode
(invisible du serveur qui ne peut voir que l’OD-interface ou l’OD-classe),
- effectue le dépliage des paramètres d’appel de l’OD-méthode,
- invoque l’appel distant via une table de méthodes associée à l’OD-
interface,
- récupère lé résultat de l’OD-méthode et en effectue le pliage,
- retourne le résultat via un ObjectOutput,
- peut générer des exceptions RemoteException (SkeletonMismatchException,
MarshalException ou UnmarshalException).
ARCHITECTURE RMI
Couche de transport
(Socket + Protocole JMRP)
Service de résolution de noms
rmiregister (sous JNDI)
Amorce client
Stub*
OD-client
Amorce serveur
Skeleton*
OD-serveur
* Génération
dynamique depuis
JDK 1.5

Java RMI Y. Laborde Cours LOO - TOA
5
 À PROPOS DE LA SÉRIALISATION (marshalling/unmarshalling, pliage/dépliage) :
Pour que des objets puissent passer via un flux de données ObjectStream, il leur faut
implémenter soit l’interface java.io.Serializable (qui sérialise automatiquement) soit
l’interface java.io.Externalizable (qui effectue sa propre sérialisation).
Ce doit être le cas pour : tous les OD, tous les paramètres des OD-méthodes, et
pour tous les objets retournées par les OD-méthodes.
La plupart des classes de java.lang et java.util. sont Serializable.
 À PROPOS DES EXCEPTIONS (java.rmi.RemoteException) :
Toutes les OD-méthodes doivent être déclarées comme throws RemoteException
au niveau de leurs interfaces, sinon la génération des amorces échouera.
 GÉNÉRATION DES AMORCES À L’AIDE DE L’OUTIL rmic :
Pour générer les amorces, il faut partir de la classe compilée de l’OD-objet :
amorces : >rmic -d $HOME/classes ODInterfaceImpl.class
Doit avoir accès à l’OD-interface compilée : ODInterface.class
Remarque :
Les amorces sont générées dynamiquement par la JVM depuis la version 1.5 :
(ATTENTION : information non vérifiée ; voir la doc Java de la classe UnicastRemoteObject)
si la propriété système java.rmi.server.ignoreStubClasses est vraie, les amorces sont
construites dynamiquement.