[Corba]corba et jdk 1.4

Bonjour à tous,
je dois faire une application corba pour mes cours.
Mais voila, il est assez difficile de trouver des tutoriaux récents sur le sujet en java. J'ai bien deux trois exemples de codes mais la plupart datent du jdk 1.2 ou 1.3, et il semble que corba ne soit plus géré de la même facon depuis. En clair plus aucun des ces extraits ne fonctionnent et la plupart renvoient des exceptions étranges.

Y a-t-il des choses à savoir sur le jdk 1.4 vis à vis de corba?
Quelqu'un connaitrait-il un bon tutoriel récent utilisant de préfèrence les librairies par défaut?

Fait une recherche plus approfondie sur le sujet j'ai déjà posté des trucs sur CORBA il y a 1~2 mois environ. Mais la doc sur JavaIDL disponible dans la documentation du JDK est largement suffisante pour un usage de base.

Avant il fallait utiliser le BOA alors que maintenant il faut utiliser le POA. Mais c'est valable pour tous les envirronements CORBA (2.3 ?), pas juste Java. Sinon mise-à part la manière d'enregistrer les objets sur l'ORB, à mon niveau, tout le reste est resté 100% identique.

As-tu essayé de tout simplement recompiler tes interface IDL ?

Et oui, je sais tout ca.
J'ai été lire la doc de sun mais le problème ne me semble pas être la. Voici l'une des fonctions me renvoyant une exception: orb.resolve_initial_references("RootPOA")
Mais pas une exception style InvalidName mais plutot org.omg.CORBA.NO_IMPLEMENT .
Voici d'ailleurs un copier coller du code de ORBSingleton.java:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

/*   * Things that aren't allowed.   */   public String[] list_initial_services () { throw new NO_IMPLEMENT(); }   public org.omg.CORBA.Object resolve_initial_references(String identifier) throws InvalidName { throw new NO_IMPLEMENT(); }   public void register_initial_reference( String id, org.omg.CORBA.Object obj ) throws InvalidName { throw new NO_IMPLEMENT(); }

---

Bon ben voila, quelqu'un sait pourquoi mon jdk ne prends pas ca en charge?

Edit: j'ai rien dit, c'est moi qui n'appelait pas la bonne fonction d'initialisation de l'orb.

Rajout de balise code

Cela fonctionnet-t'il maintenant ?

Ouais, ca fonctionne :D :D :D .
J'aurais juste une petite question: plutot que de lancer le name service dans un programme en ligne de commande, il n'y aurait pas moyen de le lancer dans un programme java, dans un thread? (juste pour avoir un programme un peu plus facile d'utilisation)

Aucune idée, et puis faut dire que l'ORB de Sun est assez limité quand même. C'est même le strict ninimum ni plus ni moins.

Franchement je comprend que le service de nommage soit peut-être utile en grosse entreprise mais pour les petits et moyens projet c'est plus un boulet qu'autre chose.
Moi j'utilise des services spéciaux de mes ORB côté serveur C++(BootManager pour ORBacus/OB et IORTable pour ACE/TAO) pour éviter d'avoir à utiliser un service de nommage => cela me permet d'utiliser des URL corbaloc:iip:<host>:<port>/<service> à la place. Puisque OB a un équivalent Java (JOB) il est peut-être possible d'utiliser BootManager avec cet ORB également. Egalement il est fort probablement que dans JOB l'API du service de nommage soit accessible. Mais bon ORBacus est loin dêtre gratuit.... Voir peut-être du côté de JacORB et co...

Pour en revenir à ta question à part faire un Runtime.exec() pour lancer la commande du Service de Nommage je ne vois pas trop. J'ignore s'il dispose d'un API accessible dans la JVM.

Merci pour toutes ces précisions, je vais essayer de voir ce que je peux faire, mais je sens que ca va pas être de la tarte.
Faut dire aussi qu'on a un prof véritablement "génial", de ceux qui peuvent rendre n'importe quel concept, même très simple, incroyablement compliqué.
Ceci dit, est-ce que ces services supplémentaires dont tu parles sont normalisés? Est-ce qu'ils peuvent assurer une portabilité impecable ou bien sont-ils spécifiques uniquement à ces implémentations d'orbs?

Citation:

---

Ceci dit, est-ce que ces services supplémentaires dont tu parles sont normalisés?

---

Apparement non puisque déjà ce ne sont pas les même dans les 2 ORB C++ (OB vs. TAO). Encore un manque de la norme probablement. Même la manière d'initialiser l'ORB sur un port spécifique côté serveur n'est pas la même (doh). Par contre les URL corbaloc sont standards (cherchez l'erreur...).

