XML-RMI et passage d objets en mode valeur/résultat

Transcription

1 UFR 919 Sciences de l ingénieur Master Informatique Spécialité STL ALADYN XML-RMI et passage d objets en mode valeur/résultat version 1.2 du 24/10/2012 Jacques Malenfant professeur des universités Résumé L objectif de ce projet est de comprendre les possibilités offertes par l outil Javassist par ses capacités de génération dynamique de code, et ce par la réalisation d un système d appel de méthodes à distance en XML pour des objets répartis en Java. 1 Appel à distance L appel d une méthode à distance entre deux ordinateurs, clé de la programmation répartie, demeure un maillon relativement simpliste même dans les approches les plus sophistiquées utilisées aujourd hui dans l industrie. En effet, la plupart des protocoles qui ont été implantés à ce jour demeurent limités (comme SOAP, par exemple) ou très lourds (comme Java RMI) dès qu il s agit de passer des objets en paramètres et de les recevoir en résultat. Dans ce projet, nous allons nous poser comme défi d être capables de passer des objets en paramètres à des appels de méthodes à distance, de recevoir des objets en résultat, et de récupérer des modifications à l état des objets passés en paramètres pendant l exécution de la méthode distante. En Java RMI, pour ce faire, il faut que les objets passés en paramètres soient euxmêmes des objets distants, modifiés par des appels de méthodes distants en retour, ce qui est très pénalisant. Nous allons donc tenter une autre approche : un passage par valeur/résultat, c est-à-dire que l objet passé en paramètre sera recréé sur le site distant, modifié localement par la méthode appelée, puis retourné à l appelant pour récupérer ses modifications en fin d exécution de l appel. Dans le domaine des langages de programmation, ce genre d interaction sur les paramètres où la valeur du paramètre n est remise à jour dans le contexte de l appel qu à la fin de l exécution de la méthode appelée est généralement désignée sous le nom «d appel par valeur/résultat». 2 XML-RMI Pour se mettre dans un contexte de programmation répartie, nous allons nous baser sur une approche relativement simple : XML-RPC. XML-RPC est un protocle minimaliste d appel de procédures à distance où la sérialisation des paramètres et du résultat utilise un format XML et où la communication entre hôtes distants se fait par la protocole HTTP. Sa popularité est due à cette simplicité permettant d implanter des services Web à peu de frais. La spécification XML-RPC prévoit uniquement les types suivants comme paramètres ou résultat d un appel : entiers (int), réels (double), booléens (boolean), chaînes de caractères (string),

2 moments dans le temps (datetime ISO8601), binaire (base64), des tableaux (array) de valeurs homogènes des autres types de la norme, et des valeurs structurées struct contenant des champs nommés avec des valeurs hétérogènes des autres types de la norme. Plus précisément, voici un exemple d appel en XML-RPC : <?xml version="1.0"?> <methodcall> <methodname>examples.getstatename</methodname> <params> <param><value><int>41</int></value></param> </params> </methodcall> La spécification complète de XML-RPC se trouve à l URL spec.html. Plutôt que le protocole HTTP pour échanger entre hôtes, nous verrons plus loin que notre utilisation se fera plutôt dans le contexte d une communication par «sockets». Le projet consiste à implanter ce protocole en lui ajoutant un nouveau type de données «object» pour obtenir ce qu on va appeler du XML-RMI. La figure 1 présente un schéma Relax-NG permettant de valider le contenu XML d une requête ou d un résultat en XML-RMI. On constate que la spécification distingue les appels de méthodes des résultats qui seront retournés. Un appel contient un nom de méthode puis les valeurs des paramètres. Les types conservés de la spécification XML-RPC sont, comme indiqué plus haut : int (ou i4), double, boolean (mais avec les valeurs numérioques explicites 0 et 1, et non true et false), string, datetime, base64 (binaire encodé selon la norme), array et struct. En XML-RMI, nous ajoutons le type object pour passer des objets en paramètre ou les retourner en résultat, ce qui sera discuté dans la prochaine section. 3 Des objets en XML pour XML-RMI Le cœur du projet va consister à effectivement réaliser le passage d objets en paramètres pour ce protocole XML-RMI que nous inventons pour l occasion. Le principe est de sérialiser les objets sous la forme d une liste de champs («fields») et d une liste de méthodes. Les champs seront définis par un nom et une valeur initiale, alors que les méthodes seront données sous la forme d un texte représentant le code de la méthode dans un certain langage de programmation, comme Java. Quelle est l idée? D une part, il s agit d être capables de sérialiser des objets pour les passer en paramètre, ce qui se réalise à l aide du schéma RelaxNG de la figure 2. Certes, une telle sérialisation n est pas nouvelle, puisque la norme RMI de Java le fait déjà. Mais ici, on ne sérialise pas l objet, on crée plutôt un représentant de l objet qui va être transféré côté appelé pour y être utilisé tout au long de l exécution de la méthode appelée. Cette idée a plusieurs avantages : ne pas avoir besoin de revenir côté appelant à chaque fois que la méthode appelée veut utiliser l objet passé en paramètre, permettre à l appelant de ne passer qu une partie de l objet à l appelé (ne pas y mettre tous les champs ni toutes les méthodes), ce qui est utile pour des objets dont une partie n a pas à être vue par l appelé (par exemple, pour des raisons de sécurité des données), rendre le code appelé plus indépendant que dans SOAP de la structure du XML passé en paramètre en permettant d appeler les méthodes de l objet plutôt que d accéder directement aux champs, et améliorer l interopérabilité, en ayant la possibilité de passer des objets lors d appels entre objets répartis écrits dans différents langages de programmation (par exemple, un objet en Python peut appeler un objet écrit en Java, en prenant soin de définir en Java les méthodes des objets passés en paramètres en XML).

