Introduction à CORBA (1)

Pierre Gançarski∗

Juillet 2007

Département d'informatique
UFR de Mathématique et Informatique
Université Louis Pasteur - Strasbourg

Bibliographie
Corba, des concepts à la pratique, Jean-Marc Geib, Christophe Gransart & Philippe Merle, Ed Masson
Au coeur de Corba avec Java, Jérome Daniel, Ed.Vuibert

1 Introduction
1.1 Plate-forme
Rappel sur les caractéristiques des applications distribuées :

 communication
 hétérogénéïté au niveau des matériels et des systèmes
 intégration de l'existant à l'intérieur d'une entreprise
 intéropérabilité entre diérents systèmes de diérentes entreprises (mise en place de normes)

S'il existe de nombreuses solutions pour faire communiquer des processus, celles-ci sont souvent de bas-niveau
et ne sont pas intégrées directement dans les langages de programmation. De plus, même les RPC associés à
XDR ne résolvent que les problèmes liés à la communication et à l'hétérogénéité (reste donc, l'intégration et
l'interopérabilité)
⇒utilisation de plates-formes réparties (middleware) qui orent :

 l'indépendance entre les applications et le système : chaque système ore des interfaces de programmation
spéciques pour contrôler les couches de communication. La plate-forme fournit aux applications des
interfaces standardisées masquant les spécicités du système

 la portabilité des applications : ces interfaces standardisées permettent de concevoir des applications
distribuées portables et indépendantes de l'environnement (peuvent être aisément recompilées)

 des services partagés : fonctionnalités système tels que la communication, la sécurité, les transactions, la
localisation, la désignation, l'administration, etc.
∗ Pierre.Gancarski@dpt-info.u-strasbg.fr

1
De fait, ces plates-formes sont standardisées pour être portables et interopérables ⇒dénitions entre construc-
teurs de middelware ouverts : DCE de l'OSF, ou X/Open
Une plate-forme répartie peut être vue aussi comme un bus qui permet d'interconnecter une ou plusieurs ap-
plications avec des services distribués et hétérogènes. Les interfaces standardisées permettant d'encher les
applications et les services.

Application Application Application

Interfaces standardisées

Plate-forme d’intégration (services partagés distribués)

communication localisation
environnement d’exécution sécurité
gestion réseau outils ...

Interfaces spécifiques aux systèmes d’exploitation

Système d’exploitation Système d’exploitation

réseau réseau
matériel matériel

1.2 La norme CORBA

CORBA (Common Object Request Brocker Architecture) est une telle plate-forme. Il est issu des travaux de
l'OMG (Object Management Group) et est basé sur la notion d'objets distribués : cette norme propose une
architecture de gestion d'objets répartis (Objwordect Management Architecture - OMA). Elle vise à prendre en
compte toutes les fonctionnalités nécessaires à la construction d'applications réparties.
Corba a été conçu pour permettre à des composants intelligents (des objets) de se découvrir les uns les autres
et d'interopérer sur un bus. Mais en plus, cette norme dénit un vaste ensemble de services associés au bus qui
permettent de créer/supprimer des objets, de leur assigner un nom, de les rendre persistant, d'externaliser leur
état, de dénir des relations entre eux, de traiter des transactions, .... Ainsi, grâce à ces services, on peut créer
un objet ordinaire puis le rendre persistant et/ou fonctionnel par la simple utilisation de ces services.
Ainsi, les objets Corba peuvent être distribués sur plusieurs sites ⇒ nécessité de mécanisme d'appel de méthodes
à distance. Le langage objet doit coopérer avec le système d'exploitation et les couches de communication réseau
pour réaliser les invocations entre les objets localisés sur des sites distants.
CORBA intègre donc un bus permettant la connection d'applications. Les objets communiquent alors de
manière transparente par l'intermédiaire d'objets souche appelés aussi mandataire, proxies ou surrogates :

 Une souche-cliente (intégrée dans une interface) est un représentant local d'un objet distant : il connaît