Comme indiqué l'ORB de SUN est... miminal, il n'y a aucun des services standard habituels... A part un service de nommage (et encore il semble que seul le binaire tnameserv.exe soit présent). Pas de service d'évènements, de transaction, de stockage d'interface ou d'implémentation, .........

Pour moi c'est suffisant puisque c'est le serveur C++ qui fait tout le boulot d'etre localisable et que je n'utilise pas de services. Mais si tu cherches qqchose de plus évolué il te faudra regarder du côté des autres ORB écrits Java. C'est principalement à cause des manquements de l'ORB fournis avec le JDK qu'ils existent (en même temps Sun a un peu fait exprès).

Ok, après avoir été fouillé du coté de la documentation de sun j'ai réussi à faire un truc qui fonctionne.
Pour les intèrèssés je m'en vais faire un petit copier-coller (tu peux aussi en profiter pour me dire si il y a des erreurs ou des choses à ne pas faire :) ).

Fichier idl:
module MEcho
{
interface Echo
{
string action(in string aechoer);
};
};

Coté serveur:
String nomService="echoservice";
String persistantport="6969";
String[] initORB={"-ORBPersistentServerPort",persistantport};
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(initORB,null);

EchoServant servant = new EchoServant();

POA rootpoa = POAHelper.narrow( orb.resolve_initial_references("RootPOA") );
rootpoa.the_POAManager().activate();

rootpoa.activate_object( servant );

((com.sun.corba.se.internal.Interceptors.PIORB) orb).register_initial_reference( nomService, rootpoa.servant_to_reference(servant) );

orb.run();

Coté client:
String nomService="echoservice";
String machine="localhost";
String port="6969";
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init( (String[])null,null);

org.omg.CORBA.Object obj = orb.string_to_object("corbaloc:iiop:" +machine+ ":" +port+ "/" + nomService);
Echo impl = EchoHelper.narrow(obj);

String returned = impl.action(jTextField1.getText());

Ben voila. Je n'ai pas trop confiance dans le gros casting fait sur l'orb mais si tu me dis que les url corbaloc sont normalisées, je pense que je ne devrais pas avoir trop de problèmes.

Ben tu vois là c'est toi qui m'apprend des trucs parce que j'ignorais totalement comment fixer le port de l'ORB de Sun avec quel flag et comment rendre un objet joignable par URL sur ce même ORB.

Pour corbaloc et corbaname voir http://www.iona.fr/devcenter/corba/c...0corbaloc&#39;

Bon moi je vais me coucher, il est quand même déjà 01h40 du mat ici.

PS : pour le cast cela me parait normal puisque là tu fais appel au type de l'instance concrete (et en temps normal cachée) de l'ORB. Et que tu appelle une méthode spécifique à l'ORB de SUN. Si ca marche, tout est OK.

Hum une bonne nuit de sommeil et on se sent mieux.

Note aux modo s'il lisent : il serait très fortement interessant de mettre la solution de zais_ethael (après vérification du fonctionnement) dans la FAQ Java (et aussi la FAQ CORBA si elle existe), rubrique CORBA, intitulé de la question "Comment utiliser des URL corbaloc: avec l'ORB de Sun ?".

A la rigueur, si tu as du temps devant toi, tu pourrais faire un petit tuto sur l'utilisation de l'orb de sun. Moi je n'ai vraiment pas assez de temps avec mes cours et puis je ne pense pas être assez calé sur le sujet.

Par contre j'ai une autre petite question à laquelle tu pourras surement répondre 8) : comment faire, dans une des méthode de mon servant, pour différencier un utilisateur d'un autre? Genre pouvoir acquérir son addresse ip. N'importe quoi qui me permette de dire: "toi tu me demandes un service mais tu en as déja demandé un il y a 5 minutes".

Argh, zut.....

Là encore il semble a priori que ce soit quelque chose de propre à chaque implémentation. J'utilisais ca avec OB dans une map des clients avec une clé [addresse IP : port] pour socker les listener nécessaires pour faire du callback.

Et paf ! Evidement le code ne fonctionne pas avec TAO. Les classes permettant de déterminter les addresses et port du client étaient spécifiques à OB et je n'ai pas réussit à trouver les équivalents dans TAO. Voir mon post à ce sujet dans le forum CORBA (essaie quand même de voir si tu peux adapter le code C++ de la méthode getClientInfo() en Java).

J'ai contourné le problème de la manière suivante :

- le client fournis son addresse IP au serveur.
- le serveur lui retourne un identificateur unique (actuellemenent le temps système).
- pour les opération nécessitant un controle spécifique le client passe son identificateur au serveur (dans mon cas le désenregistrement des listener pour le callback).

C'est moins secure je trouve (le client pourrait mentir sur son addresse) mais bon ça marche quand même.