3 # ***************************************************************************** # ALADYN -- Architectures logicielles pour l auto-adaptabilité dynamique. # Copyright (C) 2012 <Jacques.Malenfant@lip6.fr> # GPL version>=2 # ***************************************************************************** start = methodcall methodresponse #****************************************************************************** # Appel par le client #****************************************************************************** methodcall = element methodcall { methodname, element params { param+? methodname = element methodname { xsd:string {pattern = "[a-za-z0-9_\.,/]+" param = element param { value value = element value { typedvalue text typedvalue = integer boolean stringval # string is a keyword double datetime base64 array struct object integer = element i4 { xsd:int element int { xsd:int boolean = element boolean { "0" "1" stringval = element string { text double = element double { xsd:double datetime = element datetime.iso8601 { xsd:string {pattern = # xsd:date does not allow " T12:10:56" "[0-9]{4[0-1][0-9][0-3][0-9]T[0-2][0-9]:[0-5][0-9]:[0-5][0-9]" base64 = element base64 { xsd:base64binary array = element array { element data { value+ struct = element struct { namedmember+ namedmember = element member { membername & value membername = element name { xsd:nmtoken object = external "object.rnc" #****************************************************************************** # Retour du resultat du client #****************************************************************************** methodresponse = element methodresponse { fault element params { param+ fault = element fault { faultvalue faultvalue = element value { faultstruct faultstruct = element struct { (faultcode, faultstring) (faultstring, faultcode) faultcode = element member { element name { "faultcode" & element value { integer faultstring = element member { element name { "faultstring" & element value { stringval text Figure 1 Le schéma RelaxNG pour XML-RMI.

4 # ***************************************************************************** # ALADYN -- Architectures logicielles pour l auto-adaptabilité dynamique. # Copyright (C) 2005 <Jacques.Malenfant@lip6.fr> # GPL version>=2 # ***************************************************************************** start = object object = element object { attribute oid { xsd:anyuri, attribute type { xsd:nmtoken?, element fields { field*, element methods { method* field = element field { attribute name { xsd:nmtoken, parent value # value pattern as defined in the parent schema method = element method { attribute language { xsd:nmtoken?, # programming language used text # method definition Figure 2 Le schéma RelaxNG pour la représentation des objets en XML-RMI. Bien sûr, une fois l appel reçu côté appelé, l objet en XML ne peut être utilisé tel quel. C est là où la réflexion et les approches vues en ALADYN entrent en jeu pour permettre de créer à la volée un objet Java à partir de l objet XML. Nous allons poser comme hypothèse que toutes les méthodes qui peuvent être appelées par XML-RMI sont définies avec une signature où tous les types des paramètres sont soit des types primitifs du protocole XML-RPC, soit des objets dont le type est donné par une interface Java. Cette interface peut être déterminée soit par le contexte, lorsque l objet correspond à un paramètre de la méthode appelée sur le serveur, ou être nommée explicitement dans l attribut type (optionnel) de la représentation XML-RMI lorsque l objet est utilisé dans un autre contexte (dans un tableau, comme valeur d un champ dans un objet,...). L objet XML devra donner une définition pour chacune des méthodes apparaissant dans l interface Java en question. En utilisant Javassist à la réception de l appel en XML-RMI, vous allez créer une classe pour représenter cet objet puis instancier cette classe et initialiser l objet obtenu avant de l utiliser dans l appel à la méthode de l objet appelé. Par exemple, soit un objet réparti offrant une méthode display de la forme suivante : public void display(stringable s) { System.out.println("Un point 2D : " + s.tostring()) ; L interface Stringable typant le paramètre s est définie de la manière suivante : public interface Stringable { public String tostring() ; Un exemple de contenu XML-RMI pour l appel de la méthode display avec un paramètre objet correspondant à l interface Stringable prend la forme suivante :

