Cours Informatique Répartie

Chapitre 6

CORBA
Common Object Request Broker Architecture
 Concepts clés
Permettre l’interopérabilité des composants / applications
par l’intermédiaire d’un mode de coopération unifié :
l’appel d’objets distants
Transparence des invocations

Gérer l’hétérogénéité des réseaux, machines, systèmes

et langages
Langage pivot commun

Offrir une architecture globale

INTRODUCTION
 CORBA (Common Object Request Broker Architecture) est né
en 1992 du besoin de faire communiquer ensemble des
applications en environnement hétérogène (plusieurs systèmes
et plusieurs langages)

 CORBA est une spécification, un standard qui décrit une

architecture logicielle, un environnement réparti (middleware).

 L’ OMG(Object Management Group) est l’organisme qui a

spécifié CORBA. L’ OMG créé en 1989, est un consortium qui
regroupe plus de 800 entreprises du monde entier.

 L'OMG définit des spécifications pour fournir un modèle de

coopération entre objets répartis. Il spécifie tous les constituants
d'un modèle objet global appelé O.M.A. ( Object Model
Architecture )
OMG ..Architecture globale
Cette architecture globale, OMA, vise à classifier les
différents objets qui interviennent dans une application
répartie en fonction de leurs rôles

Le middleware CORBA est une partie du modèle

OMA

Il faut considérer CORBA comme une architecture basée

sur un bus nommé ORB (Object Request Broker) bus à
requête à objet
Object Model Architecture (OMA)
Architecture Globale OMA
 Le bus d’objets répartis assure le transport des requêtes entre
tous les objets CORBA. Il offre un environnement d’exécution
aux objets masquant l’hétérogénéité liée aux langages de
programmation, aux systèmes d’exploitation, aux processeurs
et aux réseaux.

 Les services objet communs (CORBAservices) fournissent

sous forme d’objets CORBA, spécifiés grâce au langage IDL,
les fonctions systèmes nécessaires à la plupart des
applications réparties.

 Actuellement, l’OMG a défini des services pour les annuaires

le cycle de vie des objets, les relations entre objets, les
événements, les transactions, la sécurité, la persistance, etc.
Au fur et à mesure des besoins, l’OMG ajoute de nouveaux
services communs.
services objet communs
 Le service d’annuaire : permet d’associer des objets CORBA à des
noms et offre au client un moyen simple et standard pour retrouver
l’objet
 Le service de persistance : il assure la persistance (la sauvegarde)
d’un objet CORBA dans une BD.
 Le service cycle de vie : gère la création, le déplacement et la
destruction des objets du bus CORBA
 Le service de concurrence d’accès: gère les mécanismes pour
ordonnancer les accès concurrents sur des objets CORBA
 Le service de requête : permet d’interroger des attributs d’objets
 Le service de sécurité : fournit tous les élements pour sécuriser
l’environnement CORBA. Il offre également des mécanismes de haut
niveau de protection, comme la non-répudiation qui permet de
prouver qu’une opération a bien été invoquée et d’identifier par qui
elle l’a été
…
 OMA
 Les utilitaires communs (CORBAfacilities) sont des canevas
d’objets (« Frameworks ») qui répondent plus particulièrement
aux besoins des utilisateurs. Ils standardisent l’IHM, la gestion
de l’information le Datawarehouse, l’administration, etc.

 Les interfaces de domaine (Domain Interfaces) définissent des

objets de métiers spécifiques à des secteurs d’activités comme
la finance (e.g. monnaie électronique), la santé (e.g. dossier
médical) et les télécoms (e.g.transport multimédia). Leur
objectif est de pouvoir assurer l’interopérabilité sémantique
entre les systèmes d’informations d’entreprises d’un même
métier : les « Business Object Frameworks » (BOFs).
Le protocole IIOP
 L’interopérabilité entre bus : un protocole générique de transport des
requêtes (GIOP pour General Inter-ORB Protocol) a été défini
permettant l’interconnexion de bus CORBA provenant de
fournisseurs distincts.
 La popularité de l’Internet à ensuite amené les concepteurs de la
