Telechargé par zinasondes

RMICorba

publicité
Invocation de Méthode à des
Objets distants
RMI et Corba
Applications Réparties
AM Dery
Merci à Rémi Vankeisbelck, Michel Riveill, Annick Fron, Mireille Blay Fornarino etc
Objectifs des objets répartis :
RAPPEL
1) invoquer des méthodes comme en local :
objetDistant.methode();
2) utiliser un objet distant (OD), sans savoir où il se trouve, en demandant
à un service « dédié » de renvoyer son adresse :
objetDistant =
ServiceDeNoms.recherche("monObjet");
3) passer un OD en paramètre d’appel à une méthode
resultat = objetLocal.methode(objetDistant);
resultat = objetDistant.methode(autreObjetDistant);
4) récupérer le résultat d’un appel distant sous forme d’un nouvel objet qui
aurait été créé sur la machine distante :
ObjetDistant1 = ObjetDistant2.methode() ;
2
Comparaison Corba RMI
Premières informations
3
Des technologies
RMI (Remote Method Invocation) est un
système d’objets distribués performant destiné
au développement d’applications distribuées
entièrement en Java
CORBA (Common Object Request Broker Architecture)
Plate-forme client/serveur orientée objets permet de
communiquer avec d ’autres langages (C++, Lisp,
Smalltalk, Python…)
4
Panorama
JRMP
Client
Serveur
Stub
Skeleton
Remote reference layer
Remote reference layer
TCP/IP, Unicast
5
CORBA par comparaison
IIOP
Client
Serveur
Stub
Skeleton
Object request broker
Object request broker
Interface IDL
TCP/IP, Unicast
6
Points communs et interopérabilité
• Utilisent les sockets
• Des Protocoles
– Un propriétaire : JRMP (Remote Method Protocol)
– Un protocole normalisé par l’OMG: IIOP
• Il existe des implémentations sur IIOP utilisées par
RMI
7
I.5. OMA
ORB
Spécificité Corba => ORB
 la localisation d’objet
 la désignation des objets
 l’empaquetage des paramètres (marshalling)
 le dépaquetage des paramètres (unmarshalling)
 l’invocation des méthodes
 la gestion des exceptions
 l ’activation automatique et transparente des objets
De plus, il fournit des caractéristiques telles que :
 la liaison avec « tous » les langages de programmation
 un système auto-descriptif
 l ’interopérabilité entre les bus
