• I. Introduction
  
• II. Mise en place de l'environnement
  
• III. Exercice 1
• IV. Exercice 2
• V. Exercice 3

Les parties IV et V comportent des exercices à rendre.

I. Introduction

II. Mise en place de l'environnement

Nous faisons maintenant l'hypothèse que vous utilisez zsh et que vous avez récupérer les sources des exercices, puis, utilisé la commande

tar xvf tp-corba-java.tar

pour les extraire de l'archive dans votre répertoire principal. Votre répertoire principal doit alors contenir le répertoire TP-CORBA. Dans ce dernier, se trouve le fichier corba.zsh. Celui-ci comprend la définition des variables nécessaires au bon fonctionnement de l'ORB. Pour positionner ces variables, il suffit alors d'utiliser la commande :

source corba.zsh

dans toutes les fenêtres où vous exécuterez des processus utilisant CORBA.

III. Exercice 1

Le premier exercice consiste en un exemple simple d'application client/serveur CORBA. Il s'agit de l'exemple présenté lors du TP RPC. Le serveur exporte deux méthodes (bid_carre et bid_rac) 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 :

• Passer les commandes :

  cd TP-CORBA/EXO1
  make

  pour générer les souches et squelettes et pour compiler le client et le serveur. Le code Java généré par le compilateur IDL est placé dans le répertoire tpcorba ; quant aux fichiers .class, ils sont stockés dans le répertoire classes/tpcorba.

• Lancer le serveur par la commande java tpcorba.Serveur.

• 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 la référence de l'objet qu'il gère (fichier calcul.ref), il est donc nécessaire de lancer le client et le serveur dans le même répertoire.

On vous demande d'observer par quelles étapes passent le serveur et le client pour initialiser l'objet CORBA, et pour invoquer les méthodes de l'objet. Vous regarderez plus précisément les points suivants :

1. Quelles sont les interactions entre le serveur et la BOA ?

2. 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) ?

3. 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) ?

4. Chercher dans le squelette (classe _calculImplBase.java) où se situent les appels à l'implémentation de l'objet (classe calcul_Impl.java).

5. Enfin, identifier dans le fichier calcul.ref (fichier qui contient la référence d'objet) l'adresse IP où se trouve le serveur et le port TCP utilisé pour les interactions entre les clients et le serveur. Vous utiliserez à cet effet la commande :

   iordump `cat calcul.ref` (attention aux back quotes!)

   qui affiche à l'écran le contenu de la référence d'objet.

Pour vous aider, voici un bref rappel des principales règles du mapping IDL/Java qui vont vous être nécessaires dans ce TP (le mapping complet est accessible à cet endroit . Un résumé est donné en annexe dans le 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.

IV. Exercice 2

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

On se propose dans ce deuxième exercice d'ajouter une fonctionnalité de ``mémoire'' à notre calculatrice. La mémoire est implantée sous la forme d'un attribut CORBA. On rappelle qu'un attribut d'interface CORBA est une donnée encapsulée dans un objet. Un attribut peut être consulté et/ou modifié à distance par un client. Dans notre cas, il s'agit d'un attribut en lecture seule.

Dans le mapping IDL/Java, un attribut en lecture/écriture nécessite la production de deux méthodes dans la souche. Le nom de ces méthodes est le nom de l'attribut lui-même. Ces méthodes sont utilisées par les clients pour manipuler les attributs à distance. Une seule méthode est générée dans le cas d'un attribut en lecture (voir les souches générées pour de plus amples informations).

On vous demande de :

1. Compléter la description IDL tpcorba.idl en ajoutant à l'interface calcul, les méthodes ajouteMemoire, soustraitMemoire, multiplieMemoire et miseAZero. Chacune de ces méthodes prend un unique paramètre en in de type double (sauf miseAZero qui ne prend pas de paramètre). Elle mettent à jour la mémoire mais ne renvoient pas d'information au client. La méthode diviseMemoire doit lever une exception en cas de tentative de division par zéro. Une exception CORBA est un mécanisme proche d'une exception Java : une exception CORBA est un événement déclenché lors de l'invocation d'un objet et qui est transmis à l'appelant de cet objet. Appelant et appelé ne sont pas nécessairement localisés sur la même machine.

2. Compléter la définition de la classe d'implémentation dans le fichier calcul_impl.java.

3. Compléter le client afin de tester les quatre méthodes implantées. Le client doit afficher l'état initial de la mémoire, puis effectuer des opérations sur celle-ci. Enfin, avant de se terminer, il devra afficher l'état final de la mémoire.

4. Que se passe-t-il lorsque la mémoire est utilisée par plusieurs clients successivement ?

V. Exercice 3

Une solution possible au problème posé par la quatrième question du deuxième exercice est d'utiliser plusieurs instances de l'interface ``calcul''. Pour ce faire, nous allons définir une usine à objets. Une usine à objets offre des services permettant de créer et gérer dynamiquement des objets CORBA (voir partie 5 du cours). Nous allons donc offrir aux clients la possibilité de créer et détruire dynamiquement des objets ``calcul'' et éventuellement de se partager un même objet.

Le serveur doit maintenant gérer un ensemble de calculatrices. Pour chaque calculatrice, il maintient une référence sur l'objet CORBA, un identifiant (un nom sous la forme d'une chaîne de caractères utilisé par les clients pour désigner une calculatrice particulière) ainsi qu'un nombre d'utilisateurs (nombre de clients qui manipulent la calculatrice).

Dans cet exercice, il vous est demandé de :

1. Modifier le fichier tpcorba.idl en rédigeant pour l'interface usine les quatre méthodes décrites ci-dessous (n'oubliez pas de déclarer les exceptions utilisées par chaque méthode) :

