Discussion :

[smutmutant2003]

Bonjour
Je voudrai comprendre l'interet en Corba de IDL. Es ce qu'on peut les associer a des interfaces comme dans les ejb ??? Je sais qu'ils font la jonction dans le bus Corba entre le stub et le squellet. Quelqu'un pourrait il me donner une definition simple de ce concept, je n'arrette pas de potasser de la doc. c'est toujours des definitions qui ne sont pas forcement parlante pour un neophyte comme moi.
En vous remerciant a l'avance

[CorbAddict]

En gros, IDL est un langage indépendant des langages de programmation (C, C++, Java...), permettant de définir des "contrats" entre un client et un serveur.
Ces contrats définissent les types de données pouvant être échangés, et les différentes requêtes pouvant être appelées par le client vers le serveur.

Es ce qu'on peut les associer a des interfaces comme dans les ejb ???

Je ne comprends pas bien la question.
Une interface IDL "MyInterface" compilée en Java donne pour le serveur des interfaces et des classes squelettes.
En particulier, l'interface générée "MyInterfaceOperations" contient toutes les opérations définies dans l'IDL. Elle est implémentée par la classe abstraite "MyInterfacePOA" qui ajoute des opérations internes CORBA, mais n'implémente pas les opérations venant de l'IDL.
Le développeur du serveur doit créer une classe d'implémentation "MyInterfaceImpl" qui hérite de "MyInterfacePOA" et implémente toutes les opérations définies dans "MyInterfaceOperations".

[smutmutant2003]

Merci pour ta reponse.
Ce que je voulais dire par interface en ejb, c'est que lorsque l'on veut instancier un objet a distance, programmation -sans doute heritee de Corba et autres RMI RPC, et systemes reparties- oblige dabord de declarer des interfaces qui representent des methodes a distance. Le client ne peut pas instancier directement l'objet sur le server, il passe par des stub -cote client- et squellet -cote server- le client ne peut manipuler l'objet que via les interfaces. Alors en voyant les Idl je me suis peut etre dit que c'est similaire??? Je parle pour les ejb session, par contre pour les beans entites il y a d'autres interfaces qui entrent en jeu dont je ne detaillerai pas ici le contenu. En examinant de pres Idl, qui prensentent par exemple, les objets persistents avec leur assesseurs es ce qu'il y a une similitude??? En Ejb c'est la classe implementee cote server qui detaille les assesseurs.


Cordialement

[CorbAddict]

Ce que je voulais dire par interface en ejb, c'est que lorsque l'on veut instancier un objet a distance, programmation -sans doute heritee de Corba et autres RMI RPC, et systemes reparties- oblige dabord de declarer des interfaces qui representent des methodes a distance.

Oui, c'est le but de l'IDL de déclarer les opérations accessibles à distance. Mais de manière indépendante des langages de programation. Cela permet à un client C++ de contacter un serveur Java, par exemple.

Le client ne peut pas instancier directement l'objet sur le server, il passe par des stub -cote client- et squellet -cote server- le client ne peut manipuler l'objet que via les interfaces. Alors en voyant les Idl je me suis peut etre dit que c'est similaire???

Le mécanisme stub/skel est similaire. Lorsqu'on compile l'IDL, cela génère le code pour les stub et les skel (les mapping IDL vers les langages de programation C, C++, Java... sont aussi standard)
En revanche, dans la norme CORBA de base, il n'y a pas de mécanisme par défaut pour qu'un client instancie un serveur à distance. Le serveur doit déjà exister et avoir un objet CORBA accessible.
Mais après rien n'interdit de définir un pattern Factory en IDL, avec un objet CORBA Factory sur le serveur qui créera à la demande d'autres objets CORBA sur ce même serveur.

Sinon, il existe une spécification "CORBA Component Model (CCM)" qui définit un model de composant style EJB. (en fait, plus étendu que les EJB, car la spec considère les EJB comme des composants CORBA basiques).

En examinant de pres Idl, qui prensentent par exemple, les objets persistents avec leur assesseurs es ce qu'il y a une similitude??? En Ejb c'est la classe implementee cote server qui detaille les assesseurs.

L'IDL ne définie pas la persistance. Lorsque tu définies des attributs à une interface en IDL, seules les opérations d'accès (set et get) sont générées. Mais c'est au développeur de les implémenter, et donc de gérer le stockage des attributs.

[smutmutant2003]

Je te remercie CorbAddict
Maintenant Corba et en particulier les Idl me sont moins floues. Pour l'instant je travaille sur une technologie qui repose sur les webservices. Il m'arrive de travailler plus rarement sur les EJB, toutefois en voyant les ejb, RMI je me dis qu'il y a enormement de point commun. Seule chose que je n'arrive pas a faire d'analogie c'est ce fameux bus corba -les idl tu me les as admirablement bien explique- je ne vois pas en EJB ni en RMI de choses similaire. Peut etre que sur le server d'application -pour les EJB- le conteneur EJB fait office de bus Corba???
Voila


Et encore merci l'ami

[CorbAddict]

Je t'en prie !

Pour ce qui est du "bus CORBA", je trouve aussi que ce terme prête à confusion.
Car il n'y a pas 1 process/démon ou 1 objet qui représente ce "bus".
Ce qu'on appelle "bus CORBA", c'est du point de vue de l'implémentation, l'ensemble du code généré (stub/skel) et non-généré (ORB, POA, couche transport...) qui permet à un client et une implémentation d'objet CORBA (appelé servant) de communiquer entre eux.

Donc, concrètement, pour 2 process distincts, le bus CORBA est coupé en 2 ensembles de classes communiquant via TCP/IP (ou autre protocole):
- stub + ORB/POA/transport, instanciés côté client
- skel + ORB/POA/transport, instanciés côté serveur

Quant aux EJB communiquant via IIOP, ils ne font que réimplémenter cette couche transport pour communiquer selon le standard CORBA IIOP (en utilisant le mapping "Java to IDL" qui standardise la manière d'exprimer les types Java en IDL, et donc traduisibles en d'autres langages).
On peut donc considérer que le serveur d'appli EJB embarque une implémentation minime d'un bus CORBA.