Discussion :

[guimond]

Bonjour à tous

J'ai un serveur qui tourne actuellement sur Mico et qui dialogue avec des applications qui elles tournent avec :
1.Visibrocker
2.Corba XML
3.MICO
4.JacORB

Je voudrais savoir si je decide de changer l'ORB du serveur MICO par, par exemple omniorb, est ce qu'il faut que je modifie les IDLs?

Je debute dans le monde corba, apres lecture de documents, je n'ai pas trouver d'allusions faites entre la relation ORB et IDL . Vu que l'on parle de langage IDL avec une propre syntaxe, je pense que le changement d'ORB n'implique pas une impacte au niveau des IDLs. Mais je souhaiterai avoir confirmation

Merci

[menator]

La raison d'être des IDL est de définir un contrat unique valable pour toutes les applications qui dialoguent grâce à cet IDL. Donc quelque soit l'ORB utilisé par les applications.

-> ton IDL ne change pas (sinon ce n'est pas la peine de définir une interface !)

Par contre en migrant de MICO à OmniORB, tu devras:
- recompiler l'IDL. Le mapping IDL -> C++ est spécifique à chaque ORB si je me souviens bien (par contre le mapping est standard en Java, pas de recompilation normallement).
- modifier probablement le code du serveur, si des méthodes de l'ORB sont différentes entre MICO et OmniORB ou si des methodes spécifiques à l'ORB sont utilisées (ce qui est très probable si le serveur est un peu "sophistiqué").

[guimond]

Ok merci de confirmer se que je pensais.
Une autre question me viens alors:
Sur quels criteres concidere t on qu'un ORB est bon? Entendre par là, pourquoi choisir MICO et pas un autre si ceux-ci effectuent le meme traitement au niveaux des IDLs?
Comment avez vous choisi votre ORB?
Parce que sur le site suivant
http://www.puder.org/corba/matrix/
il existe apparamment une multitude d'ORB C++ avec diverses options. Quelles sont les options selon-vous à prendre en compte?
L'orb devra tourné sur un serveur linux et traiter enormement de requetes venant de clients ayant les ORB cité dans mon premier message ( environ 400 000 demandes par jour)

Merci

[menator]

Si ton serveur doit migrer de Mico vers OmniORB, il ya sûrement une raison, et une démarche de choix d'ORB derrière... sinon j'ai des craintes pour ce projet de migration !

En vrac je verrais comme critères de choix de l'ORB:
- les service supportés (ex: Notification, Naming...) si ton serveur les utilise. Les Orb n'ayant pas tous les services, on se tournera parfois vers des intégrateurs (Prismtech par ex) qui repackagent les ORB en ajoutant certains services et utilitaires.
- la version de la norme CORBA supportée, avec quelles restrictions.
- la licence et le coût runtime (à étudier de près en cas de gros déploiement)
- l'intéropérabilité prouvée avec d'autres ORB.
- la performance : nb appels/s supportés et temps de latence d'un appel. Dans ton cas ça joue un rôle mineur (400 000 appels/j ca nous fait du 5 appels /s c'est pas énorme du strict point de vue traffic de communication).

L'interopérabilité est un point à tester tout particulierement dans ton cas, vu que tu as 5 ORB différents (un côté serveur et 4 côté client).

Par rapport au site que tu donnes, il faut vérifier entre autres la dispo des éléments:
- POA ou BOA (en fonction de ce que ton serveur utilise)
- VTS (ValueType) si ton IDL les utilise
- SSL : connexion sécurisée possible, si ton appli l'exige.

[guimond]

Si ton serveur doit migrer de Mico vers OmniORB, il ya sûrement une raison, et une démarche de choix d'ORB derrière... sinon j'ai des craintes pour ce projet de migration !

Oui justement mon but et de determiner le meilleur ORB possible pour remplacer MICO, j'ai cité OmniORB a titre d'exemple.

- l'intéropérabilité prouvée avec d'autres ORB.
L'interopérabilité est un point à tester tout particulierement dans ton cas, vu que tu as 5 ORB différents (un côté serveur et 4 côté client).

Pour ce qui est de l'intéropérabilité, le meilleur moyen est je suppose de demander directement a l'entreprise si l'ORB supporte les autres ORBs. A moins que quelqu'un ne connaisse un autre moyen pour determiner l'intéropérabilité auquel cas je suis preneur

Encore merci pour tes conseils

[menator]

Tu trouveras parfois certains tests d'interopérabilité dur le Web, mais avec la relative baisse d'intérêt autour de CORBA, il n'y a pas grand chose de récent.

Une alternative interessante à CORBA est Ice (http://www.zeroc.com), très proche de CORBA, mais + simple sur certains aspects. Valable si tu est aussi maître de l'évolution des clients. Bon j'arrête le prosélitisme Ice.

[guimond]

Une alternative interessante à CORBA est Ice (http://www.zeroc.com), très proche de CORBA, mais + simple sur certains aspects. Valable si tu est aussi maître de l'évolution des clients. Bon j'arrête le prosélitisme Ice.

Oui mais pour une architecture déjà existante, l'impacte au niveau de l'implémentation des differents clients et du serveur doit etre énorme pour mettre en place Ice non?

[guimond]

Une alternative interessante à CORBA est Ice (http://www.zeroc.com), très proche de CORBA, mais + simple sur certains aspects. Valable si tu est aussi maître de l'évolution des clients. Bon j'arrête le prosélitisme Ice.

Oui mais pour une architecture déjà existante, l'impacte au niveau de l'implémentation des differents clients et du serveur doit etre énorme pour mettre en place Ice non?

[menator]

Oui. L'impact est très lourd. C'était juste pour faire de la Pub à Ice .
J'apprécie leur démarche pragmatique malgré le discours très "marketing".

Il faudrait, pour migrer:
- traduire l'IDL en IDL "Ice" (donc disparition des éventuels Any, entre autres),
- modifier le serveur (c'est là le + lourd, ton serveur supporte une charge conséquente, il doit être déjà bien structuré) et les clients en fonction du mapping IDL Ice-> Java, C++...

Ca n'a de sens que si de gros bénéfices sont attendus, par ex:
- fournisseur unique pour tous les mappings vers les langages -> interopérabilité assurée,
- mapping C++ à priori + simple en Ice (je n'ai pas vérifié)
- éventuellement meilleure perfs, mais là c'est sujet à caution, on fait dire ce qu'on veut à un test,
- facilité de développement améliorée, notamment pour la programmation asynchrone et de + certains concepts lourdingues de CORBA sont supprimés,
-etc... voir le discours et la doc