Nadir Boussoukaia

Si dessous est présenté une alternative à la méthode run() de l'ORB en Corba.

Problématique: la méthode run() de l’ORB permet de se placer à l’écoute des requêtes Corba (IIOP).
Mais elle est bloquante!

Exemple classique en C++:

//Si on a l'objet ORB obtenu par init CORBA::ORB_var orb = CORBA::ORB_init(argc, argv); // - methode 1: on place orb->run() qui est bloquant orb -> run();

Comment faire des traitements en parallèle de l’ORB dans un programme serveur?

• 1/Utiliser des Thread, par exemple JTC de Iona en C++, ou directement avec Java
• 2/Utiliser l’alternative à run() ci dessous

L’alternative à run() :

• boolean work_pending(): Non bloquant, indique si une requête Corba est arrivée
• void perform_work(): Non bloquant, traite les requêtes Corba en attente

il faut utiliser le couple d'appels orb.work_pending()/orb.perform_work() qui remplacent orb.run() et qui peuvent être utilisées dans la boucle principale du programme.

mise en œuvre en C++:

// méthode 2: on utilise orb.work_pending() qui est non bloquant     int x=0;     while (1) {             cout << "je suis dans la boucle de traitement depuis «             <<(x++)<<" secondes" << endl;         //orb.work_pending() fonctionne de paire avec orb.perform_work()             if ( orb->work_pending() )                 orb->perform_work();                    //pause 1 second (défini dans dos.h) pour éviter de bloquer le processeur         sleep(1);     }

 Mise en œuvre en Java:

int x=0;             while (true) {                 System.out.println("je suis un client qui boucle depuis "                                                 +(x++)+" secondes");                 try {Thread.sleep(1000);} catch (Exception e){;};                                 //methode 2: on utilise orb.work_pending() qui est non bloquant                 //orb.work_pending() fonctionne de pair avec orb.perform_work()                 if ( orb.work_pending() )                     orb.perform_work();                       }

 
Enfin, et pour information, le must est d'utiliser le service Corba "Event" ou "Notification" qui a été créé précisément pour gérer des messages asynchrones bidirectionnels.

Voici un exemple commenté de fichier de configuration que je propose.
Si ce fichier etait placé par exemple sur C:\ORBacus\orbacus.cfg alors l'appel serait:

java  -classpath ... -Dooc.config=C:\ORBacus\orbacus.cfg ServeurCorba

Contenu du fichier "orbacus.cfg":

#adresse du service de nom ooc.orb.service.NameService=corbaloc:iiop:localhost:1973/NameService #Tracer les connections #ooc.orb.trace.connections=2 # pour java positionne Orbacus comme ORB par defaut org.omg.CORBA.ORBClass=com.ooc.CORBA.ORB org.omg.CORBA.ORBSingletonClass=com.ooc.CORBA.ORBSingleton

Comme vous pouvez le voir, les commentaires sont précédés du "#".

La première ligne ooc.orb.service.NameService précise ou se trouve l'annuaire, et remplace avantageusement le paramètre passé en ligne de commande du style "-ORBInitRef NameService=corbaloc:iiop:localhost:1973/NameService".

Pour débugger, on activer la ligne ooc.orb.trace.connections qui montre plus de détails sur les connexions Corba.

Enfin, avec java il faut indiquer à la JVM d'utiliser Orbacus plutot que l'Orb livré avec le JDK.
Il faut pour cela positionner les variables d'environnement org.omg.CORBA.ORBClass et org.omg.CORBA.ORBSingletonClass: Les 2 dernières lignes permettent de le faire.

Elles remplacent avantageusement un appel du genre:

java -Dorg.omg.CORBA.ORBClass=com.ooc.CORBA.ORB
     -Dorg.omg.CORBA.ORBSingletonClass=com.ooc.CORBA.ORBSingleton ServeurCorba

ou encore le code suivant placé au debut du main(), avant l'appel à ORB.init() - comme je vous l'ai montré dans les corrections des TP :

// indiquer à la jvm d’utiliser l’ORB Orbacus
java.util.Properties props = System.getProperties();
props.put("org.omg.CORBA.ORBClass", "com.ooc.CORBA.ORB");
props.put("org.omg.CORBA.ORBSingletonClass", "com.ooc.CORBA.ORBSingleton");

System.out.println("init ORB");
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args, props);

