1 RMI/IIOP

- 1 -
Implantation de la fonctionnalité RMI/IIOP dans
l’infrastructure logicielle Jonathan
Kathleen Milsted
Bruno Dumant
France Télécom R&D
Kelua SA
DTL/ASR

- 2 -
1 RMI/IIOP
Ce paragraphe décrit RMI/IIOP de façon générale. Son implantation dans Jonathan est décrite
dans la section 2.
1.1 Définition des termes
D’abord, il est utile de distinguer trois différentes plates-formes réparties à objets :
 une plate-forme RMI/JRMP : offre le modèle de programmation répartie « Java RMI »
implanté sur un système de communication utilisant le protocole propriétaire JRMP de
Sun.
 une plate-forme CORBA : offre le modèle de programmation répartie « CORBA » implanté
sur un ORB utilisant le protocole IIOP normalisé par le consortium OMG.
 une plate-forme RMI/IIOP : offre le modèle de programmation Java RMI mais implanté
sur un ORB utilisant le protocole IIOP.
Ainsi, RMI/IIOP est avant tout la transposition du modèle de programmation répartie Java RMI
dans le monde CORBA. En d’autres termes, il s’agit de faire du Java RMI en s’appuyant sur
CORBA.
La transposition du modèle Java RMI en CORBA se définit par deux normes de l’OMG
(disponibles à http://www.omg.org) :
- Java to IDL : cette spécification définit les éléments nécessaires pour mapper le modèle de
programmation Java RMI sur le modèle de programmation CORBA (avec quelques
extensions). Elle comprend des extensions à un ORB implanté en Java pour supporter ce
modèle CORBA étendu.
- Objects by Value : cette spécification définit les extensions au modèle CORBA pour
supporter le passage d’objets par valeur. Ceci est autorisé par le modèle Java RMI mais pas
dans le modèle CORBA jusqu’à présent.
Ainsi, RMI/IIOP n’est pas l’objet d’une spécification en elle–même mais plutôt l’union des
deux normes ci-dessus avec notamment la déclinaison Java de la deuxième. La description qui
suit résume les principales caractéristiques de RMI/IIOP extraites des deux normes, complétées
par des références aux outils de génération de code fournis avec la plate-forme RMI/IIOP de
référence de Sun et IBM.
1.2 Principales caractéristiques de RMI/IIOP
1.2.1 RMI/IDL : langage de définition d’interfaces
RMI/IDL correspond à un sous-ensemble de Java qui peut être utilisé pour définir les interfaces
d’objets dans les deux modèles répartis Java RMI et CORBA. Il représente en quelque sorte
l’intersection de ces deux modèles en terme de définition d’interfaces. RMI/IDL est défini par
le biais de restrictions syntaxiques (donc vérifiables statiquement) sur la définition en Java

- 3 -
d’interfaces remote, de classes sérialisables, de classes externalisables, de tableaux,
d'exceptions, etc.
1.2.2 Traduction de RMI/IDL en IDL 2.3
Les restrictions syntaxiques imposées sur RMI/IDL permettent sa traduction en un sous-
ensemble d’IDL 2.3 (sans struct ni union, ni enum).
Quelques éléments de la traduction de RMI/IDL en IDL 2.3 sont :
- les interfaces remote sont traduites en des types interfaces (indiquant le passage d’objets
par référence) ;
- les classes sérialisables sont traduites en des types valeurs (indiquant le passage d’objets
par valeur) ;
- les classes externalisables sont traduites en des types valeurs customisables (indiquant le
passage d’objets par valeur mais avec possibilité de surcharger l’encodage/décodage des
valeurs) ;
- la génération de certains identificateurs au lieu d’une simple transposition d’un langage à
l’autre afin de pallier aux incompatibilités entre les deux langages (ex : Java respecte la
casse d’identificateurs mais pas IDL, les noms de méthodes peuvent être surchargés en
Java mais pas en IDL).
Dans la plate-forme RMI/IIOP de référence de Sun et IBM, la traduction de RMI/IDL en IDL
2.3 est réalisée par l’outil rmic avec l’option –idl.
1.2.3 API plate-forme RMI/IIOP
RMI/IIOP nécessite de nouvelles APIs plate-forme en plus de celles définies par le mapping
OMG d’IDL vers Java. Une plate-forme RMI/IIOP est donc une plate-forme CORBA en Java
dotée d’une API supplémentaire spécifique. Cette dernière se définit par un ensemble
d’interfaces et classes Java, sous-entendant le fait que toute plate-forme RMI/IIOP est
implantée en Java.
1
L’API est définie par :
- javax.rmi.CORBA.Tie : une interface que chaque tie RMI/IIOP doit implanter ;
- javax.rmi.CORBA.Stub : une classe abstraite que chaque stub RMI/IIOP doit étendre.
En particulier, elle définit des méthodes pour les sérialisation et désérialisation de stubs
RMI/IIOP dans des streams GIOP ;
- javax.rmi.CORBA.ValueHandler : une interface définissant des méthodes pour la
sérialisation et désérialisation d’objets Java dans des streams GIOP ;
- javax.rmi.CORBA.Util : une classe utilitaire de méthodes statiques utilisés par des
stubs ;
- javax.rmi.PortableRemoteObject : une classe permettant d'exporter des objets servants,
c'est-à-dire de les enregistrer dans l'ORB pour les rendre accessibles à distance.
En ce qui concerne l’implantation de cette API, Sun inclut des implantations par défaut dans le
JDK à partir de la version 1.3. Toutefois, des implantations alternatives (le cas pour Jonathan)
sont possibles via des interfaces déléguées (javax.rmi.CORBA.StubDelegate,
javax.rmi.CORBA.UtilDelegate et javax.rmi.PortableRemoteObjectDelegate).
1
Le modèle de programmation répartie Java RMI a été défini sur la base du modèle d’objets
Java ; ainsi, toute plate-forme répartie offrant le modèle Java RMI (c’est à dire, RMI/JRMP et
RMI/IIOP) se doit d’être implantée en Java. En revanche, le modèle de programmation réparti
de CORBA n’a pas été défini avec un modèle langage particulier en vue ; dans la mesure de
possible, une plate-forme CORBA peut donc être implantée en différents langages (C++, Java,
Smalltalk, Ada, C, Cobol, ...

- 4 -
1.2.4 Génération de stubs et ties RMI/IIOP
Une classe de tie est générée pour chaque classe d’implémentation ; la classe de tie étend la
classe javax.rmi.CORBA.Tie. Une classe de stub est générée pour chaque interface remote :
par exemple, si Foo est une interface remote, une classe _Foo_Stub sera générée qui
implémente Foo et qui étend javax.rmi.CORBA.Stub. Les stubs peuvent contenir du code
permettant d’optimiser le chemin d’appel dans le cas où un objet servant est local.
Dans l’implantation de référence de RMI/IIOP par Sun et IBM, la génération des stubs et ties
est réalisée par l’outil rmic avec l’option –iiop. Par défaut, les stubs générés contiennent du
code pour optimiser des appels locaux mais la génération de ce code peut être inhibée avec
l’option supplémentaire –nolocalstubs.
La génération des stubs et ties peut aussi être réalisée par l’outil idlj à partir de IDL 2.3. En
plus des stubs et ties, idlj génère également les classes d’interface les classes helper et holder
conformément au mapping CORBA de IDL vers Java. L’outil idlj diffère donc d’un
compilateur idl2java par le fait que les stubs et ties générés sont ceux de RMI/IIOP et non de
CORBA.
La figure 1 permet de situer les différents outils et ce qu'ils génèrent.
Figure 1
A noter qu’un stub (tie) RMI/IIOP n’est pas un stub (tie) CORBA. Bien que les deux utilisent
IIOP comme protocole de transport, les premiers utilisent l’API supplémentaire de RMI/IIOP et
non les API de CORBA. Toutefois, les deux sont compatibles, c’est à dire, ils peuvent
communiquer sous certaines conditions. Voir la section 2.3 qui décrit les cas d’interopérabilité.
1.2.5 API de développement
Chaque plate-forme à objets fournit une API aux développeurs d’applications.
RMI/IDL
RMI/IDL
(subset of Java)
RMI/IIOP stubs,
ties
(Java)
CORBA interface,
helper, holder
(Java)
rmic -iiop
subset of
IDL 2.3
rmic -idl
idlj
RMI/JRMP stubs,
skeletons
(Java)
rmic

- 5 -
Dans le cas d’une plate-forme RMI/JRMP, l’API de développement côté serveur comprend
notamment la classe java.rmi.server.UnicastRemoteObject. Les interactions avec le système de
transport sous-jacent sont implicites et cachées du développeur d’applications derrière les
méthodes de cette classe.
Dans le cas d’une plate-forme CORBA, l’API de développement côté serveur offre deux styles
de programmation : par héritage d’une classe racine d’implémentation ou par délégation à une
classe de tie. Les opérations de connexion et déconnexion à l’ORB sont explicites côtés serveur
et client et codées par le développeur d’applications.
Dans le cas d’une plate-forme RMI/IIOP, l’API de développement repose sur la classe
javax.rmi.PortableRemoteObject. En effet, cette classe cache une API CORBA derrière des
méthodes similaires à java.rmi.server.UnicastRemoteObject. Ainsi, le développeur fera du
CORBA mais implicitement, masqué par un style de programmation plus léger à la
RMI/JRMP.
Côté client, une différence est à noter entre les API de RMI/JRMP et de RMI/IIOP. Pour le
premier, il suffit de caster le type en Java pour transformer une référence RMI/JRMP en un
objet typé. Pour RMI/IIOP, la méthode statique javax.rmi.PortableremoteObject.narrow doit
être utilisée pour transformer une référence RMI/IIOP en un objet typé.
En ce qui concerne l’implantation de javax.rmi.PortableRemoteObject, Sun inclut une
implantation par défaut dans le JDK à partir de la version 1.3. Toutefois, une implantation
alternative (le cas pour Jonathan) est possible via une interface déléguée
(javax.rmi.PortableRemoteObjectDelegate).
1.2.6 Téléchargement et localisation de code
Le téléchargement de code à partir d’une URL est l'une des principales caractéristiques d’une
plate-forme RMI/JRMP. Cette fonctionnalité doit exister aussi pour une plate-forme RMI/IIOP.
Ainsi, les classes des stubs et des valeurs (classes sérialisables et externalisables) doivent
pouvoir être chargés à distance à partir d’une URL. La valeur du codebase (une chaîne
contenant une suite d’URL séparée par des blancs) est transmise dans les messages GIOP.
A noter que cette notion de téléchargement de code à partir d’une URL n’est pas supportée par
une plate-forme CORBA. En revanche, la localisation de code est supportée par le biais d’une
interface repository ; quand une IOR (référence d’objet CORBA) est transmise, elle est
toujours accompagnée d’un repository ID qui pourrait être utilisé comme clé pour rechercher
dans l’interface repository un type pour gérer la référence (ex : pour typer la référence). Ainsi,
au lieu de localiser des classes dans des URL, elles sont localisées dans l’interface repository.
Avec Objects by Value, cette idée est étendue aux valeurs qui sont aussi transmises avec un
repository ID indiquant un type à utiliser pour instancier la valeur côté récepteur. Le concept
d’usine à valeurs (value factory) est aussi introduit dans CORBA 2.3 pour correspondre à cette
notion d’instantiation ; dans le binding IDL 2.3 to Java, une usine à valeurs est simplement une
classe (instance de java.lang.Class).
1.2.7 Services de nommage
Les deux normes, Java to IDL et Objects by Value, ne parlent pas de services de nommage.
Toutefois, il est clair que le service de nommage CORBA (CosNaming) est utilisé pour stocker
des références à des objets RMI/IIOP tandis que le registry RMI/JRMP est utilisé pour stocker