norme CORBA à définir un protocole de communication entre les
objets adapté à Internet fonctionnant au dessus de TCP/IP. Ce
protocole s’appelle IIOP (Internet Inter-ORB Protocol)

 Les participants à un échange CORBA communiquent à l'aide du

protocole IIOP

 Le protocole IIOP est indépendant du langage de programmation,

du système d'exploitation et de la machine utilisée.
 IIOP est un standard pour l’interopérabilité entre objets
 Principe de CORBA
 Un ORB est réalisé sous forme d’une bibliothèque de
fonctions qui permettent de mettre en œuvre les coopérations
entre clients et serveurs.

 Le bus CORBA propose un modèle orienté objet client/serveur

d’abstraction et de coopération entre les applications réparties
 Chaque application peut exporter certaines de ses fonctionnalités
(services) sous la forme d’objets CORBA : c’est la composante
d’abstraction (structuration) de ce modèle
 Les interactions entre les applications sont alors matérialisées par
des invocations à distance des méthodes des objets : c’est la
partie coopération
 L’application implantant l’objet est le serveur, l’application utilisant
l’objet est le client.
 Bien entendu, une application peut tout à fait être à la fois cliente
et serveur.
Schéma Principe de CORBA

Bus CORBA
L’Object Request Broker (ORB)
Le cœur de CORBA est constitué par l’ORB qui est le
bus (le conduit) par lequel les requêtes sur les objets
transitent.

L’ORB gère les transferts entre les clients et les

serveurs.
L’adaptateur d’objets, est quand à lui chargé de la
gestion des références aux objets et de l’activation des
implémentations :
l’adaptateur d’objets est donc, comme son nom
l’indique, le canal par lequel l’ORB est connectée à
l’implémentation de l’objet
 Principe de CORBA
 L’application cliente est un programme qui invoque les méthodes
des objets à travers l’ORB (le bus CORBA).
 La référence d’objet est une structure désignant l’objet CORBA et
contenant l’information nécessaire pour le localiser sur le bus.
 L’interface de l’objet est le type abstrait de l’objet CORBA
définissant ses opérations et attributs (classe abstraite ou
interface). Celle-ci se définit par l’intermédiaire d’une interface IDL
du langage OMG-IDL .
 La requête est le mécanisme d’invocation d’une méthode ou
d’accès à un attribut de l’objet.
 Le bus CORBA achemine les requêtes de l’application cliente vers
l’objet en masquant tous les problèmes d’hétérogénéité (langages,
systèmes d’exploitation, matériels, réseaux).
 L’objet CORBA est le composant logiciel cible. C’est une entité
virtuelle gérée par le bus CORBA.
Principe de CORBA
 L’activation est le processus d’association d’un objet
d’implantation à un objet CORBA.

 L’implantation de l’objet est l’entité codant l’objet CORBA

à un instant donné et gérant un état de l’objet temporaire.
Au cours du temps, un même objet CORBA peut se voir
associer des implantations différentes.

 Le code d’implantation regroupe les traitements associés

à l’implantation des opérations de l’objet CORBA. Cela
peut être par exemple une classe Java aussi bien qu’un
ensemble de fonctions C.

 L’application serveur est la structure d’accueil des objets

d’implantation et des exécutions des opérations.
Bus CORBA
Middleware

WINDOWS
Les composantes du Bus CORBA
 ORB (Object Request Broker) est le noyau de transport des requêtes
aux objets. Il intègre au minimum les protocoles GIOP et IIOP.
l’interface au bus fournit les primitives de base comme l’initialisation
de l’ORB.
 SII (Static Invocation Interface) est l’interface d’invocations statiques
permettant de soumettre des requêtes contrôlées à la compilation
des programmes. Cette interface est générée à partir de définitions
OMG-IDL.
 DII (Dynamic Invocation Interface) est l’interface d’invocations
dynamiques permettant de construire dynamiquement des requêtes
vers n’importe quel objet CORBA sans générer/utiliser une interface
SII.
 IFR (Interface Repository) est le référentiel des interfaces contenant
