Exercice 1

Les sources de cet exercice se trouvent dans le répertoire ``. /TP-CORBA/EXO1''.

Le premier exercice consiste en un exemple simple d'application client/serveur CORBA. Il est constitué de deux méthodes ( $calcule\_carre$ et $calcule\_racine$) définies dans l'interface IDL calcul (fichier tpcorba.idl). Dans cet exercice, vous devez compiler et exécuter l'application. Pour ce faire, il faut d'abord passer les commandes :

cd TP-CORBA/EXO1 
make

qui compilent l'ensemble des sources. Vous noterez que la compilation est effectuée en deux phases :

1.

L'invocation du compilateur jidl qui va générer les souches et les squelettes à partir du fichier tpcorba.idl. Le code Java généré par le compilateur IDL est placé dans le répertoire tpcorba.

2.

La compilation de chaque classe Java par le compilateur javac. Pour chaque fichier source (préfixé par .java et contenant une seule classe), un fichier .class est généré. Ce dernier contient le code intermédiaire Java (code qui sera interprété par la machine virtuelle Java). Notez que contrairement à un langage classique (ex : C), il n'y a pas d'édition des liens : lorsqu'un utilisateur demande l'exécution d'une classe Java, la machine virtuelle se charge de lire les fichiers .class au fur et à mesure des besoins. Le code intermédiaire Java est stocké dans le répertoire classes/tpcorba.

Il est maintenant possible de lancer le client et le serveur :

• Lancer le serveur par la commande java tpcorba.Serveur. Cette commande permet d'exécuter la classe Java Serveur par la machine virtuelle (cette dernière est encapsulée dans la commande java). A cette instant, le code Java contenu dans le fichier Serveur.class est interprété par la machine virtuelle. L'exécution déclenche le chargement successif de très nombreuses autres classes, et en particulier du fichier $\_calculImplBase$.class qui n'est autre que le squelette CORBA.

• Enfin, lancer le client par java tpcorba. Client num où num est le nombre sur lequel le serveur doit effectuer le calcul. Attention : le serveur écrit sur disque (fichier calcul.ref) la référence de l'objet qu'il gère ; c'est-à-dire un pointeur distant sur l'objet. Il est nécessaire de lancer le client et le serveur dans le même répertoire. Ainsi, si le client et le serveur sont lancés sur des machines différentes, le serveur NFS joue, d'une certaine manière, la fonction de serveur de nom.

On vous demande de regarder quelles sont les étapes que le serveur et le client réalisent respectivement, pour initialiser l'objet CORBA, et pour invoquer les méthodes de l'objet. Il n'y a aucun programme à modifier dans cet exercice. Vous regarderez plus précisément les points suivants :

• Quelles sont les interactions entre le serveur et la BOA ?

• Dans la souche (classe StubForcalcul.java), où se trouvent la construction et l'émission de la requête vers le serveur ? Comment le client obtient il la souche pour invoquer l'objet (voir la méthode narrow dans la classe calculHelper.java) ?

• Chercher dans le squelette (classe $\_calculImplBase$.java) où se situent les appels à l'implémentation de l'objet (classe $calcul\_Impl$.java).

• On va inspecter le contenu d'une référence sur un objet CORBA. Normalement, le contenu d'un tel pointeur est opaque au client (ce dernier ne cherche pas à connaître son contenu). Pour cela, on utilise la commande suivante (après exécution de l'application) :

  iordump `cat calcul.ref`
  

  (attention au back-quote). Cette commande affiche le contenu de la référence gérée par le serveur. Quels sont les informations qui permettent de désigner cet objet chez le serveur ?

• Enfin, quelle est la relation entre la classe d'implémentation (classe $calcul\_Impl$.java) et le squelette (le squelette est défini par la classe $\_calculImplBase$.java dans le répertoire tpcorba) ?

Vous trouverez ici le manuel en ligne d'ORBacus.

Pour vous aider, voici une brève explication des principales règles du mapping IDL/Java qui vont vous être nécessaires dans ce TP (le mapping complet est accessible à cet endroit. Les principales règles sont (cf. partie 7.2 du support de cours) :

• Les squelettes et les souches sont implantés par une classe Java.
• A chaque type simple IDL correspond un type simple Java (dans cet exercice, les types IDL long, double et string sont directement mappés en types Java int, double et String).
• Pour les signatures de méthodes avec des paramètres en in, le mapping définit une méthode IDL :

  void methode(in type t);
  

  en une méthode Java :

  void methode(type t);
  

• Pour les signatures de méthodes avec des paramètres en out ou en inout, le mapping définit une méthode IDL :

  void methode(out type t1, inout type t2);
  

  en une méthode Java :

  void methode(typeHolder t1, typeHolder t2);
  

  Où typeHolder est une classe encapsulant une variable de type type (attribut value). En effet, les paramètres sont passés par copie dans Java. C'est donc le champ value de la classe typeHolder qui est utilisé pour véhiculer le paramètre du serveur vers le client.