5 <methodcall> <methodname>display</methodname> <params> <param> <value> <object oid=" type="stringable"> <fields> <field name="x"><value><double>10.0</double></value></field> <field name="y"><value><double>20.0</double></value></field> <field </fields> <methods> <method language="java"> public String tostring() { return this.x + this.mark + this.y ; </method> </methods> </object> </value> </param> </params> </methodcall> On voit que cet objet est un point 2D avec trois champs représentant l abcisse, l ordonnée et un caractère utilisé comme séparateur pour produire une représentation sous forme de chaîne de caractères avec le format suivant : 10.0@20.0. Mais la production de ce format à partir des données est masquée par la méthode tostring de l interface Stringable. Notez que le schéma RelaxNG de XML-RMI diffère de celui de XML-RPC en deux points. D abord, on introduit le type object comme déjà mentionné. Mais il y a une autre modification au niveau de la réponse. Là où XML-RPC ne prévoit qu une valeur de retour, nous permettons plusieurs «paramètres» en retour. Par convention, le premier paramètre en retour sera toujours le résultat de la méthode appelée, mais l appelé poura inclure tout ou partie des objets passés en paramètres lors de l appel pour retourner à l appelant les nouvelles valeurs des champs de ces objets après exécution de la méthode. Ainsi, l appelant pourra mettre à jour les valeurs des champs dans les objets originaux de son côté. Mais pour cela, il faut qu il puisse identifier les objets retournés. C est pour cela que la représentation du type object prévoit un identifiant d objets unique de la forme d une URI. L appelant peut donc mémoriser lors de l appel la correspondance entre les identifiants uniques et les références locales à ses objets, et au retour utiliser cette correspondance pour mettre à jour l objet original. Ainsi, dans l exemple précédent, la réponse aurait la forme suivante : <methodresponse> <params> <param> <value>void</value> </param> <param> <value> <object oid=" <fields> <field name="x"><value><double>10.0</double></value></field> <field name="y"><value><double>20.0</double></value></field> <field name="mark"><value><string>@</string></value></field>

