Introduction à Java IDL

jeudi 30 août 2001

Article de Sun traduit et adapté en français.

Qu’est-ce que Java IDL ?

Java IDL est une technologie pour les "objets distribués", c’est-à-dire des objets interagissant avec différentes stations de travail d’un réseau. Java IDL est similaire à RMI (Remote Method Invocation) qui supporte des objets distribués écrits entièrement et exclusivement en langage Java. Cependant, Java IDL permet aux objets d’être utilisés même s’ils sont écrits dans un langage différent de Java, comme C/C++, Cobol, et bien d’autres.

Ceci est possible car Java IDL est basé sur l’architecture CORBA (Common Object Request Brokerage Architecture), un standard mondial de l’industrie dans la distribution d’objets sur un réseau. Une des composantes de Corba est IDL (Interface Definition Language), langage dit "neutre". Chaque langage de programmation supportant Corba implémente une IDL, d’où le nom de "Java IDL", l’implémentation IDL pour Java. Corba et IDL sont issus d’un consortium de trusts mondiaux (notamment IBM, Boeing, etc.) connus sous le nom de OMG (Object Management Group), et le fait que Sun Microsystems soit l’un des membres fondateurs explique que IDL soit si bien adapté à Java.

Pour permettre des interactions entre les objets de différents programmes d’un réseau, Java IDL "fourni" un ORB (Object Request Broker). Un ORB est une bibliothèque de classes qui permet une communication de bas niveau entre Java IDL et d’autres applications basées sur Corba.

L’architecture CORBA

Une interaction entre 2 objets sur un réseau a toujours 2 sens: le client et le serveur (entrée/sortie su vous préférez). Le serveur crée une "Remote Interface" (c’est à dire une porte d’entrée vers lui), et le client appelle et utilise cette "Remote Interface". Ceci est globalement la procédure généralisée utilisée par les standards d’objets distribués comme RMI ou Corba. On notera que les mots "client" et "serveur" désignent des interactions au niveau des objets et pas des applications: un logiciel peut être à la fois client et serveur selon s’il publie ou reçoit tel ou tel objet.

Du côté du client, l’application a une référence vers l’objet distribué. La référence a une méthode "stub" ("stub" signifie le "talon" d’un ticket en anglais) qui est une sorte des remplaçant pour la méthode appelée à distance. Le "stub" est installé dans l’ORB, l’appeler revient donc à activer les fonctions de communication de l’ORB qui se chargera de la connexion au serveur.

Du côté du serveur, l’ORB utilise un "squelette" de code pour traduire l’appel à distance en un appel de méthode sur un objet local. Le squelette se charge de bien traduire la requête dans le format attendu par l’objet local. Quand la méthode finit (à comprendre: quand elle retourne) le squelette se charge de traduire la valeur de retour ou les erreurs et de les transmettre à l’ORB qui les transmet à son tour au client.
Entre les ORB, la communication est établie grâce à un protocole spécial: IIOP (Internet Inter-ORB Protocol). IIOP, basé sur le standard TCP/IP, définit comment des ORB pour Corba échangent des informations. Tout comme Corba et IDL, IIOP est un standard définit par l’OMG (Object Management Group).

En plus des possibilités de communication exposées plus haut, les ORB basés sur Corba ont des fonctionnalités améliorées, des services définis par l’OMG. Ceci inclut la recherche d’objets par nom, la persistance d’objets, la possibilité d’échanger des messages, etc. Certains ORB supportent ces fonctions, celui fourni avec Java IDL supporte la recherche d’objets par nom.

Le processus de développement de Java IDL

1) Définir l’interface à distance
On définit l’interface à distance en utilisant le langage de définition de l’interface de l’OMG, c’est à dire IDL. On utilise IDL plutôt que Java car le compilateur idl-to-java travaille à partir d’un (code) source IDL, générant tous les fichiers "stub" et "squelette" avec le code d’infrastructure nécessaire à la connexion avec l’ORB. En utilisant IDL, on permet aux autres développeurs d’implémenter des clients et des serveurs dans d’autres langages compatibles Corba.

2) Compiler l’interface à distance
Quand on lance le compilateur idl-to-java sur le fichier source de définition de l’interface, il génère une version en Java de l’interface, comme il génère les stubs et les squelettes.

3) Implémenter le serveur
Une fois le compilateur idl-to-java lancé, on peut utiliser les squelettes générés pour assembler son serveur. En plus d’implémenter les méthode de l’interface à distance, le code du serveur inclut un mécanisme pour lancer l’ORB et attendre une requête d’un client.

4) Implémenter un client
De même on utilisera les stubs générés par le compilateur comme base pour l’application client. Le code client construit à partir des stubs lance l’ORB de son côté qui recherche une connexion vers le serveur utilisant le service de noms indiqué par Java IDL, obtient une référence vers l’objet à distance et invoque à distance ses méthodes.

5) Démarrer l’application
Une fois le serveur et le client créée, on peut lancer le service de noms, puis démarrer le serveur, et enfin lancer le client.

Notes:
1) Avec Java 1.3, idltojava compiler est remplacé par idlj compiler
2) Si vous désirez un exemple concret: HelloWorld! dans la suite de cet article de la FAQ. Article Sun ici.

Traduit et adapté de l’anglais par Narcanes, (article original de Jim Inscore Sun Microsystems)
pour l’association Java-France/Jgflsoft
www.java-france.com / www.jgflsoft.com
Réédité pour Valhalla GFBLOG.
Montpellier, 30 août 2001.