la localisation de l'objet et implante les mécanismes de communication pour invoquer l'objet (extension
des RPC).
 Une souche-serveur (intégré dans le serveur) est une extension à un objet, cette extension étant chargée
de transférer une demande distante (d'une souche-client) en un appel local de méthode.

L'appel de méthode à distance peut se shématiser par :

1 2 4 5
objet
client souche souche serveur
cliente serveur
10
7 6
9

Processus client Processus serveur

8
Réseau

2
CORBA est construit sur ce mécanisme qui donne aux objets la capacité via des interfaces décrites initialement
dans un langage propre à CORBA, le langage IDL (Interface Description Language) d'utiliser des services
distants.

1.3 Construction et lancement d'une application.

La mise en place d'une application CORBA nécessite :

 la construction des services, c'est-à-dire la création des classes d'objets capables

• de recevoir des demandes distantes (serveur)
• d'en envoyer (clients)
 l'utilisation d'objets issus de ces classes.

1.3.1 Création des classes

Etape 1 : Description du service par une interface en IDL, stockées dans un chier texte (par exemple Icarre.idl)
interface Icarre { long carre ( in long source ) ;
};

Etape 2 : Projection dans les langages cible : idlj -fall -oldImplBase Icarre.idl
A partir du chier IDL, génération automatique de pluiseurs classes :
 _IcarreImplBase.java (skeleton), _IcarreStub.java (proxy)
 IcarreHelper.java pour lire et écrire des objets implantant cette interface dans un ux par read()
et write() et pour convertir un objet CORBA en type Java, transtypage (ou cast en anglais) par
narrow()
 IcarreOperations.java, Icarre.java : interfaces Java correspondant à la projection du chier
IDL
 IcarreHolder.java (voir un peu plus loin, utile lors d'un passage de paramètres)
Option -f<side> avec side = [client|server|all] an de générer les chiers utilisés par le client, ou
par le serveur. Option -oldImplbase pour générer un certain type de squelette (non interopérable avec
des ORBs autre que Java SUN) mais facile à utiliser.
Etape 3 : Dénition d'une classe d'objets capables de réaliser localement les fonctions.
import o r g . omg .CORBA. ∗ ;
p u b l i c c l a s s I c a r r e I m p l extends _IcarreImplBase {
public int carre ( int source ) { return source ∗ source ; }
}

Etape 4 : Ecriture du serveur

import o r g . omg .CORBA. ∗ ;
public c l a s s Serveur {
p u b l i c s t a t i c v o i d main ( S t r i n g [ ] a r g s ) {
try {
ORB orb = ORB. i n i t ( a r g s , n u l l ) ;
I c a r r e I m p l myobj = new I c a r r e I m p l ( ) ;
S t r i n g i o r = orb . o b j e c t _ t o _ s t r i n g ( myobj ) ;
System . out . p r i n t l n ( i o r ) ;
orb . run ( ) ;
} c a t c h ( o r g . omg .CORBA. SystemException ex ) { System . e r r . p r i n t l n ( ex ) ; }
return ;
}
}

Le serveur créé un objet qui sera accessible à distance.

3
Etape 5 : Ecriture du client
Rappel : Pour pouvoir appeler un méthode distante l'objet doit :

 avoir une description de l'interface dans SON langage ;

 connaître l'identiant CORBA de l'objet serveur. En eet, pour pouvoir associer une interface
à un objet distant, il est indispensable de connaître son IOR (Indentier Object Request) qui est
son identiant universel. A partir de celui-ci, on peut le retrouver où qu'il soit dans le monde.
L'opération d'association prendra donc comme parametre un tel IOR.

import j a v a . i o . ∗ ;
import o r g . omg .CORBA. ∗ ;
public class Client {
p u b l i c s t a t i c v o i d main ( S t r i n g a r g s [ ] ) {
i n t nombre = 2 ;
int res ;
try {
ORB orb = ORB. i n i t ( a r g s , n u l l ) ;
String ior = args [ 0 ] ;
o r g . omg .CORBA. Object o b j = orb . s t r i n g _ t o _ o b j e c t ( a r g s [ 0 ] ) ;
I c a r r e s e r v i c e = I c a r r e H e l p e r . narrow ( o b j ) ;
r e s=s e r v i c e . c a r r e ( nombre ) ;
System . out . p r i n t l n ( " Res : " + r e s ) ;
} c a t c h ( o r g . omg .CORBA. SystemException ex ) { System . e r r . p r i n t l n ( ex ) ; }
}
}

1.3.2 Compilation et lancement

 javac *.java
 java Serveur (sur la machine du serveur). Cela génère une IOR (identiant unique sur le réseau) en
achage qui est la référence sur l'objet myobj

 java Client <IOR> (sur la machine du client)

2 Le langage d'interfaces IDL

En Corba, toutes les interfaces doivent être dénies à l'aide du langage de dénition d'interface (Interface
Denition Language) IDL. L'intérêt majeur du langage IDL est de permettre la dénition de contrats entre
des fournisseurs de services et des utilisateurs. Ce contrat s'exprime sous la forme d'un ensemble d'interfaces
clairement spéciées avec IDL : les clients ne voient pas les détails d'implantation.
Les contrats IDL sont projetés dans les environnement de programmation pour donner des souches IDL pour
les programmes clients et des squelettes IDL pour les fournisseurs.
La norme Corba, donne des régles pour la projection des descriptions IDL en un langage cible. Elles représentent,
par exemple pour C++, 4 chapîtres de la norme.

Attention Le langage IDL est fortement inspiré de C++ mais ce n'est pas du C++ !!!!

2.1 Modules et interfaces

Un module est un espace de dénition décrivant d'une part une ou plusieurs interfaces et d'autre part, l'environnement
(types, attributs, exceptions) nécessaire à celles-ci:

 espace de dénition : module < nom > { <ensemble de déclarations> };

 interface : interface <nom > { <ensemble de déclarations> };

4
• exemple :
module Planning {
struct UneDate { short jour,mois,annee;} ;
typedef short Int;
Attribute UneDate Aujourdhui;
exception PasUneDate { UneDate d; }
interface Idate { ... }
}

2.2 Types de base et types construits.

Comme dit, IDL est proche de C++. Ainsi par exemple, les commentaires, les déclarations de type (typedef),
de variables, les constructions de structures (struct), de classes sont identiques1 à C++.
Quelques ajouts dont principalement les séquences qui permettent de dénir des ensembles dynamiques de
valeurs homogènes : le nombre d'éléments d'une séquence est xé à l'exécution.

2.2.1 Types de base et projection :

CORBA IDL C++ Java

short CORBA::Short short
char CORBA::Char char
double CORBA::Double double
string CORBA::String String
boolean CORBA::Boolean boolean

2.2.2 Typedef

Même syntaxe et utilisation qu'en C++

• Exemple : typedef short Int;
• Attention si le type C++ existe, la régle change le type est alors traduit par : typedef CORBA::Short _cxx_int;

2.2.3 Séquences

Ce sont des tableaux de taille dynamique.

Ainsi, typedef sequence<short> DesEntiers; ou typedef sequence<short,10> DesEntiers;
déclare un tableau d'entiers de taille dynamique

2.2.4 Structures

Déclaration identique qu'en C++

Exemple : struct UneDate { short jour, mois, annee ; } ;

2.3 Attributs
Un attribut est une spécication décrivant une propriété d'un objet clairement dénie dans son interface.
<mode> attribute <type> <nom>;
Un attribut peut être accédé en lecture-écriture (mode par défaut) ou en lecture seulement (mode : readonly)
Exemple : interface Idate { attribute short Aujourdhui; }
1 mais n'ont pas nécessairement les mêmes eets ou comportements !

5
2.4 Opérations
2.4.1 Déclaration

<mode d'invocation> <type> <nom> (<parametres>)

[raises (<liste exception>)]
[context (<liste contextes)];
avec :

 mode d'invocation : par défaut, un appel est synchrone (le client attend la n de l'opération). Le mode
d'invocation oneway rend l'appel asynchrone.

 liste des paramètres : pour TOUS les paramètres il faut dénir leur mode de passage
• in : transport du client vers l'objet ;
• out : transport en retour de l'objet vers le client ;
• inout : transport dans un sens puis dans l'autre.

 liste des exceptions : indique les exceptions pouvant être déclenchées par cette opération (interdit en
oneway) (cf 2.4.2)

 liste des contextes : permet de transmettre l'équivalent de variables d'environnement depuis le client vers
les objets (peu utilisé)

Exemple :
interface Idate
{ exception NumeroNonValide { short num; };
Boolean DonnerDate(in short Numero_jours, out UneDate D) raises (NumeroNonValide); }
Le raises est indispensable pour que l'interruption soit transmise (du serveur) au client.
Lors de l'implantation, l'invocation d'opération et l'accès à des attributs se font à travers le mécanisme d'appel
de méthode du langage d'implantation (. en Java, -> ou . en C++).
• ATTENTION : IDL n'admet pas la surcharge des opérateurs.

Passage de paramètres : Les trois modes de passages des paramètres ne sont pas disponibles dans tous les
langages.
Ainsi, en Java, seul le mode de passage par valeur est présent. Pour les modes inout ou out, le pré-compilateur
génére, pour chaque type IDL, une classe conteneur composée d'un unique attribut. Ainsi, pour recevoir une
valeur en sortie, le programmeur crée une instance d'une classe conteneur et l'opération stocke la valeur à
retourner dans cet objet.
C++ autorise les divers modes.

2.4.2 Exceptions

IDL permet de dénir des classes d'exceptions par :

interface Idate
{ exception NumeroNonValide { short num; };
Boolean DonnerDate(in short Numero_jours, out UneDate D) raises (NumeroNonValide);
}

6
2.5 Héritage
IDL admet un héritage multiple à la seule condition qu'il n'y ait pas de conit d'héritage sur les attributs ou
les opérations. Par contre, l'héritage répété ne pose pas de problemes.
interface <nom-interface-derivee> : <nom classe mere> { ... };
Prenons l'exemple suivant :
interface Iecho {
string Hello(in string msg);
double Compte(in string msgr); };
interface Icar : Iecho { void EtVoila() ; };
Au niveau de l'implantation, deux approches possibles (seront vues plus tard)

3 Le bus CORBA
3.1 Caractéristiques principales du bus
 liaison avec les langages de programmation (C++, C, Eiel, Java, Smalltalk, ...) via des interfaces en IDL
(qui décrivent les services rendus, mais qui devront être traduites dans le langage cible)

 transparence totale des invocations : le bus CORBA transporte les invocations d'opérations sur les objets
en choisissant automatique le meilleur moyen de transport ⇒ un utilisateur a toujours l'impression de
faire un appel local.

 invocation statique ou dynamique : CORBA fournit deux mécanismes distincts pour invoquer des objets
• statique : les invocations sont construites avant la compilation et vériées lors de celle-ci. Le résultat
de la projection des descriptions IDL dans le langage cible forme alors le Static Invocation Interface
(SII) : à chaque interface IDL est associée une interface d'invocation statique
• dynamique : à partir d'informations contenues dans le Référentiel des Interfaces (base de données
encapsulées dans des objets CORBA, contenant toutes les dénitions IDL des objets) un programme
peut via la Dynamique Invocation Interface (DII), construire dynamiquement une invocation. C'est
plus souple mais ça ralenti l'exécution. De plus, l'utilisateur doit spécier chaque élément de la
requête (objet cible, opération, paramètres, etc.)

 système auto-descriptif : le bus CORBA contient des métadonnées décrivant les interfaces des objets.