8
Modèle de référence OMA
Objets
applicatifs
Interfaces
de domaine
Utilitaires communs
Workflow Administration
Télécom
Spécifiques
Santé
Finance
DataWare
IHM
Bus d’objets répartis (O.R.B.)
Nommage
Vendeur
Interrogations
Sécurité
Relations Collections Temps
Cycle
de vie Transactions Propriétés Persistance
Licences Externalisation
Events ChangementsConcurrence
Services objet communs (CORBA Services)
Rappel processus RMI
Interface
HelloWorld
Interface
HelloWorld
Code du client
Classe
d’implémentation
HelloWorldImpl
Code du serveur
Utilisation du registry
10
Corba : Interface décrite avec IDL
Client
d’objets
Stub
IDL
Contrat
IDL
Bus CORBA
Objets Corba
Fournisseur
d ’objets
Squelette
IDL
Étapes de mise en œuvre Corba
Spécification interface IDL
Compilation interface IDL
Implantation des objets Corba
Implantation du client
Implantation du serveur
Enregistrement du serveur
Côté client
Utilisation du service Nommage
Côté serveur
12
Dans les 2 cas
• Une référence à un OD peut être :
– passée en argument
– retournée en résultat d ’un appel dans toutes les
invocations (locales ou distantes)
• Un OD peut être transformé (cast) en
n’importe laquelle des interfaces qu ’il
implémente
13
L ’amorce client (stub) (1)
• Représentant local de l ’OD qui implémente
ses méthodes « exportées »
• Transmet l ’invocation distante à la couche
inférieure Remote Reference Layer / ORB
• Il réalise le pliage (« marshalling ») des
arguments des méthodes distantes
• Dans l ’autre sens, il réalise le dépliage
(« demarshalling ») des valeurs de retour
14
L ’amorce client (Stub) (2)
• Il utilise pour cela la sérialisation des objets
• Il les transforme en un flot de données (flux
de pliage) transmissible par le réseau
15
L ’amorce serveur (Skeleton)
• Réalise le dépliage des arguments reçus par
le flux de pliage
• Fait un appel à la méthode de l ’objet distant
• Réalise le pliage de la valeur de retour
16
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 : un service d’annuaire
– Rmiregistry en RMI
– Service de nommage Naming en Corba
– JNDI Interface d’annuaire
17
La couche de transport
• Connecte les 2 espaces d ’adressage (JVM
pour Java)
• Suit les connexions en cours
• Ecoute et répond aux invocations
• Construit une table des OD disponibles
• Réalise l ’aiguillage des invocations
• Sécurité ?
18
Diagramme d ’interaction
Stub
Skeleton
Implementation
invoke
Marshal param
Send req.
Unmarshal param
Invoke impl.
Return result
Unmarshal reply
Return value or exc
Return return or exc.
Marshal return or exc.
Send reply
19
Passage de paramètres
20
Passage de paramètres
• On sera souvent amenés à passer des
paramètres aux méthodes distantes...
• Les méthodes distantes peuvent retourner une
valeur ou lever une exception...
• On a deux types de paramètres
– Les objets locaux au client
– Les objets distants au client
21
Passage de paramètres:
ATTENTION
– Certains objets sont copiés (les objets locaux), d'autres
non (les objets distants)
– Les objets distants, non copiés, résident sur le serveur
– Les objets locaux passés en paramètre doivent être
sérialisables afin d'être copiés, et ils doivent être
indépendants de la plate-forme
– Les objets qui ne sont pas sérialisables lèveront des exceptions
– Attention aux objets sérialisables qui utilisent des ressources locales !!!
22
Passage de paramètres
Objets locaux RMI
• RMI permet de transporter (copier) des objets
complexes qui doivent avoir la capacité de se
mettre en série
• RMI utilise les mécanismes de sérialisation
inclus dans Java (java.io)
• Il faut des classes d'objets implémentant
l'interface Serializable
23
Passage de paramètres
Objets locaux – exemple RMI
• On crée un objet sérialisable local StateObject à deux
états que l'on va passer à une méthode distante
• On crée un OD avec une méthode qui change l'état d'un
objet StateObject qu'on lui passe en paramètre et qui
le retourne
• Le client crée un objet StateObject et affiche son état
• Il invoque la méthode du serveur en lui passant l'objet à
état créé et récupère le retour dans une variable
• Il affiche l'état de l'objet référencé avant invocation,
puis de celui résultant de l'invocation
24
Passage de paramètres
Objets locaux – exemple RMI
• Diagramme de classes
25
Passage de paramètres
Objets locaux – exemple RMI
• La classe StateObject
26
Passage de paramètres
Objets locaux – exemple RMI
• L'interface StateChanger
27
Passage de paramètres
Objets locaux – exemple RMI
• La classe StateChangerImpl
28
Passage de paramètres
Objets locaux – exemple RMI
• Le programme serveur
29
Passage de paramètres
Objets locaux – exemple RMI
• Démarrage du serveur
– On lance le rmiregistry
– On lance le serveur
30
Passage de paramètres
Objets locaux – exemple RMI
• Le programme client
31
Passage de paramètres
Objets locaux – exemple RMI
• Démarrage du client
• Conclusion
– L'état de l'objet créé en local n'a pas changé, par
contre, l'objet retourné a un état différent
– Il y a bien eu copie de l'objet
• Dans notre exemple, 2 copies !!!
– Une lors du passage de so1 en paramètre
– L’autre lors du retour de la méthode
32
Passage de paramètres
Objets locaux – exemple RMI
33
Passage de paramètres
Objets distants RMI
• Passage d'objets distants
– Le passage d'un objet distant à une méthode ou comme
valeur de retour manipule en fait un stub
– Exemple typique : la recherche d'objets dans la base de
registres rmiregistry
HelloWorld h = (HelloWorld)Naming.lookup(...);
• Retourne un stub pour un OD de type HelloWorld
• L'appelant peut ensuite manipuler l'OD au travers du stub
reçu
– Pas de copie de l'objet, mais transmission du stub
34
Passage de paramètres
Objets distants
• Passage d'objets distants
– Très différent du passage d'objets locaux
– Les objets locaux sont copiés
• Les deux protagonistes ne manipulent pas le même objet
– Passage d'OD = passage du stub
• Pas de copie
• Les deux protagonistes manipulent le même objet au travers
de son stub
35
Passage de paramètres
Objets distants RMI
• On va créer un OD (1) de type HelloAccessor
qui permet d'accéder à un autre OD (2) de type
HelloWorld, situé dans la même JVM
– Un client va
• 1) Obtenir une référence vers l'OD (1)
• 2) Invoquer sa méthode et récupérer l'OD (2)
• 3) Invoquer la méthode sayHello() de l'OD (2)
=> sayHello() affiche une trace dans la console... regardons si
la trace s'affiche chez le client ou le serveur
36
Passage de paramètres
Objets distants – exemple RMI
• Diagramme de classes
37
Passage de paramètres
Objets distants – exemple RMI
• L'interface HelloAccessor
38
Passage de paramètres
Objets distants – exemple RMI
• La classe HelloAccessorImpl
39
Passage de paramètres
Objets distants – exemple RMI
• Le serveur HelloAccessorServer
40
Passage de paramètres
Objets distants – exemple RMI
• Démarrons le serveur
– 1) Démarrage du rmiregistry
– 2) Démarrage du serveur
– => Le serveur est lancé, occupons nous maintenant du
client...
41
Passage de paramètres
Objets distants – exemple RMI
• Le client HelloAccessorClient
42
Passage de paramètres
Objets distants – exemple RMI
• Démarrage du client
• => Pas de trace niveau client...
• Regardons la trace serveur :
=> La méthode a bien été exécutée sur le serveur !
43
Objets distants – exemple RMI
44
Passage de paramètres
Conclusion
• Il faut être vigilant quand au passage des paramètres
– Certains objets sont copiés (les objets locaux), d'autres
non (les objets distants)
– Les objets distants, non copiés, résident sur le serveur
– Les objets locaux passés en paramètre doivent être
sérialisables afin d'être copiés, et ils doivent être
indépendants de la plate-forme
– Les objets qui ne sont pas sérialisables lèveront des exceptions
– Attention aux objets sérialisables qui utilisent des ressources locales !!!
45
Déploiement
46
Que doit connaître le client ?
• Lorsqu’un objet serveur est passé à un
programme, soit comme paramètre soit
comme valeur de retour, ce programme doit
être capable de travailler avec le stub associé
• Le programme client doit connaître la classe
du stub
47
Que doit connaître le client ?
• les classes des paramètres, des valeurs de
retour et des exceptions doivent aussi être
connues...
– Une méthode distante est déclarée avec un type de
valeur de retour...
– ...mais il se peut que l ’objet réellement renvoyé
soit une sous-classe du type déclaré
48
Que doit connaître le client ?
• Le client doit disposer des classes de stub,
classes des objets retournés…
• copier les classes sur le système de fichiers local du
client (CLASSPATH)...
• ...cependant, si le serveur est mis à jour et que de
nouvelles classes apparaissent, il devient vite pénible de
mettre à jour le client
• C ’est pourquoi les clients RMI peuvent charger
automatiquement des classes de stub depuis un autre
emplacement
– Il s ’agit du même type de mécanisme pour les applets qui
fonctionnent dans un navigateur
49
Chargement dynamique des
amorces
• Rappel : un objet client ne peut utiliser un
objet distant qu ’au travers des amorces
• RMI permet l ’utilisation des OD dont les
amorces ne sont pas disponibles au moment
de la compilation
• A l ’exécution, RMI réclamera au serveur
l ’amorce client manquante et la
téléchargera dynamiquement (byte code)
50
Chargement dynamique des
classes
• Plus généralement, le système RMI permet
le chargement dynamique de classes comme
les amorces, les interfaces distantes et les
classes des arguments et valeurs de retour
des appels distants
• C ’est un chargeur de classes spécial RMI
qui s ’en charge
java.rmi.server.RMIClassLoader
51
Sécurité (1)
• RMI n ’autorise pas le téléchargement
dynamique de classes (avec
RMIClassLoader) si l ’application (ou
l ’applet) cliente n ’utilise pas de
SecurityManager pour les vérifier.
• Dans ce cas, seules les classes situées dans
le CLASSPATH peuvent être récupérées
52
Sécurité (2)
• Le gestionnaire de sécurité par défaut pour
RMI est java.rmi.RMISecurityManager
• Il doit être absolument utilisé
(System.setSecurity()) pour les applications
standalone
• Pas de problèmes pour les applets, c ’est
l ’AppletSecurityManager (par défaut) qui
s ’en charge
53
RMISecurityManager
• Il est très simple :
• Vérifie la définition des classes et autorise
seulement les passages des arguments et des
valeurs de retour des méthodes distantes
• Ne prend pas en compte les signatures
éventuelles des classes
54
Quelques bouquins...
• Core Java Volume 2
•
•
•
•
Par Cay S. Horstmann & Gary Cornell
Editions CampusPress
Une référence pour les développeurs Java
Bonne section sur RMI, servi de base pour ce cours
• Java Distributed Computing
•
•
•
•
Par Jim Farley
Editions O'Reilly
Tout sur les applications reparties avec Java
Plus technique...
55
Téléchargement