Discussion :

[mencaglia]

bonjour,

Je vais devoir programmer un outil de calcul distribué à l'aide de la technologie CORBA. J'ai commencé à programmer mon outils de calcul en JAVA pour des besoins de portabilité et je souhaite savoir si je dois me procurer des outils pour programmer en CORBA.

je dispose de JBuilder 5 ainsi que d'un précompilateur idlj pour générer du code java à partir de ma définition d'interface "monexemple.idl".
Je veux savoir si j'ai toutes les armes pour me lancer dans le programmation de l'architecture client/serveur avec CORBA.

MERCI,

Xavier

[bouye]

Déjà un nouveau thread ?

L'implémentation de Sun, fournies avec le JRE, est suffisante dans la plupart des cas mais minimaliste :
- ORB à la norme CORBA 2.kekchose
- compilateur IDL -> Java pour générer du code pour cet ORB.
- service de nommage (compatible IIOP ?????).
- pas grand chose d'autre.
Il n'y a pas de service d'évènements ou de service de transaction. Bon bref en général ca suffit pour faire des trucs qui marchent bien.

Dans JBuilder X et 2005, il y a je crois un ORB de Borland (EasyBroker ??) fournis mais je n'y ait jamais jeté de coup d'oeuil et je ne sais pas quels services sont éventuellement fournis avec, ni comment l'utiliser en lieu et place de celui de Sun. => lire la doc de JBuilder.

Il existe d'autres ORB disponibles en Java, certains gratuits d'autres pas, entre autre JacORB et ORBacus/JOB. Il faudrait que tu regardes et compare le niveau de la norme supportée ainsi que les différents services CORBA dispos sur chacune des implémentations.

!!!! si tes client et ton serveur sont tous en Java et que ca ne changera jamais, tu peux éventuellement réfléchir à l'utilisation de RMI au lieu de CORBA ; les principes sont similaires et cela te simplifiera quelques étapes (pas de fichier IDL, ...).

[mencaglia]

j'ai besoin de définir une architecture client serveur pour lancer des calculs numériques sur des machines distantes.

Le serveur sera mon code de calcul SAMCEF sur un supercalculateur.
Le client sera MonApplication java développé avec JBuilder.
Je cherche juste à lancer SAMCEF sur le supercalculateur depuis une autre machine du réseau à l'aide de mon programme Java.
Puis je devrais pouvoir échanger des données avec MonApplication sous forme de fichier. MonApplication devra récupérer les fichiers de résultats du calcul sur le supercalculateur.

J'espère avoir été clair.
Est-il possible de faire ca avec JBuilder et l'ORB disponible dans JBuilder

Xavier

[bouye]

Est-il possible de faire ca avec JBuilder et l'ORB disponible dans JBuilder

Hum...
la reponse courte : oui cela me semble possible et suffisant.
Et avec les version recentes de JBuilder tu auras meme le choix entre 2 ORB (celui de Sun et EasyBroker donc). Il te faudra cependant packager l'ORB de Borland avec ton application (si tu l'utilises).

La reponse longue : ca depend de comment tu veux interragir avec tes scripts, de si tu peux te permettre d'installer un daemon sur le super-calculateur ou meme si une implementation de Java existe sur cette machine/OS. T'es-t'il possible d'installer des apps sur ton super-calculateur ? Etc...

En general ton client ne peut pas comme ca par magie faire demarrer un serveur en se connectant au super-calculateur. Cependant il y a des moyens sous Unix/Linux de faire demarrer automatiquement un programme lors d'une connection sur un port donne en passant par xinetd (ou equivalents), je crois.

Du moins c'est comme ca que CVS marche sur ma machine, lorsque je me connecte sur mon poste Linux sur le port CVS, xinetd demarre le serveur CVS qui prend alors le relai ; il n'y a pas de daemon CVS tournant en permanence. Le daemon xinetd lui tourne en permanence.
Mais c'est un peu hors sujet pour ce forum et je suis pas du tout suffisement verse dans ce domaine pour pouvoir t'aider. En plus je ne sais pas sous quel OS ni quelles sont les capacites de ton super-calculateur.

Rappel :

Typiquement ton serveur sera un service/daemon (celon l'OS de ton supercalculateur) qui tournera en permanence sur le supercalculateur. Ton client se connectera sur ce service et lui demandera de lancer/arrêter des calculs. Il peut aussi lui demander d'acceder à un objet permettant de vérifier l'état dd'un calcul ou d'une simul donnée.

Maintenant est-ce que j'ai ecrit est clair pour toi ou est-ce que j'ecrit en chinois ?

Es-tu au moins sur qu'il soit possible de faire tourner Java (si possible avec une version similaire/compatible au niveau de l'ORB/norme CORBA a celle des postes clients) sur ton super-calculateur (pour le serveur) ?

