03/04/2004 Première version. Merci a Julien Herbin et a Thomas Chevalier pour leurs corrections
Etude du compilateur IDLJ
L'IDL est le langage utilisé par l'OMG pour décrire les interfaces qu'un client peut appeler ainsi que l'implémentation des objets. Celle-ci définit complètement l'interface ainsi que les paramètres de chacune des opérations.
Le langage IDL est totalement indépendant d'un langage donné. IDLJ va se charger de projeter la définition IDL vers le langage java. Il existe au moins un compilateur IDL pour chaque langage projeté.
Le compilateur idlj convertit à partir du langage de définition IDL les interfaces et modules en classes, méthodes et interfaces Java qui pourront être utilisées pour le code client et serveur.
Paramètres du compilateur : Options : -d <symbole>
equivaut à faire #define <symbole> dans le fichier IDL -emitAll
Génére tous les types inclus dans le fichier idl
Par exemple, avec deux fichiers idl : Main.idl :
#include <Included.idl>
interface Main
{
};
Et Included.idl :
interface Included
{
};
Si on exécute la commande idlj sur le fichier Main.idl : # idlj Main.idl
Cette commande ne va générer les projections Java que pour l'interface Main alors qu'en rajoutant l'option -emitAll, on va générer les projections pour tous les types inclus. Donc notre cas, on obtiendra aussi les fichiers Included*.java. # idlj -emitAll Main.idl
-f<side>
Définit quels bindings doivent être générée.
<side> peut prendre différentes valeurs :
- client => génere les classes du client
- server => génere les classes du serveur
- serverTIE => génere les classes du serveur en utilisant la modéle par délégation
- all => génere toutes les classes (client et serveur)
- allTIE => génere toutes les classes (client et serveur) en utilisant la modéle par délégation
Ainsi, les deux commandes suivantes sont équivalentes : # idlj -fclient -fserver Main.idl
# idlj -fall Main.idl
Par défaut, seul les bindings client sont générés.
L'approche par héritage a changé de structure depuis l'arrivée de la version 1.4 de Java. Le modèle par défaut pour le serveur est appelé "Portable Servant Inheritance Model". Cependant, il reste possible, même si cela reste déconseillé (l'API est deprecated), d'utiliser l'ancien modèle pour le serveur en utilisant l'option -oldImplBase.
Les fichiers ainsi produits différents :
Par l'approche récente, on va obtenir pour notre fichier idl Main.idl, ces 3 fichiers :
- Main.java
- MainOperations.java
- MainPOA.java
Etant donné une interface Main définie dans le fichier Main.idl, le fichier MainPOA.java est généré. Il faut fournir une implémentation pour Main qui doit hériter de MainPOA.
Avec l'approche précédente (JDK 1.3 et précédents), on obtient :
- _MainImplBase.java
- Main.java
- MainOperations.java
Il est cependant possible de spécifier une approche par délégation.
Avec cette approche, on obtient les mêmes fichiers qu'avec l'approche par héritage actuelle avec un fichier en plus : - MainPOATie.java
-i <include-path>
Spécifie dans quel répertoire chercher les fichiers à inclure (Par défaut, le répertoire courant est utilisé pour les fichiers inclus).
-keep
Conserve les fichiers déjà existants (par défaut, ces fichiers sont écrasés).
-noWarn
N'affiche pas les messages de warning.
-oldImplBase
Utilise l'approche par héritage des versions JDK 1.3 et précédentes. Voir l'option -f <side> pour plus d'informations.
-pkgPrefix <type> <package>
Permet de préfixer un type idl, un module, une interface... avec un nom de package Java.
Par exemple, pour le fichier idl :
interface Main
{
};
La commande # idlj -pkgPrefix Main Plop Main.idl
va nous créer un répertoire Plop avec toutes les classes dedans appartenant bien au bon package (package Plop).
-pkgTranslate <type> <package>
Permet de changer le nom du module <type> par le nom <package>. Ainsi, on provoque un renomage du package obtenu.
Par exemple, pour le fichier idl :
#include <Included.idl>
module MonModule {
interface Main
{
};
};
Si on projete en Java de manière classique, on va obtenir le package MonModule. Avec la commande : # idlj -pkgTranslate MonModule MonPackage Main.idl
On va obtenir le package MonPackage (effet du renommage du module MonModule).
-skeletonName xxx%yyy
Permet de changer le modèle du nom de fichier pour le squelette (donc uniquement coté serveur).
Par exemple, toujours en utilisant le superbe fichier Main.idl, en compilant avec la commande suivante : # idlj -fserver -verbose -skeletonName MonPOA%version2 Main.idl
Le squelette va s'appeller MonPOAMainversion2.java au lieu de MainPOA.java
-td <répertoire>
Utilise le répertoire <répertoire> comme répertoire pour la génération des fichiers au lieu du répertoire courant.
-tieName xxx%yyy
Permet de chagner le modèle du nom de fichier pour le modèle par délégation.
Le principe est le même que pour l'option -skeletonName.
-verbose
Mode verbeu. Permet d'obtenir plus d'informations quant à la compilation idj.
Par exemple : # idlj -verbose Main.idl
-version
Affiche les informations sur la version du compilateur IDL vers Java.
Makefile (ant)
Pour la compilation, il est plus approprié d'utiliser Ant, programme du groupe Apache. Ce programme est un outil de compilation. Dans le principe, il fait la même chose que le GNU/Make mais en corrigeant les problèmes inhérents à ce genre d'outils :
la portabilité
En effet, la plupart de ces logiciels sont basés sur les fonctionnalités des shells et donc ainsi très difficiles à porter sur des plateformes Microsoft ou n'utilisant pas des shells différents.
Ant permet une mise en place simple d'un fichier de compilation :
- build.xml pour Ant qui est l'équivalent de Makefile pour le programme make
Celui-ci permet de facilement définir les différentes opérations à réaliser avec les différentes dépendances tout en utilisant le standard XML pour la configuration.
Il permet aussi de spécifier l'utilisation d'idlj lors du processus de génération avec ses différents paramètres.
Voici un exemple type de fichier ant.
<project name="MonProjetAvecIDLJ" default="dist" basedir=".">
<description>
Test de ant pour le projet CORBA avec Java
</description>
<!-- Definie les proprietes globales pur cette compilation -->
<property name="projectName" value="MonProjet"/>
<property name="src" location="."/>
<property name="build" location="build"/>
<property name="dist" location="dist"/>
<property name="idl.dir" location="."/>
<property name="idl.file" location="Main.idl"/>
<target name="init">
<!-- Genere le timestamp -->
<tstamp/>
<!-- Cree le repertoire de compilation utilise par la partie compilation -->
<mkdir dir="${build}"/>
</target>
<target name="stubs" depends="init">
<echo>Genere les stubs, les classes helper et l'approche a partir du fichier IDL ${idl.file} </echo>
<exec executable="idlj" >
<arg value="-td" />
<arg value="${src}"/>
<arg value="-emitAll" />
<arg value="-f" />
<arg value="all" />
<arg value="-i" />
<arg value="${idl.dir}"/>
<arg value="${idl.file}" />
</exec>
</target>
<target name="compile" depends="stubs"
description="compile les sources" >
<!-- Compile le code java de ${src} vers ${build} -->
<javac srcdir="${src}" destdir="${build}"/>
</target>
<target name="dist" depends="compile"
description="Genere la distribution (archive)" >
<!-- Creer le repertoire de distribution -->
<mkdir dir="${dist}/"/>
<!-- Met le fichier dans ${build} dans le fichier ${projectName}-${DSTAMP}.jar -->
<jar jarfile="${dist}/${projectName}-${DSTAMP}.jar" basedir="${build}"/>
</target>
<target name="clean"
description="On passe le ballet !" >
<!-- On supprime les repertoires ${build} et ${dist} -->
<delete dir="${build}"/>
<delete dir="${dist}"/>
</target>
</project>
Ce fichier génère les classes à partir du fichier IDL spécifié, compile les classes nécessaires et créer automatiquement un fichier Jar contenant toutes les classes.
Etude des classes générées et leur relation d'héritage
Pour cette description, nous crééons le fichier IDL Hello.idl suivant :
La méthode sayHello devant renvoyer une string (au hasard, "Hello world !").
Coté serveur avec l'approche par héritage
On génère les fichiers avec la commande : # idlj -fserver Hello.idl On obtient trois fichiers :
- Hello.java
Interface Java héritant de l'interface HelloOperations de org.omg.CORBA.Object (pour s'assurer de la compatibilité nécessaire à CORBA)
- HelloOperations.java
Interface d'un objet distribué CORBA ayant pour définition de ses méthodes le fichier IDL Hello.idl
- HelloPOA.java
Classe abstraite définissant le squelette d'accès à l'objet d'interface Hello.
Elle hérite de org.omg.PortableServer.Servant, et implémente les interfaces InvokeHandler interface et HelloOperations.
Cette classe sera étendue par la classe serveur.
Coté client avec l'approche par héritage
On génère les fichiers la commande : # idlj -fclient Hello.idl
On obtient cinq fichiers :
- Hello.java
Même que pour le coté serveur
- HelloOperations.java
Même que pour le coté serveur
- _HelloStub.java
Classe est le stub pour le client. Elle fournit l'accès aux fonctionnalités CORBA pour le client.
Elle hérite de org.omg.CORBA.portable.ObjectImpl et implémente l'interface Hello.java.
- HelloHelper.java
C'est une classe abstraite qui fourni les méthodes pour les types IDL définit par les utilisateurs. Elle est responsable de la lecture et de l'écriture des types de données des flux CORBA et l'insertion et l'extraction des types de données à partir des Any.
- HelloHolder.java
Classe finale qui permet de gérer le fait qu'il n'existe pas en Java de passage en out et inout. Cette classe se charge donc de ce travail.
Elle implémente org.omg.CORBA.portable.Streamable.
Coté serveur avec l'approche par délégation
On génère les fichiers avec les commandes (en effet, pour obtenir tous les fichiers nécessaires à l'approche par délégation, il faut exécuter ces deux commandes) : # idlj -fserver Hello.idl
# idlj -fserverTIE Hello.idl
On obtient trois fichiers :
- Hello.java et HelloOperations.java
Ces deux fichiers sont similaires à ceux obtenu par l'approche par héritage.
- HelloPOATie.java
Classe définissant le squelette d'accès à l'objet d'interface Hello.
Elle hérite de HelloPOA.