2. Compléter l'implantation de l'interface usine (c'est à dire le fichier usine_impl.java).

3. Tester cette nouvelle interface avec le client.

Les méthodes qui vous devez ajouter au fichier tpcorba.idl sont :

1. La méthode creation qui prend :
   • un paramètre en inout retournant une référence sur un objet ``calcul''.
   • un paramètre en in de type string désignant le nom de la calculatrice à créer.

   Cette méthode doit créer une nouvelle instance de la classe calcul_impl, puis l'enregistrer auprès de la BOA grâce à la méthode obj_is_ready. Enfin, elle doit renvoyer au client une référence sur le nouvel objet CORBA créé (rappel : le mot clef interface est un constructeur de type, ``calcul'' est donc un type IDL).

   La méthode doit lever :

   • une exception dont le nom sera calculatriceDejaExistante si l'objet demandé existe déjà.
   • une exception plusDePlace si le nombre d'objet maximal est atteint.

2. La méthode suppression qui prend un paramètre en in de type string désignant le nom de la calculatrice à détruire. L'objet CORBA pourra être désactivé grâce à la méthode deactivate_obj de la BOA (cette méthode nécessite un seul paramètre : une référence d'objet CORBA).

   La méthode doit lever :

   • une exception calculatriceEnUtilisation si l'objet à supprimer est encore utilisé ( nombre d'utilisateurs associé à l'objet différent de zéro).
   • une exception calculatriceInconnue si le paramètre string adresse une calculatrice qui n'existe pas.

3. La méthode connecter qui prend :
   • un paramètre en inout retournant une référence sur l'objet CORBA.
   • un paramètre en in de type string désignant le nom de la calculatrice concernée.

   Cette méthode doit incrémenter le nombre d'utilisateurs associé à une calculatrice. Par contre, elle ne crée pas d'objet CORBA : elle permet d'avertir l'usine à objets qu'un client souhaite utiliser une calculatrice déjà existante. Elle doit renvoyer au client une référence sur l'objet CORBA concerné. La méthode doit lever une exception si le paramètre string adresse une calculatrice inexistante (exception calculatriceInconnue).

4. La méthode deconnecter qui prend un paramètre en in de type string désignant le nom de la calculatrice concernée. Cette méthode ``déconnecte'' un utilisateur d'une calculatrice. Elle permet d'avertir l'usine à objets que le client ne souhaite plus utiliser la calculatrice.

   La méthode doit lever :

   • l'exception aucunUtilisateur si l'objet n'a déjà plus d'utilisateur (c'est à dire si le nombre d'utilisateur associé à l'objet est égal à zéro).
   • l'exception calculatriceInconnue si le paramètre string adresse une calculatrice inexistante.