Cependant si les modes/possibilites d'executions sur une telle machine sont restreints il te fraudra peut-etre envisager des protocoles reseau plus simples a base de sockets et en gerant toi-meme les connections et en utilisant des protocoles connus (FTP, HTTP, SSH, SFTP...) quitte a devoir recuperer des libs externes pour supporter ca dans le client.

[mencaglia]

oui je crois avoir à peu prés compris,
pour utiliser mon supercalculateur je dois pouvoir faire tourner une version Java similaire à celle de ma machine pour disposer d'un Orb compatible à celui que j'ai avec JBuilder...
je vais déjà me renseigner la dessus puis on en reparle.

Je veux juste une précision sur ACE / TAO si tu connais,
C'est un modèle d'Orb basé sur CORBA.
Pourrais tu me donner qqs précisions si tu connais cet ORB.
Qu'est ce qu'il permet de faire en plus???


Merci

XAvier

[bouye]

TAO est intéropérable avec l'ORB de Sun via IIOP*, je ne sais pas pour EasyBroker. Je suis en train de faire des tests/progs de base dessus avec ACE/TAO en ce moment : je vais remplacer ORBacus/OB par ACE/TAO dans nos applis C++ en cours de dével car OB est trop cher pour le déploiement. Nos clients sont tous en Java et utilisent l'ORB de Sun... pour le moment le dialogue marche bien (mais je ne fais rien de sorcier).

Il est fournis avec beaucoup plus de services CORBA que celui de Sun et semble donc très complet. De plus il est construit en sur-couche de ACE qui semble offrir une API assez vaste par rapport aux lib C++ standard (qui sont portable mais... limitées dans leurs fonctionalités). Support du threading, ... bref comme une mini-API Java mais en C++ et c'est portable sur une large variété de platformes et de compilateurs.

Ce que je n'aime pas dans cet ORB/API c'est son manuel ou plutot son manque de documentation claire et concise pour bien débuter : m'est avis que je suis trop habitué à OB, m'enfin par certains côté ACE/TAO ressemble à projet universitaire (ce qu'il est probablement) : il a donc des "coins moins arrondis" qu'un projet commercial... Il existe cependant des version commerciales de TAO avec manuel et tout et tout, voir ici. Mais nous on restera avec la version gratuite.

Ceci dit il contient des exemples dont on peut voir le code. Il est très très long à compiler (plus de 2h sous Windows, pas encore essayé sous Linux) et la compilation était assez délicate (j'ai écris une liste des trucs à faire qq part au boulot) ; mais bon en général on ne le compile qu'une seule et unique fois. Egalement je n'arrive pas à trouver d'équivalent à certaines fonctionalités d'OB (voir mon post dans le forum CORBA). Mais bon je crois que je vais prendre le pb par un autre bout et contourner l'obstable (le cleint fournira son addr et une ID).

D'un autre côté d'après mes tests certaines parties du code de basse utilisé pour initialiser OB peuvent être repris tels quels car ce sont des appels standardisés par la norme CORBA. Après effectivement les fichiers générés par le compilateur IDL ne sont pas les mêmes, les headers et autres lib à inclure dans le projet et les options de compilations sont différents et il m'a fallut fouiller un peu sur le net pour trouver comment faire que mon serveur puisse fonctionner avec des URL (remplacer BootManager de OB par IORTable de TAO). Mais bon pour le moment j'en suis content.

*IIOP : CORBA est une norme, avec comme dans toutes les normes des parties vagues qui peuvent être laissées à l'interpretation des implémenteur. Alors bien évidement à la sortie de CORBA 1.0, plusieurs ORB ont vu le jour qui bien qu'étant totalement conforme à la norme ont trouvé le moyen d'être totalement incompatibles entre eux ("a cause pa", "a personne au bout du fil", "allo Houston on vous capte pas", ...). Alors que quelques part CORBA avait été spécialement concut dans ce but-là... y avait comme un problème quelque part...

l'OMG est donc retourné plancher sur une nouvelle norme appellée IIOP (Internet Inter-Operability Protocol ou Internet Inter-ORB Protocol) qui permet à 2 ORB de 2 vendeurs différents de communiquer entre eux.

De même avec le temps des services standard : service de nommage, service de transaction, service d'évènement, ... eux-mêmes écrits en CORBA et des modèles de threadings différents pour la gestions des connections clientes par le serveur, ... ont été définis dans les versions plus récentes de la norme CORBA.

[mencaglia]

je vais discuter avec l'administateur réseau de mon entreprise demain pour voir ce qu'il est possible de faire sur notre supercalculateur...
et avec quel orb ....
donc je te donne des nouvelles demain car j'aurai surement des questions.

Bonne journée

Xavier

[bouye]

Ok.
Pour les truc hors client Java/Java-IDL et/ou bien spécifiques à TAO mieux vaudra poster dans le forum CORBA cependant.