une représentation des interfaces OMGIDL accessible par les
applications durant l’exécution.
Les composantes du Bus Corba
 SSI (Skeleton Static Interface) est l’interface de squelettes
statiques qui permet à l’implantation des objets de recevoir les
requêtes leur étant destinées. Cette interface est générée comme
l’interface SII.
 DSI (Dynamic Skeleton Interface) est l’interface de squelettes
dynamiques qui permet d’intercepter dynamiquement toute
requête sans générer une interface SSI.
 OA (Object Adapter) est l’adaptateur d’objets qui s’occupe de
créer les objets CORBA, de maintenir les associations entre
objets CORBA et implantations et de réaliser l’activation
automatique si nécessaire.
 ImplR (Implementation Repository) est le référentiel des
implantations qui contient l’information nécessaire à l’activation.
Ce référentiel est spécifique à chaque produit CORBA.
Le langage IDL (Interface Definition Language)
Il permet de définir dans un langage commun à
l’ensemble des compilateurs, la partie visible d’un
objet : méthodes et propriétés. Le principe utilisé ici
est la séparation de l’interface d’un objet et de son
implémentation et en masquant les divers
problèmes liés à l’interopérabilité, l’hétérogénéité et
la localisation de l’objet.
Permet d’exprimer, sous la forme de contrats IDL la
coopération entre les fournisseurs et les utilisateurs
de services.
Interface Definition Language IDL
Dans une description IDL Il s'agit de décrire au sein
d'une interface ( vue cliente de l'objet ) la liste des
services offerts ( ensemble de fonctions et données )..
IDL est compilé pour générer les stubs, les squelettes
et pour définir les interfaces du référentiel d'interface
Indépendant de tout langage de programmation /
compilateur
 Langage pivot entre applications

Correspondance IDL/langage est fournie pour : C, C+

+, Java, Smalltalk, Ada, Cobol, etc.
Interface Definition Language (IDL)
Les contrats IDL sont projetés en souches (stubs)
IDL dans l’environnement de programmation du
client et en squelettes IDL dans l’environnement de
programmation du fournisseur.

Le client invoque localement les souches pour

accéder aux objets. Les souches IDL construisent
des requêtes, qui vont être transportées par le bus,
puis délivrées par celui-ci aux squelettes IDL qui les
délégueront aux objets.
WINDOWS
exemple
A titre d’exemple, le code suivant présente l’interface
IDL d’un service minimal de gestion du compte d’un
client:
// CompteClient.idl
interface CompteClient {
void credit ( in unsigned long montant );
void debit ( in unsigned long montant );
long solde ( );
};

À l’aide d’un compilateur IDL, on génère une souche (stub) pour le client et un
squelette (skeleton) pour le serveur.

Une description IDL est compilée pour générer les stubs et squelettes
nécessaires au mécanisme d’invocation à distance.
Souche : Coté client
Fonctions de la souche :
Prépare les paramètres d’entrée de l’invocation
Décode les paramètres de sortie et le résultat
Souche statique
Une par type d’objet serveur à invoquer
Identique aux talons clients RPC
Générée à la compilation à partir de l’interface IDL
Souche dynamique
Souche générique construisant dynamiquement tout
type de Requêtes
Permet d’invoquer des objets serveurs que l’on
découvre à l’exécution (i.e. dont on ne connaît pas
l’interface à la compilation : Référentiel d’interfaces)
Squelette : Côté serveur
Fonctions du squelette :
– décode les paramètres d’entrée des invocations
– prépare les paramètres de sortie et le résultat
 Squelette statique
– un par type d’objet serveur invocable
– identique aux talons serveurs RPC
– généré à la compilation à partir de l’interface IDL
Squelette dynamique
squelette générique prenant en compte
dynamiquement tout type de requêtes
permet de créer à l’exécution des classes d’objets
serveurs (i.e. que l’on ne connaissait pas à la
compilation)
Structure d'un fichier IDL

les modules peuvent être emboîtés les uns dans les