Voilà.
Mettre en place un fichier de la sorte réduit fortement la longueur des lignes pour execcuter les applications Corba avec Orbacus.

Si vous essayez de faire fonctionner un programme serveur Corba, avec l'ORB Orbacus par exemple, même s'il fonctionnait sous JDK 1.4, on obtient une exception à partir de Java 1.5 du genre "java.lang.NoSuchMethodError: org.omg.PortableInterceptor.IORInterceptor_3_0.adapter_manager_state_change" 

c'est quelque chose qui ne se produira que sur JDK 1.5, 1.6 etc

La raison tient au fait que dans Java 1.4, le JDK ne contient pas d'implémentation de la classe IORInterceptor_3_0, de sorte que la version inclue avec Orbacus est la seule utilisable.

Malheureusement, Sun a ajouté une mise en œuvre de IORInterceptor_3_0 au JDK 1.5 qui diffère à la fois de la spécification CORBA et de l'implémentation faite avec Orbacus (ils utilisent un entier sur le paramètre ID alors que cela devrait être une chaîne de caractères).

Voilà pourquoi l'erreur n'apparait qu'à partir du JDK 1.5.

La propriété endorsed dirs résoud le problème. il faut positionner java.endorsed.dirs comme propriété java.
ajouter -Djava.endorsed.dirs="chemin vers le répertoire contenant les jars".
Exemple: java   -Djava.endorsed.dirs=C:\Orbacus\lib Serveur

Attention: c'est bien un répertoire qu'il faut préciser, qui contient notamment OB.JAR.

Voir explications des endorsed dirs ici http://java.sun.com/j2se/1.4.2/docs/guide/standards/ .

Voici comment configurer Orbacus pour que tous les programmes Corba sur votre machine sache retrouver l'objet notoire NameService.

Rappel: Lancer le service de nom (NameService)
lancer le name service :
    Nameserv -i -OAport 1973
ou 
   nameserv.exe -i -IIOPport 1973

Lancera l'annuaire sur le port 1973

Comment retrouver le service de nom?

pour utiliser le naming service, il faut passer en argument:
     -ORBInitRef NameService=corbaloc:iiop:localhost:1973/NameService

exemple:

     server.exe  -ORBInitRef NameService=corbaloc:iiop:localhost:1973/NameService

Configuration Globale
sinon on peut aussi faire une fois pour toute:
1 créer un fichier pointé par ORBACUS_CONFIG : C:\ORBacus\orbacus.cfg
2 créér la variable d'environnement ORBACUS_CONFIG

set ORBACUS_CONFIG=C:\ORBacus\orbacus.cfg   
  ou
  export ORBACUS_CONFIG=/home/moimeme/.orbacus.cfg   
   
3 creer une ligne dans ce fichier pour le service de nom:
    ooc.orb.service.NameService=corbaloc::localhost:1973/NameService

Et voilà! les programmes Corba sauront retrouver le nameService.

Cas des programmes ecrits en Java   

L'environnement n'est pas passé automatiquement en Java, il faut donc préciser une propriété pour transférer la valeur de ORBACUS_CONFIG


java  -classpath %CP% -Dooc.config=%ORBACUS_CONFIG% Client
ou alors passer la propriété ORBInitRef.   

Verifier le fonctionnement

Avec Orbacus il existe la commande nsadmin qui permet d'interrroger le NameService.
> nsadmin -l
 si la commande ci-dessus fonctionne, alors la variable d'environnement et le fichier ORBACUS_CONFIG sont correctement positionnés