invocation de méthode à des objets distants rmi et corba
Post on 09-Jan-2016
40 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
2
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éthoderesultat = 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() ;
3
Comparaison Corba RMI
Premières informations
4
Des technologies
RMI (Remote Method Invocation) est unsystème d’objets distribués performant destinéau développement d’applications distribuéesentiè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…)
5
Panorama
Client
Stub
Remote reference layer
Serveur
Skeleton
Remote reference layer
TCP/IP, Unicast
JRMP
6
CORBA par comparaison
Client
Stub
Object request broker
Serveur
Skeleton
Object request broker
TCP/IP, Unicast
IIOP
Interface IDL
7
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 Corba
8
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
I.5. OMAORB
CO
RB
AModèle de référence OMA
Bus d’objets répartis (O.R.B.)
Licences
Transactions PersistancePropriétés ChangementsEvents
Nommage Vendeur Sécurité Relations Collections Temps Externalisation
InterrogationsCyclede vie Concurrence
Services objet communs (CORBA Services)
Workflow
DataWare IHM
Administration
Utilitaires communs
Finance
Télécom
Santé
Interfacesde domaine
Objetsapplicatifs
Spécifiques
10
Rappel processus RMI
InterfaceHelloWorld
Interface HelloWorld
Classe d’implémentationHelloWorldImpl
Utilisation du registry
Code du client
Code du serveur
Contrat IDL
Bus CORBA SqueletteIDL
StubIDL
Fournisseurd ’objets
Clientd’objets
Corba : Interface décrite avec IDL
Objets Corba
12
Étapes de mise en œuvre Corba
Spécification interface IDL
Compilation interface IDL
Implantation des objets Corba
Implantation du serveur
Enregistrement du serveur
Implantation du client
Côté client Côté serveurUtilisation du service Nommage
13
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
14
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
15
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
16
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
17
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
18
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é ?
19
Diagramme d ’interactionStub Skeleton Implementation
invoke
Marshal paramSend req.
Unmarshal paramInvoke impl.
Return resultReturn return or exc.Marshal return or exc.Send reply
Unmarshal replyReturn value or exc
20
Passage de paramètres
21
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
22
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 !!!
23
Passage de paramètresObjets 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
24
Passage de paramètresObjets 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
25
Passage de paramètresObjets locaux – exemple RMI
• Diagramme de classes
26
Passage de paramètresObjets locaux – exemple RMI
• La classe StateObject
27
Passage de paramètresObjets locaux – exemple RMI
• L'interface StateChanger
28
Passage de paramètresObjets locaux – exemple RMI
• La classe StateChangerImpl
29
Passage de paramètresObjets locaux – exemple RMI
• Le programme serveur
30
Passage de paramètresObjets locaux – exemple RMI
• Démarrage du serveur– On lance le rmiregistry– On lance le serveur
31
Passage de paramètresObjets locaux – exemple RMI
• Le programme client
32
• 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
Passage de paramètresObjets locaux – exemple RMI
33
Passage de paramètresObjets locaux – exemple RMI
34
Passage de paramètresObjets 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
35
Passage de paramètresObjets 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
36
Passage de paramètresObjets 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
37
Passage de paramètresObjets distants – exemple RMI
• Diagramme de classes
38
Passage de paramètresObjets distants – exemple RMI
• L'interface HelloAccessor
39
Passage de paramètresObjets distants – exemple RMI
• La classe HelloAccessorImpl
40
Passage de paramètresObjets distants – exemple RMI
• Le serveur HelloAccessorServer
41
Passage de paramètresObjets 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...
42
Passage de paramètresObjets distants – exemple RMI
• Le client HelloAccessorClient
43
Passage de paramètresObjets 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 !
44
Objets distants – exemple RMI
45
Passage de paramètresConclusion
• 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 !!!
46
Déploiement
47
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
48
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é
49
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
50
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)
51
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 chargejava.rmi.server.RMIClassLoader
52
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
53
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
54
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
55
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...
top related