Article de Sun traduit et adapté en français.

Qu’est-ce que Java IDL ?

Java IDL est une technologie pour les "objets distribués", c’est-à-dire des objets interagissant avec différentes stations de travail d’un réseau. Java IDL est similaire à RMI (Remote Method Invocation) qui supporte des objets distribués écrits entièrement et exclusivement en langage Java. Cependant, Java IDL permet aux objets d’être utilisés même s’ils sont écrits dans un langage différent de Java, comme C/C++, Cobol, et bien d’autres.

Ceci est possible car Java IDL est basé sur l’architecture CORBA (Common Object Request Brokerage Architecture), un standard mondial de l’industrie dans la distribution d’objets sur un réseau. Une des composantes de Corba est IDL (Interface Definition Language), langage dit "neutre". Chaque langage de programmation supportant Corba implémente une IDL, d’où le nom de "Java IDL", l’implémentation IDL pour Java. Corba et IDL sont issus d’un consortium de trusts mondiaux (notamment IBM, Boeing, etc.) connus sous le nom de OMG (Object Management Group), et le fait que Sun Microsystems soit l’un des membres fondateurs explique que IDL soit si bien adapté à Java.

Pour permettre des interactions entre les objets de différents programmes d’un réseau, Java IDL "fourni" un ORB (Object Request Broker). Un ORB est une bibliothèque de classes qui permet une communication de bas niveau entre Java IDL et d’autres applications basées sur Corba.

L’architecture CORBA

Une interaction entre 2 objets sur un réseau a toujours 2 sens: le client et le serveur (entrée/sortie su vous préférez). Le serveur crée une "Remote Interface" (c’est à dire une porte d’entrée vers lui), et le client appelle et utilise cette "Remote Interface". Ceci est globalement la procédure généralisée utilisée par les standards d’objets distribués comme RMI ou Corba. On notera que les mots "client" et "serveur" désignent des interactions au niveau des objets et pas des applications: un logiciel peut être à la fois client et serveur selon s’il publie ou reçoit tel ou tel objet.

Du côté du client, l’application a une référence vers l’objet distribué. La référence a une méthode "stub" ("stub" signifie le "talon" d’un ticket en anglais) qui est une sorte des remplaçant pour la méthode appelée à distance. Le "stub" est installé dans l’ORB, l’appeler revient donc à activer les fonctions de communication de l’ORB qui se chargera de la connexion au serveur.

Du côté du serveur, l’ORB utilise un "squelette" de code pour traduire l’appel à distance en un appel de méthode sur un objet local. Le squelette se charge de bien traduire la requête dans le format attendu par l’objet local. Quand la méthode finit (à comprendre: quand elle retourne) le squelette se charge de traduire la valeur de retour ou les erreurs et de les transmettre à l’ORB qui les transmet à son tour au client.
Entre les ORB, la communication est établie grâce à un protocole spécial: IIOP (Internet Inter-ORB Protocol). IIOP, basé sur le standard TCP/IP, définit comment des ORB pour Corba échangent des informations. Tout comme Corba et IDL, IIOP est un standard définit par l’OMG (Object Management Group).

En plus des possibilités de communication exposées plus haut, les ORB basés sur Corba ont des fonctionnalités améliorées, des services définis par l’OMG. Ceci inclut la recherche d’objets par nom, la persistance d’objets, la possibilité d’échanger des messages, etc. Certains ORB supportent ces fonctions, celui fourni avec Java IDL supporte la recherche d’objets par nom.

Le processus de développement de Java IDL

1) Définir l’interface à distance
On définit l’interface à distance en utilisant le langage de définition de l’interface de l’OMG, c’est à dire IDL. On utilise IDL plutôt que Java car le compilateur idl-to-java travaille à partir d’un (code) source IDL, générant tous les fichiers "stub" et "squelette" avec le code d’infrastructure nécessaire à la connexion avec l’ORB. En utilisant IDL, on permet aux autres développeurs d’implémenter des clients et des serveurs dans d’autres langages compatibles Corba.

2) Compiler l’interface à distance
Quand on lance le compilateur idl-to-java sur le fichier source de définition de l’interface, il génère une version en Java de l’interface, comme il génère les stubs et les squelettes.

3) Implémenter le serveur
Une fois le compilateur idl-to-java lancé, on peut utiliser les squelettes générés pour assembler son serveur. En plus d’implémenter les méthode de l’interface à distance, le code du serveur inclut un mécanisme pour lancer l’ORB et attendre une requête d’un client.

4) Implémenter un client
De même on utilisera les stubs générés par le compilateur comme base pour l’application client. Le code client construit à partir des stubs lance l’ORB de son côté qui recherche une connexion vers le serveur utilisant le service de noms indiqué par Java IDL, obtient une référence vers l’objet à distance et invoque à distance ses méthodes.

5) Démarrer l’application
Une fois le serveur et le client créée, on peut lancer le service de noms, puis démarrer le serveur, et enfin lancer le client.

Notes:
1) Avec Java 1.3, idltojava compiler est remplacé par idlj compiler
2) Si vous désirez un exemple concret: HelloWorld! dans la suite de cet article de la FAQ. Article Sun ici.

Traduit et adapté de l’anglais par Narcanes, (article original de Jim Inscore Sun Microsystems)
pour l’association Java-France/Jgflsoft
www.java-france.com / www.jgflsoft.com
Réédité pour Valhalla GFBLOG.
Montpellier, 30 août 2001.

Voir aussi