autres
les types, constantes, exceptions peuvent être
déclarés à différents niveaux (globalement,
localement à un module, localement à une interface)
Les types de base
Les types de base de CORBA sont :
 Boolean
 octet
 short
 ushort
 long (int en java)
 ulong
 longlong (long en java)
 float
 double
 long double
 char : un caractère sur 1 octet
 wchar : un caractère encodé sur plusieurs octets
 string : une chaine de caractères char
 wstring : une chaine de wchar
Les paramètres d'une opération
La description d'un paramètre comporte trois parties :
le modificateur
le type de l'argument ( type de base ou type complexe )
le nom de l'argument

Le modificateur spécifie le sens d'échange du

paramètre :
in : du client vers l'objet CORBA
out : en retour, de l'objet CORBA vers le client
inout : équivalent à un passage par adresse.
Premier Exemple IDL
interface Premier
{
void affiche ( in string message ) ;
};
Le fichier est nommé « Premier.idl »

L'exemple décrit un objet qui offre une interface

appelée « Premier ». Cette interface comporte une
opération dénommée « affiche » qui entraîne
l'affichage d'un message sur le serveur ( message
passé en tant que paramètre in ).
Compilation d'une Interface IDL
 La génération des stubs et squelettes passe par la
compilation de l’IDL.
 Plusieurs compilateur selon le ORB que vous utilisez (par
exemple « openORB »)
 Le JDK inclut un ORB appelé « JavaIDL »
 Exemple de compilation IDL : (inclus dans le JDK)
idlj –fall –v Premier.idl
 A l'issu de la compilation, plusieurs fichiers sont créés :
PremierPOA.java : il s'agit du squelette,
_PremierStub.java : il s'agit du stub
Premier.java : il s'agit de l'interface
PremierOperations.java : il s'agit des opérations de
l'interface
Concept de « mapping »
Une description IDL est traduite vers un langage de
programmation.

Les règles de traduction sont appelées « mapping »

et font partie de la spécification CORBA.

Grâce au mapping, deux fournisseurs d'ORBs

offriront le même modèle de programmation.

portabilité des applications

Etapes de Mise en œuvre

1. Ecrire une Interface IDL qui décrit les services

offerts des objets CORBA (langage IDL)

2. Développer les objets CORBA

3. Développer le serveur

4. Développer le client
Développer les objets CORBA
Pour développer un objet CORBA plusieurs critères
sont à prendre à compte :
le type de l'adaptateur d'objet utilisé,
l'approche de développement.
Deux adaptateurs d'objets sont disponibles :
le B.O.A. ( Basic Object Adapter )
le P.O.A. ( Portable Object Adapter )
Deux approches existent :
 l'approche par héritage : la classe d’implantation doit
hériter du squelette généré (extends PremierPOA.java)
l'approche par délégation : développer une classe qui
implémente l’interface d’opérations de l’objet
(implements PremierOperations.java)
L’approche par héritage
Développement d’un objet CORBA

•Adaptateur d'objets POA

•Approche par héritage du squelette :
Développer le serveur
Les étapes à respecter sont les suivantes :

initialiser l'ORB
initialiser l'adaptateur d'objets (BOA ou POA)
créer un (ou plusieurs) objet d’implantation CORBA
Connexion et activation de l’objet à l’adaptateur d’objets
enregistrer l'objet
exporter la référence de l'objet dans un fichier
attendre les invocations clientes
Initialiser l'ORB
 Pour cela, on fait appel à la fonction statique « init » de la
classe « org.omg.CORBA.ORB ».

 Deux formes de cette fonction sont disponibles :

org.omg.CORBA.ORB.init( )
org.omg.CORBA.ORB.init( String [] args, java.util.Properties
prop )
public static void main( String [ ] args )
{
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init( args, null );
// …
}
Initialiser l'adaptateur d'objets
Une application serveur contient au minimum un POA
(elle peut en avoir plusieurs) appelé le RootPOA
Le(s) POA(s) sont gérés par le POA Manager
Une application serveur doit

1. Récupérer une référence d’objet RootPOA

