Invocation de Méthode à des Objets distants RMI et Corba

Présentation au sujet: "Invocation de Méthode à des Objets distants RMI et Corba"— Transcription de la présentation:

1 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 Il faudrait ajouter quelque chose tôt sur le marshalling et quelque chose sur le protocole d ’application…. Et le déploiement

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é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() ;

3 Premières informations
Comparaison Corba RMI Premières informations

4 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…)

5 Panorama JRMP Client Stub Remote reference layer Serveur Skeleton
TCP/IP, Unicast

6 CORBA par comparaison IIOP Client Stub Object request broker Serveur
Skeleton Object request broker Interface IDL TCP/IP, Unicast

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
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 Location transparency The client does not know or care whether the target object is local to its own address space, is implemented in a different process on the same machine, or is implemented in a process on a different machine. Server processes are not obliged to remain on the same machine forever; they can be moved around from machine to machine without clients becoming aware of it (with some constraints, which we discuss in Unit 22). • Server transparency adire dans la transparence The client does not need to know which server implements which objects. La liaison avec les langages de programmation : assurés par des transformations frd IDL en construction directement exploitables via un précompilateur IDL. La transparence des invocations: le choix du moyen de transport en fonction de la localisation des objets qui est alors transparente même processus, différents process même machine, ou … invocations d ’opérations statiques et dynamiques : statique la + utilisée elle permet aux programmeurs d ’écrire les invocations sur les objets en utilisant les souches de communication produites par un précompilateur IDL. (typage est vérifié dans la phase de compilation.) dynamique utilise les interfaces des objets durant l exécution grâce à un référentiel des interfaces. à partir des info extraites , un pgme peut construire dynamiquement les invocations à destination des objets. Les opérations invoquées ne sont connues qu ’à l  ’exécution donc mécanisme plus souple mais aussi plus coûteux en temps d ’exécution. Un système auto-descriptif : Le bus contient des métaDonnées décrivant les interfaces des objets. Celles-ci sont stockées dans le référentiel des interfaces. Utilisées entre autres par des outils tels aue les générateurs de code à la volée, ateliers de G.L. ou navigateurs d ’interfaces. Activation automatique des objets : les objets sont en mémoire uniquement s ’ils sont utilisés par une application cliente. communication entre différents bus: pas de technologie imposée pour l ’implantation du bus. cependant des règles et protocoles sont définis pour permettre le dialogue entre différentes implantations. soit par des conversion de requêtes entre bus, soit par l ’usage de protocole commun. 2 familles : 1) Protocoles à usage général instancié à partir du protocol générique (General Inter-ORB Protocol GIOP) et 2) celle dédiée spécifiquement à des environnements distribués (Environment Specific In.. ESIOP) . IIOP (Internet ..) est l ’instanciation de GIOP sur la couche de transport TCP/IP de l ’internet.

9 Modèle de référence OMA
Objets applicatifs Spécifiques Finance Télécom Santé Interfaces de domaine Workflow DataWare IHM Administration Utilitaires communs CORBA Bus d’objets répartis (O.R.B.) Licences Transactions Persistance Propriétés Changements Events Nommage Vendeur Sécurité Relations Collections Temps Externalisation Interrogations Cycle de vie Concurrence Services objet communs (CORBA Services) Orienté Système : ORB et services Objets ; Orienté application : applicatioon object et Common Facilities Pour favoriser l’intégration et l’interopérabilité d'applications réparties hétérogènes, l’OMG propose un guide décrivant une architecture de gestion des objets appelé l’Objet Management Architecture Guide. Cette archi est globale car elle vise à prendre en compte toutes les fonctionnalités nécessaires à la construction d’appli dans un environnement ouvert et distribué aussi bien au niveau des composantes techniques et/ou système (transactions, persistance) qu ’au niveau des composantes proches des applications comme l ’interface utilisateur ou les documents composites. De plus la modularité de ces composantes permet de ne construire une application qu ’en choisissant les services strictement nécessaires. Cette architecture structure ces fonct. en 4 grandes catégories de composantes : Le bus d ’objets répartis (ORB object Request Broker) :assure le transport des requête et masque tous les pbmes d hétérogénéité : il permet aux objets de communiquer de façon transparente. Dans la 2.0 l ’interopérabilité est étendue aux bus…(clef de voûte) Les services objet Commun :spécifiés par des IDL, abstractions aux fonctions système de base telles que nommage, persistance, cycle de vie, transactions, sécurité (16 services de base ont été spécifié ….). Cette base permet d ’écrire des appli indépendantes des mécanismes sous-jacent du système et donc la portabilité de ces applis. annuaire (vendeur et Nommage), cycle de vie, relations, events, transactions... Utilitaires communs ouCorba facilities : canevas de composants logiciels(frameworks) : prise en charge de fonctionnalités communes à beaucoup d ’applications telles que interface utilisateur, gestion de l ’info, administration du système, gestion des tâches Interfaces de domaine : modélisent des domaines d ’activités (santé(dossier médicale), finance(monnaie électronique), télécom, échanges commerciaux : aussi dits objets de métier. Idée: permettre l ’interopérabilité entre des systèmes d ’informations d ’entreprises d ’un même métier : Business Object Frameworks BOFs objets applicatifs : objets de métiers ?? développés spécifiquement pour une application. Très spécifiques, ils ne sont pas standardisés et sont simplement décrits par une ID, mais ils peuvent le devenir... 11 11