6 </fields> <methods></methods> </object> </value> </param> </params> </methodresponse> Dans cet exemple, on constate que le retour est void, car la méthode display n a pas de valeur de retour (mais cela aurait pu être une valeur au sens value de XML-RMI dans un autre cas). L objet apparaissant dans le retour est identique à celui passé en paramètre lors de l appel car on présume que display ne modifie pas la valeur de son paramètre. Néanmoins, l appelé peut le retourner et l appelant le traiter sans chercher à savoir s il a été modifié ou non. Au retour, seuls les champs sont utiles, et on arrive à déterminer qu il s agit d un objet précédemment passé en paramètre par l identifiant unique oid qui est le même qu un de ses objets locaux. Une manière systématique d implanter un objet en Java pouvant être passé en paramètre via XML-RMI serait de lui faire implanter l interface suivante : public interface XMLRMISerializable { public String toxml(class<?> inter) ; public void updatefromxml(org.w3c.dom.element thexml) ; La méthode toxml sert à produire la sérialisation en XML souhaitée en fonction de l interface attendue par le service (on pourra ainsi produire un XML différent en fonction de l interface demandée), alors que la méthode updatefromxml met à jour l objet à l aide de la réprésentation en DOM de l objet en XML extraite de la réponse de l appel distant. De cette manière, le déroulement standard d un appel distant serait : 1. Encoder l appel en XML-RMI en utilisant les méthodes toxml des objets à passer en paramètres pour obtenir leur représentation en XML. 2. Envoyer l appel sur le «socket» de l objet appelé. 3. Récupérer la réponse en XML pour en décoder le résultat et mettre à jour pour chacun des objets en retour les objets originaux en appelant la méthode updatefromxml de ces derniers. Cette mécanique de mise à jour en retour ne fonctionenra que dans le cadre d un appel. Le résultat de la méthode, bien que pouvant être un objet, ne sera pas considéré comme partagé entre l appelé et l appelant. Ceci pour limiter la difficulté du projet, sinon il faudra gérer ces objets partagés sur l ensemble d une conversation entre deux ou plusieurs objets. Mais si vous souhaitez vous lancer dans cette direction, pourquoi pas? Par ailleurs, pour ne pas avoir à réimplanter la sérialisation des champs et la récupération des valeurs en retour pour chaque objet pouvant être passé en paramètre ou reçu en résultat, l annotation suivante permettra de retouver les champs à sérialiser et à mettre à jour au XMLRMIField { String serializationname() ; // nom à utiliser dans la sérialisation XML-RMI String serializationtype() ; // type XML-RMI à utiliser dans la sérialisation Par exemple, la classe Point suivante pourrait avoir servi à produire l objet passé en paramètre de l exemple d appel précédent :

7 public class Point protected double a protected double b protected char marque ; Grâce à ces annotations, il vous sera possible d implanter une fois pour toute par réflexion la sérialisation des champs et la récupération des valeurs en retour. Notez bien que cette annotation permet d utiliser un nom de champ et un type de valeur en XML qui est différent de celui utilisé en Java ; vous devrez faire les conversions nécessaires dans les deux sens. 4 Intégration dans un modèle d objets répartis Pour mettre en œuvre le concept d objets en XML dans un contexte réaliste, vous devrez le tester avec un modèle d objet réparti volontairement simple pour rester réalisable dans le cadre de ce projet. En Java, le modèle d objets répartis le plus simple est celui proposé autour de l appel de méthodes à distance RMI. Un objet réparti serveur RMI implante (au moins) une interface Java qui hérite elle-même directement ou indirectement de l interface java.rmi.remote, ce qui lui permet de publier sa propre référence sur l annuaire RMI (RMIRegistry) et à ses cleints de la récupérer par une requête à cet annuaire. L appel à distance lui-même se fait en utilisant la référence RMI ainsi obtenue, et le protocole d échange entre machines virtuelles (et éventuellement hôtes) demeurant caché dans l implantation de RMI. Pour notre XML-RMI, l idée sera la suivante : la référence à un objet réparti se fera grâce à l identification Inet ou l adresse IP de l hôte exécutant la MV Java où se trouvbe l appelé et du numéro de port sur lequel cet objet va écouter les requêtes qui lui seront faites sous forme d appel de méthode à distance utilisant le protocole XML-RPI décrit précédemment. Un objet réparti sera donc un objet possédant son propre fil d exécution («thread») et qui va répétitivement écouter sur un «socket» les requêtes en XML-RMI, les exécuter puis retourner le résultat dans le format XML-RMI à son appelant. Des informations sur la programmation de communication par «socket» en Java sont largement disponibles sur le WWW. Pour simplifier la réalisation du projet, vous pourrez considérer que l adresse IP de l hôte sur lequel se trouve l objet et le numéro de port sur lequel ce dernier écoute sont des informations connues à l avance et considérée comme constante par le client. Les étudiants les plus performants pourront étendre leur projet en ajoutant un annuaire pour le protocole XML-RMI permettant de centraliser les références et les requêtes pour la connexion en s inspirant de l annuaire RMI Registry de Java. 5 Réalisations attendues Nous vous demandons de réaliser le projet sous Eclipse en prévoyant tout le code nécessaire pour lancer l application et dans votre rendu vous devrez également joindre des tests unitaires JUnit dans des sous-packages tests. Modalités de remise des projets : Le projet se fait obligatoirement en binôme. Tous les fichiers du projet doivent comporter les noms (authors) de tous les auteurs.

8 Le projet est à rendre le vendredi 16 novembre 2012 à minuit au plus tard sous la forme d une archive tgz si vous travaillez sous Unix ou zip si vous travaillez sous Windows que vous m enverrez à Jacques.Malenfant@lip6.fr comme attachement fait proprement avec votre programme de gestion de courrier préféré. Donner pour nom à votre archive vos numéros de dossier d étudiants sous la forme n-n (ex. : tgz). Attention, peu importe le système d exploitation sur lequel vous travaillez, il faudra que votre projet s exécute correctement sous Eclipse en Mac Os X (que j utilise) Votre projet utilisera JUnit pour faire des tests de vos classes. Il comportera aussi des classes concrètes (application) permettant de réaliser les tests. Tous vos tests seront regroupés dans un répertoire spécifique tests au même niveau que le répertoire src dans votre projet Eclipse. Utilisez exactement la même structure de paquetage dans le répertoire tests que dans le répertoire src. Le code doit être documenté en Javadoc (générée et incluse dans votre livraison dans un répertoire doc au même niveau que votre répertoire src) et commenté. Le code doit également être correctement formatté (indentation,...). L évaluation comportera une soutenance d une quinzaine de minutes où vous devrez démontrer votre projet (prévoyez dans le code envoyé tout ce qu il faut pour faire une telle démonstration) et répondre à des questions sur ce dernier. Les soutenances auront lieu dans la semaine du 19 novembre 2012 selon un horaire de passage qui sera publié le moment venu sur le site de l UE. Tout retard à ces soutenances entraînera son annulation et une pénalité sera appliquée sur l évaluation du projet. Tout manquement à ces règles élémentaires entraînera une pénalité dans la note du projet!