POA rootpoa = POAHelper.narrow(orb.resolve_initial_references
(«RootPOA»));
et
2. Activer le POA Manager
rootpoa.the_POAManager().activate();
Créer et enregistrer l'objet CORBA
Pour créer l'objet CORBA, il suffit de créer une instance
de la classe d'implantation de l'objet ( PremierImpl ).
Dans la terminologie POA, cet objet s’appelle un
servant
PremierImpl premier = new PremierImpl();

Enregistrer un servant revient à lui associer une

référence :
org.omg.CORBA.Object ref =
rootpoa.servant_to_reference(premier);
Echanger une référence d'objet
Chaque objet CORBA dispose d'une identité ( la
référence d'objet ).
Pour qu'un client puisse appeler un objet CORBA,
celui-ci doit en connaître la référence de l'objet.
C'est pourquoi l'objet CORBA doit échanger avec le client
sa référence d'objet.
Pour cela, on utilise deux opérations particulières de la
classe « org.omg.CORBA.ORB » :
object_to_string : cette opération transforme une
référence d'objet en une chaîne de caractères.
string_to_object : cette opération transforme une chaîne
de caractères en une référence d'objet.
Le code du serveur Dans notre application le
serveur et le client
import org.omg.CORBA.ORB; échangeront la référence
import org.omg.PortableServer.*; de notre objet au moyen
d’un fichier nommé «
public class Serveur { ObjectID »
public static void main( String [] args ) {
try {
ORB orb = ORB.init( args, null );
POA rootpoa = POAHelper.narrow(
orb.resolve_initial_references("RootPOA"));
rootpoa.the_POAManager().activate();
PremierImpl premier = new PremierImpl();
org.omg.CORBA.Object objref =
rootpoa.servant_to_reference(premier);
String ref = orb.object_to_string( objref );
java.io.FileOutputStream file = new
java.io.FileOutputStream("ObjectID");
java.io.PrintStream output = new java.io.PrintStream( file );
output.println( ref );
output.close();
orb.run();
} catch ( Exception ex ) { ex.printStackTrace(); }
}
Remarque
En étudiant le code précédent on retrouve toutes
les étapes.
Nous observons en particulier que le serveur
passe la référence de l’objet « Premier » sous
forme d’une chaine de caractère (en utilisant
object_to_string) qu’il stocke ensuite dans un
fichier appelé « ObjectID »
Développer le client
Les étapes à suivre sont les suivantes :

Initialiser l'ORB,

Récupérer la référence de l'objet à utiliser,

Convertir la référence vers le type de l'objet à utiliser,

Utiliser l'objet.
Conversion de références d'objets
Les classes helpers
Pour chaque élément décrit en IDL, le compilateur
génère une classe supplémentaire appelée classe
helper.
Cette classe porte le nom de l'élément IDL avec pour
suffixe "Helper".
Les classes helpers associées aux interfaces IDL
comportent une opération de conversion ( narrow ).
public class PremierHelper
{
public static Premier narrow( org.omg.CORBA.Object obj )
{…}
...
}
Le code du client
public class Client
{
public static void main( String [ ] args )
{
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init( args, null );
try {
java.io.FileInputStream file = new java.io.FileInputStream("ObjectID");
java.io.InputStreamReader input = new java.io.InputStreamReader( file);
java.io.BufferedReader reader = new java.io.BufferedReader(input);
String ref = reader.readLine();
file.close();
org.omg.CORBA.Object obj = orb.string_to_object(ref) ;
Premier premier = PremierHelper.narrow( obj );
premier.affiche("Bonjour du client…");
} catch ( java.lang.Exception ex )
{ ex.printStackTrace(); }
}
}
Exécuter l'application
Suivre les étapes suivantes :

lancer le serveur,

copier le fichier contenant la référence d'objet sur le poste

client,

lancer le client.
Synthèse
Le développement d'une application CORBA respecte
toujours les mêmes étapes:

Description des objets à l'aide de l'IDL,

Implantation des divers objets,

Implantation du serveur avec échanges des références,

Implantation du client.
Exemple 2. Hello World en java