Elles sont stockées dans le référentiel des interfaces. Ce référentiel contient aussi une version compilée de
TOUS les composants logiciels du bus lui-même. Toute application peut donc invoquer directement les
objets du bus

 activation automatique des objets : CORBA se charge d'activer les objets c'est-à-dire de réserver si
nécessaire, de la place en mémoire et de leur trouver un environnement d'exécution. Plusieurs stratégies :
un processus par objet, un processus pour plusieurs objet ou un processus par exécution d'opération

 communication entre diérents bus : CORBA dénit, sans imposer de technologie pour l'implanter, un
ensemble de règles et de protocoles permettant le dialogue entre diérentes implantations de ce bus

• soit par des passerelles ou des demi-ponts convertissant les requêtes entre les diérents bus
• soit par l'utilisation de protocoles communs au niveau des requêtes :
· GIOP (General Inter-ORB Protocol) : permet d'instantier des protocoles d'interopérabilités
réseau entre diérents fournisseur. Ainsi, le protocole d'interopérabilité sur internet, IIOP (In-
ternet Inter-ORB Protocol) est une instance de GIOP pour TCP/IP
· ESIOP (Environment Specic Inter-ORB Protocol) : permet d'instantier des protocoles d'inter-
opérabilités entre diérents environnements. Ainsi, DCE/CIOP (Distributed Computing Environ-
ment/Common Inter-ORB Protocol) permet, à partir de CORBA d'utiliser le mécanisme d'appel
de DCE.

