Discussion :

[Djobird]

Bonjour,
Voici la situation.
Je réutilise une architecture permettant à un client de dialoguer avec un serveur via CORBA. Cette architecture existe et marche.
J'ai aujourd'hui besoin de rajouter certaines fonctionnalité au serveur. N'ayant aucun moyen d'y faire des modifications directes, je passe donc par un server intermédiaire.
Le client va donc envoyer ses requêtes au serveur intermédiaire, qui va ajouter les traitements qui m'intéressent, puis transférer les requêtes au serveur principale.
Seulement, sur le grand nombre de fonction dispo, je n'ai besoin de faire des modifications que sur quelques unes. Pour ces autres fonction, le client pourrait directement les faire appeler directement sur le serveur.

Sachant que je dispose des fichiers idls sources, est ce qu'il existe un moyen de générer un serveur qui va ne faire que retransmettre l'appelle de fonction ?
Ou alors je suis obliger de me taper à la main tous les transfères ?

[CorbAddict]

Bonjour,

Une solution possible est d'utiliser le DSI (Dynamic Skeleton Interface) et le DII (Dynamic Invocation Interface).
Le DSI permet d'implémenter un serveur répondant dynamiquement à des requêtes, sans hériter d'un skeleton généré, et donc sans même connaitre l'IDL.
Le DII permet de créer des requêtes CORBA et de les envoyer à un client.

C'est un peu complexe à utiliser, car tout les attributs sont récupérés sous forme d'Any, et il faut les extraire pour les utiliser.

Mais tu pourrais donc implémenter un serveur recevant toutes les requêtes, vérifiant leur nom, effectuant le traitement spécifique pour quelques unes, et sinon, transférant la requête au serveur par DII (il ne devrait y avoir qu'à copier la requête en changeant la cible).

Un bon cours sur le DSI:
http://www.ddj.com/cpp/184403847
et un autre sur le DII:
http://www.ddj.com/cpp/184403833

Sinon, écrire un générateur de code depuis l'IDL...

[Djobird]

Merci pour cette idée, malheureusement je pense que je perdrais plus de temps qu'autre chose. Surtout que les structures manipulées sont plus ou moins complexes.
Mais en tout cas ce système est intéressant, et pourrait m'être utile à un autre endroit.

[menator]

Il y a une piste avec le LOCATION_FORWARD.

Je ne l'ai jamais utilisé mais tu dois pouvoir :
- réaliser les traitements additionnels sur ton serveur intermédiaire comme prévu avant d'appeler le serveur d'origine,
- rediriger les requêtes dont le traitement ne change pas vers le serveur original grâce au LOCATION_FORWARD.

Le LOCATION_FORWARD est prévu pour les mécanismes de partage de charge (permet à un serveur intermédiaire de rediriger des requêtes alternativement sur un serveur concret ou un autre).

A voir si ça fonctionne, et comment, avec tes ORBs côté client et serveur.
Le serveur doit émettre le LOCATION_FORWARD et le client doit correctement l'interpréter pour ré-émettre la requête vers la nouvelle destination.