10 Rappel processus RMI Interface HelloWorld Interface HelloWorld
Code du client Classe d’implémentation HelloWorldImpl Code du serveur Utilisation du registry

11 Corba : Interface décrite avec IDL
Contrat IDL Client d’objets Fournisseur d ’objets Stub IDL Bus CORBA Squelette IDL Après ce tour d ’horizon de l ’env. Corba, interessons nous à présent au langage de définition d ’interface définit par l ’OMG, OMG IDL Une interface OMG IDL correspond à l ’abtraction d ’un type d ’objet, API que l'ont veut rendre publique elle contient donc les opérations exportées et utilisées par les autres objets mais pas forcément toutes les méthodes implantés par la classe d'objet. Java d ’un côté, C++ de l ’autre. Ce contrat isole le client des détails d ’implantation des objets I;E; de l ’ens. des logiciels et du matériel choisi pour leur implantation. Le fournisseur peut lui implanter plusieurs versions des objets en fonction de la qualité de service demandée. Il permet également l ’indépendance vis à vis du bus. Objets Corba 17 17

12 Étapes de mise en œuvre Corba
Spécification interface IDL Compilation interface IDL Implantation des objets Corba Enregistrement du serveur peut se faire aupres d'un service de nommage Implantation du serveur Implantation du client Enregistrement du serveur Côté client Côté serveur Utilisation 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 ’interaction
Stub Skeleton Implementation invoke Marshal param Send req. Unmarshal param Invoke impl. Return result Return return or exc. Marshal return or exc. Send reply Unmarshal reply Return 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è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

24 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

25 Passage de paramètres Objets locaux – exemple RMI
Diagramme de classes

26 Passage de paramètres Objets locaux – exemple RMI
La classe StateObject

27 Passage de paramètres Objets locaux – exemple RMI
L'interface StateChanger

28 Passage de paramètres Objets locaux – exemple RMI
La classe StateChangerImpl

29 Passage de paramètres Objets locaux – exemple RMI
Le programme serveur

30 Passage de paramètres Objets locaux – exemple RMI
Démarrage du serveur On lance le rmiregistry On lance le serveur

31 Passage de paramètres Objets locaux – exemple RMI
Le programme client

32 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

33 Passage de paramètres Objets locaux – exemple RMI

34 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

35 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

36 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

37 Passage de paramètres Objets distants – exemple RMI
Diagramme de classes

38 Passage de paramètres Objets distants – exemple RMI
L'interface HelloAccessor

39 Passage de paramètres Objets distants – exemple RMI
La classe HelloAccessorImpl

40 Passage de paramètres Objets distants – exemple RMI
Le serveur HelloAccessorServer

41 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...

42 Passage de paramètres Objets distants – exemple RMI
Le client HelloAccessorClient

43 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 !

44 Objets distants – exemple RMI

45 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 !!!

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 charge java.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 Java Distributed Computing
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...