7
3.1.1 Les composantes du bus CORBA :

Programmes utilisateur Programmes fournisseurs

Client Client & Serveur
d’objets serveur d’objets

4 9
Référentiel des Référentiel des
interfaces implantation

7
6 Interfaces de 8

2 3 Interfaces de Squelettes Interfaces de

Squelettes Dynamique l’Adaptateur
Interface Interface 5 Statiques (DSI) d’Objets
d’invocation d’Invocation Interface
Statique (SII) Dynamique (DII) ORB Adaptateur d’Objets

Noyau de l’Object Request Brocker

Protocole Inter-ORB Interbnet (IIOP)

1. noyau de communication : assure le transport des invocations

2. Interface invocation statique : vue précédemment

3. la DII remplace les stubs IDL dans le cas d'une découverte dynamique d'un service. Il permet d'obtenir
la référence d'un service, de générer les paramètres, d'eectuer l'invocation et d'obtenir les résultats.
4. Référentiel d'interfaces : contient la base de données qu'utilise la DII pour obtenir les interfaces des
services enregistrés.

5. interface de l'ORB : fournit les primitives de base pour l'initialisation, le paramètrage de l'environnement
de CORBA, l'instanciation des références ainsi que la gestion de la mémoire

6. interface de squelettes statiques (Static Skeleton Interface) : s'occupe de déballer les requêtes (et
leurs paramètre) et d'emballer les résultats. C'est la partie serveur des stubs IDL.

7. interface de squelettes dynamiques (Dynamic Skeleton Interface) : permet de recevoir les requêtes
sans disposer a priori des squelettes de déballages. Cette interface est par exemple, utilisée pour implanter
des passerelles entre le bus et un autre environnement.

8. (interface de l') adaptateur d'objets (cf 8): Il se place au dessus des services de communication de
l'ORB. Il accepte les requêtes d'accès aux services des objets du serveur. Il constitue l'environnement
d'exécution pour instancier, invoquer, assigner des référence objets. Il forme donc, le bloc fonctionnel
auquel le noyau de communication délègue l'exécution des requêtes -> activation des processus portant
les objets, requêtes à des bases de données, etc

9. référentiel des implantations : constitue la base de données des classes supportées, des objets instanciés
et de leurs références objets. Il conserve aussi des informations complémentaires comme celles de suivi,
d'audit, de sécurité et d'administration.

3.1.2 Adaptateur d'objets

A un instant donné, tous les objets existant dans CORBA, ne sont pas nécessairement utilisés.
⇒L 'OMG a donc proposé un mécanisme associant DYNAMIQUEMENT une implantation à un objet CORBA
C'est-à-dire :

 un espace mémoire pour stocker l'état d'un objet

 un contexte d'exécution pour ses opérations.

8
Ce mécanisme est totalement transparent et est réalisé par les adaptateurs d'objets. Un AO se place au dessus
des services de communication de l'ORB. Il accepte les requêtes d'accès aux services des objets du serveur.
Il constitue l'environnement d'exécution pour instancier, invoquer et assigner des référence objets, activer des
processus portant les objets, traiter des requêtes à des BD, etc

4 catégories d'AO en fonction du mode d'activation:

 serveur partagé : 1 processus pour tous les objets

 serveur non partagé : 1 processus ou thread par objet
 serveur par méthode : 1 processus par requête
 serveur persistant : l'AO fonctionne en serveur partagé mais ses requêtes sont traitées par un ordonnanceur

Il existe diérents types d'adaptateur d'objets :

 adaptateur élémentaire (Basic Object Adapter)2 , présent dans TOUTES les implantation de Corba. Il
considère que les objets sont implantés directement dans des processus pouvant être indépendants ;

 adaptateur de bibliothèques d'objets (Library Object Adapter) prend en charge les objets Corba dont
l'implantation est stockée dans des bibliotheques de codes ;

 adaptateur de bases de donnéees objets (Object-Oriented Database Adapter) fait le liaison entre le bus
Corba et une BDOO.

Le BOA3 constituait l'adaptateur objet minimal et orait les fonctionnalités suivantes :

 il pouvait gèrer le référentiel d'implantation qui contient par exemple, le nom des exécutables stockant le
code d'implantation des objets ;

 il générait et interprétait les références objets ;

 il activait et désactivait les implémentations ;
 il appellait les méthodes à travers les squelettes et transfèrait les paramètres ;
 il authentiait le client.

Malheureusement, cet adaptateur avait été sous-spécié et a donc donné lieu à des implantations diérentes des
fonctionnalités. De plus, il s'est avéré insusant et incomplet.
Un nouvel adaptateur a donc été spécié : le POA Portable Object Adaptator. (cf 4)

4 POA
4.1 Présentation
Le POA fournit un ensemble d'outils qui permettent d'aner le comportement d'un serveur et de contrôler le
traitement d'une requête côté serveur.
Trois éléments :

servant : entité qui implante une interface IDL

serveur : entité qui loge un ensemble de servants
référence d'objet : vue cliente d'une interface IDL (son IOR)
2 obsolète : remplacé par le POA (cf 4)
3 encore disponible dans quelques implantations CORBA, dont Mico.

9
4.1.1 Servant

Dans un BOA, c'est l'objet référence qui réalise directement le service : lorsqu'une réquête est envoyée à un
IOR , c'est l'objet référencé par cet IOR qui réalise l'opération associée.
Dans l'approche POA, un objet réalisant un service n'est pas directement accèdé : lorsqu'il a quelque chose à
faire, c'est un objet d'implantation du service (un servant ) qui reçoit la requête et qui la transmet à l'objet qui
réalise alors réellement le service.

Requete Requete
transmise

Servant
Client Objet service

PAO

ORB

Pourquoi ? Cela permet d'associer plusieurs servants à un objet service. Les servants pouvant présenter des
interfaces diérentes à condition bien sûr que l'objet service implante les méthodes correspondant aux diérentes
interfaces.

4.1.2 Serveur

Un serveur ou POA est un objet qui contient un ensemble de servants. Réciproquement, tout servant appar-
tient à un serveur.
Ainsi, pour pouvoir réaliser un service, il faut

 créer l'objet service

 et d'une part, disposer d'un POA et d'autre part, créer dans celui le(s) servant(s).

Un POA dispose d'un ensemble de régles (policies) qui dénissent les traitements des requêtes : gestion de la le
d'attentes des requêtes, concurrence, etc. La gestion des requêtes est alors assurée par un objet supplémentaire :
le POA manager.

4.2 Premier exemple

4.2.1 Interface

i n t e r f a c e I e c h o { s t r i n g H e l l o ( i n s t r i n g msg ) ; }

4.2.2 Implantation du service

• En Java
. Description du serveur dans le chier : IechoImpl.java
p u b l i c c l a s s I e c h o I m p l e x t e n d s IechoPOA {
p u b l i c S t r i n g h e l l o ( S t r i n g msg ) {
r e t u r n " H e l l o ` ` + msg + " from " + l o c a t i o n ; }
}

10
. Lancement du serveur dans le chier : Server.java
public c l a s s Server {
p u b l i c s t a t i c v o i d main ( S t r i n g [ ] a r g s ) {
ORB orb = ORB. i n i t ( a r g s , n u l l ) ;
// I n i t i a l i s a t i o n d ' un POA : Le RootPOA e s t l e POA par d é f a u t ( t o u j o u r s p r é s e n t )
POA poa = POAHelper . narrow ( orb . r e s o l v e _ i n i t i a l _ r e f e r e n c e s ( "RootPOA " ) ) ;
// L ' o p é r a t i o n the_POAManager ( ) donne l e manager a s s o c i é au POA
poa . the_POAManager ( ) . a c t i v a t e ( ) ;
// C r é a t i o n de l ' o b j e t s e r v i c e
I e c h o I m p l UnServeurIecho = new I e c h o I m p l ( a r g s [ 1 ] ) ;
// A c t i v a t i o n de l ' o b j e t => a s s o c i e l ' o b j e t s e r v i c e à un s e r v a n t
// e t r e t o u r n e l a r é f é r e n c e de c e s e r v a n t
o r g . omg .CORBA. Object o b j _ s e r v a n t = poa . s e r v a n t _ t o _ r e f e r e n c e ( UnServeurIecho ) ;
// on l ' a f f i c h e l a r é f é r e n c e de l ' o b j e t _ s e r v a n t
System . out . p r i n t l n ( orb . o b j e c t _ t o _ s t r i n g ( o b j _ s e r v a n t ) ) ;
// on met l 'ORB en a t t e n t e de r e q u e t e
orb . run ( ) ; }
}
}

4.2.3 Le client

• En Java
Fichier : Client.java
public class Client {
p u b l i c s t a t i c v o i d main ( S t r i n g a r g s [ ] ) {
try {
S t r i n g i o r _ s e r v a n t = a r g s [ 0 ] ; // on r é c u p è r e l ' i o r du s e r v a n t
ORB orb = ORB. i n i t ( a r g s , n u l l ) ;
// C r é a t i o n de l ' o b j e t de c o n n e c t i o n
o r g . omg .CORBA. Object o b j = orb . s t r i n g _ t o _ o b j e c t ( i o r _ s e r v a n t ) ;
// Connection d ' une i n t e r f a c e v i a l ' o b j e t de c o n n e c t i o n
I e c h o U n e I n t e r f a c e I e c h o = I e c h o H e l p e r . narrow ( o b j ) ;
// demande du s e r v i c e
System . out . p r i n t l n ( U n e I n t e r f a c e I e c h o . h e l l o ( "COUCOU" ) ;
} c a t c h ( E x c e p t i o n ex ) { System . e r r . p r i n t l n ( ex ) ; }
}
}

11