Common Object Request Broker Architecture (CORBA)

Common Object Request Broker
Architecture
(CORBA)
El Amouri Annowar
Ben Salem Aicha
Kharrat Houceme Eddine
GL4 G1
05/01/2007
Hammami Wael
Farhat Mohamed
Zine Alabidine Nabih
Plan
1. Introduction
2. Norme CORBA
3. Architecture CORBA




Services
Utilitaires
Interfaces de domaines
Communication
4. Langage de Définition d’Interface: IDL
5. Conclusion
Introduction
Application réparties
Application répartie = traitements coopérants
sur des tâches et des données réparties

Coopération= communication + synchronisation
Problèmes généraux





Tolérance aux pannes (reliability)
Nommage  nommer et localiser les ressources
Sécurité  authentification
Disponibilité (availability)  deux appels sur un même serveur ?
Outils pour le développement  génie logiciel
Modèle Client/Serveur
Client/Serveur « à procédure »

RPC
Client/Serveur « à objet »

RMI, Corba, DCOM
Client/Serveur « de données »

Requêtes SQL
Client/Serveur « WEB »

CGI, servlet, asp, jsp, php...
Client/Serveur à objets
 Paradigmes objets : encapsulation polymorphisme, composition,
généricité
 Objet = unité de désignation et de distribution
 Ex. RMI, CORBA
Norme CORBA
Qu'est ce que l'OMG ?
 O.M.G. ( Object Management Group ) est un consortium qui regroupe
plus 800 entreprises du monde entier.

Consortium ouvert aux horizons autres que les concepteurs de logiciels (
industriels, chercheurs, université, etc... ).
 Ce consortium définit des spécifications pour fournir un modèle de
coopération entre objets répartis.

CORBA 1.0 : 1991 (modèle objet)

CORBA 2.0 : 1995 (interopérabilité, IIOP)

CORBA 3.0 : 2002 (modèle composant)
Les spécifications de l'OMG
 L'OMG spécifie tous les constituants d'un modèle objet global
appelé O.M.A. ( Object Model Architecture )

CORBA est une partie de ce modèle,

Utilitaires communs ( services ),

Eléments spécifiques à des corps de métier ( objets de domaines ).
Vue du modèle OMA
Objets de domaines
Services
Annuaire
Transaction
Electronique
Médecine
Le bus CORBA
Client
Serveur
Applications utilisateurs
Administration
Impression
Utilitaires communs
Objectifs de CORBA
 Fournir un environnement ouvert

les membres participent aux spécifications
 Fournir un environnement portable

les API sont définis pour rendre les applications portables ( quelque soit
le produit CORBA utilisé )
 Fournir un environnement interopérable

Permettre aux applications CORBA de collaborer entre elles.
Qu'est ce que CORBA ?
 Common Object Request Broker Architecture





standard ouvert pour les applications réparties
bus logiciel, orienté objet
communication par appel de méthode à distance
géré par l’ “Object Management Group” (OMG).
indépendant
 du matériel, du système, des langages
 Mais aussi des vendeurs
 interopérabilité
Un environnement complet...
 CORBA est une architecture qui définit un
environnement pour permettre la collaboration entre
applications réparties.
 CORBA est disponible sur de nombreuses plate-formes,
dans de nombreux langages et chez de nombreux
fournisseurs.
 CORBA est simple à programmer en comparaison des
environnements équivalent.
 CORBA offre une homogénéisation du système
d'informations.
Le bus CORBA
Le bus CORBA = ORB
NT
UNIX
UNIX
PC
PC
Sparc
Le concept de “bus logiciel”
ajouter/supprimer des objets sans recompiler
l’ensemble de l’application


enregistrer/retrouver des références globales sur
des objets
connaître à priori ou découvrir les méthodes d’un
objet
réaliser les appels de méthode à distance


passage de paramètres (par valeur)
indépendance vis à vis de la localisation des objets
La vue réelle du bus CORBA
ORB
PC/NT
ORB
PC/UNIX
ORB
Sparc/UNIX
NT
UNIX
UNIX
PC
PC
Sparc
Réseau TCP/IP
Le modèle objet de CORBA
 Un serveur CORBA peut héberger plusieurs objets
CORBA.
 Chaque objet est accessible indépendamment des
autres objets du serveur.
 Chaque objet exprime son offre de services sous forme
d’une interface IDL

Pour cela, on utiliser un langage de description de services
appelé IDL CORBA.

Il s'agit de décrire au sein d'une interface (vue cliente de l'objet)
la liste des services offerts ( ensemble de méthodes).
Architecture CORBA
Modèle CORBA
Les services CORBA
 Pour accélérer et faciliter le développement
d'applications avec CORBA, l'O.M.G a spécifiée un
ensemble de services.
 A l'heure actuelle, plus de 17 services ont été définis.
 Les services sont vendus séparément du bus CORBA.
 Seul quelques services sont actuellement disponibles
sur le marché.
Service de nommage
 Rôle : retrouver les références d’objet à partir de noms
symboliques
 Définition du service : dans une interface IDL

Module CosNaming
 Structure : arborescence appelé graphe de désignation
(Naming Graph)



Une racine
Des répertoires, appelés « contexte de nommage »
Des feuilles : les références d’objet
 Un contexte est un objet qui gère une liste de liaisons (=
associations nom-référence)
Les utilitaires CORBA
Les utilitaires communs (CORBAfacilities) sont
des canevas d’objets (« Frameworks ») qui
répondent plus particulièrement aux besoins
des utilisateurs. Ils standardisent l’interface
utilisateur, la gestion de l’information,
l’administration, le Workflow, etc.
Ils définissent un cadre de haut niveau pour la
création de logiciels à l’aide de composants
réutilisables. Ils sont à ce jour bien moins
avancés que les services.
Les interfaces de domaines
Les interfaces de domaines concernent des
marchés verticaux et définissent donc des
interfaces spécialisées répondant aux besoins
spécifiques de tel ou tel marché comme les
télécommunications ou la finance par exemple.
Objectif : interopérabilité sémantique entre les
systèmes d'informations des entreprises, Objets
métiers spécifiques à des secteurs d'activités :
Finance, santé, télécoms.
Vue de l'architecture CORBA
Objet CORBA
CLIENT
SERVEUR
Squelette
souche
D.I.I.
D.S.I.
Adaptateur d'objets
le bus CORBA
La compilation IDL
 Une description IDL est compilée pour générer les souches
nécessaires au mécanisme d’invocation à distance.
souche
description
IDL
squelette
Souche et squelette IDL
Générés par le compilateur IDL

à partir de la description IDL de l’objet serveur
(doit être connue lors de l’écriture du client)
client
Spécification
IDL
Implémentation
de l’objet
Squelette
Compilateur
souche
IDL
GIOP / IIOP / ESIOP
IDL
IDL
Adaptateur d’objet
Cœur de l’ORB
Normalisation des communications
 Protocoles d’interopérabilité entre ORBs conformes à
CORBA 2


GIOP : General Inter-ORB Protocol
 Messages : request, reply, cancelrequest, …
 nécessite un protocole de transport fiable, orienté connexion
IIOP (Internet IOP) : instanciation de GIOP sur TCP
 Autres implantations de GIOP au-dessus de HTTP, RPC
DCE, RPC Sun
 Composants du protocole


CDR : Common Data Representation
 Format de données d’encodage des données
IOR : Interoperable Object References (références d’objets)
Les communications avec CORBA
 Les participants à un échange CORBA communiquent à l'aide d'un
protocole spécifique à CORBA : IIOP (Internet Inter-ORB Protocol).
 Le protocole IIOP est indépendant du langage de programmation,
du système d'exploitation et de la machine utilisée.

Un client Java pourra utiliser un serveur C++
 Transparence de l’appel / indépendance de la localisation de l’objet

Même espace mémoire  simple appel de fonction

Même machine  communication inter-processus

Machine distance  communication réseau
GIOP/IIOP
GIOP = General Inter ORB Protocol


spécification qui permet l’interopérabilité entre
différents ORBs
spécifie le protocole de transmission + format des
requêtes
IIOP = Internet Inter ORB Protocol


protocole d’interopérabilité standard pour Internet
construit sur IP
ESIOP = Environment Specific IOP

spécification qui permet de définir des protocoles
spécifiques
IIOP
 Livré avec toute implémentation de CORBA
 Utilise CDR (plus efficace que XDR)
 Certains serveurs WEB peuvent dialoguer via IIOP
Interface Definition Language
(IDL)
Le concept
Langage de description d’interface (IDL)
Est indépendant des langages
Peut être “mappé” dans de nombreux langages :

Cobol, ADA, C++, C, Java, Python, SmallTalk...
Permet de décrire

des interfaces contenant
 des opérations
 des attributs accessibles à distance
une interface IDL est similaire à
 une
interface Java
 une classe abstraite C++
Décrire les services offerts
 Le développement d'une application CORBA commence par
l'énumération des services offerts par chaque objet corba.
 Une même description IDL peut contenir plusieurs descriptions
d'objets.
 Une description IDL s'effectue au sein d'un fichier texte comportant
par convention l'extension « .idl »
 Chaque objet offre une interface qui contient une liste
d'opérations qui seront par la suite offertes aux applications
clientes.
Eléments du langage IDL
Modules
Interfaces


Opérations (oneway, twoway)
Attributs
Déclarations de



constantes
types
exceptions
Le module IDL
 La notion de module est similaire à celle de package de Java.
 Un module introduit un espace de désignation supplémentaire. On
notera qu'un module peut contenir un autre module, une interface,
une description de type complexe.
 La description d'un module respecte la syntaxe suivante :
module nom_du_module
{
// corps du module
};
Un module est traduit en un package (sous-répertoire).
Premières règles sur l'IDL
 Une interface est une énumération d'opérations et de définitions de
types de données.
interface Exemple
{
// contenu de l'interface
};
 Une interface supporte l'héritage multiple.
interface AutreExemple : Exemple1, Exemple2
{
// contenu de l'interface
};
Décrire une méthode
 Les opérations décrites dans une interface respectent le
format suivant :
type_de_retour ma_methode ( liste_des_paramètres ) ;
CORBA offre plusieurs types de données :
- les types de bases
- les types complexes
La liste des paramètres peut
être vide.
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 le client

inout : équivalent à un passage par adresse.
Un exemple de description IDL
 Cet 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 ).
interface Hello
{
void sayHello ( in string message ) ;
};
Types de données
Any
Types constuits
Référence objet
sequence
union
Types de base
array
Floating
Point
Boolean Octet Char
Integer
String
UShort
ULong
Float Double
Short Long
enum
struct
Déclarations de types
Renommage ou types def. par le programmeur
énumeration, structures, tableaux, unions
enum couleurs { rouge, vert, bleu};
struct ecole {
Interessant tutoriels, exposes;
Bon repas;
Sympatique station;
};
typedef Char BadDate[2];
sequences (tableaux de taille variable)
typedef sequence<ecole> formation;
Les attributs IDL
 Il est possible dans une description IDL de définir des attributs
d'interface.
 Un attribut est une donnée accessible soit en lecture/écriture, soit
en lecture seulement.
 Pour décrire un attribut, on respecte le format suivant :
[ readonly ] attribute type_de_l'attribute nom_de_l'attribut;
Optionnel, ce mot clef signale que l'attribut
est accessible en lecture seule.
Exceptions
Assure qu’un client reçoit toujours une réponse
lors d’une invocation distante
2 sortes d’exceptions


“CORBA Standard Exceptions”
 levées par CORBA
 même si elle peuvent avoir été levées par
l’implémentation d’un objet
exceptions définies par le programmeur
exception EntryNotAllowed{string
reason;};
Exceptions
 Exemple
interface Account {
exception OverdrawnException {};
void deposit( in float amount );
void withdraw( in float amount )
raises ( OverdrawnException );
float balance();
};
Notion de séquence IDL
 Une séquence est une donnée similaire à un tableau.
 Une séquence se décrit en IDL par le mot clef « sequence ». La
description d'une séquence est couplée à celle d'un alias.
 On distingue deux types de séquences :


les séquences bornées : sequence< type, borne >
les séquences non bornées : sequence< type >
 Exemples :
typedef sequence<String> liste;
typedef sequence<String, 100> liste_bornee;
Notion de structure IDL
 Une structure IDL est une description qui permet de regrouper
plusieurs données appelées membres.
 Les structures IDL doivent contenir au minimum un membre.
 Chaque structure respecte le format suivant :
struct nom_de_la_structure
{
liste_des_membres;
};
chaque membre est décrit par :
type nom;
Echange de référence d'objets
 Parmi les types de bases de l'IDL il existe celui de référence d'objet
symbolisé par « Object ».
 Ainsi, à l'aide de ce paramètre un client pourra échanger des
références avec un objet CORBA.
 On peut également échanger des références d'objets typées en
utilisant comme paramètre le nom d'une interface IDL.
Exemples
interface Exemple
{
// …
};
interface AutreExemple
{
void f ( in Object obj );
void g ( in Exemple obj );
};
On pourra grâce à « f » échanger des
références d'objets dont celle de « Exemple ».
Avec « g » on ne pourra échanger que des
références d'objets vers « Exemple » où
des références d'objets héritants
de « Exemple ».
Exemple
# pragma prefix «ensai.fr»
module annuaire
typedef string Nom;
struct Personne {
Nom nom ;
String tel ;
}
interface Repertoire {
readonly attribute string libelle ;
exception Inconnu (Nom nom ) ;
Personne obtenirPersonne (in Nom nom) raises (Inconnu) ;
}
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
Compilation d'une description IDL
 La description doit être compilée afin de générer les amorces
( souche et squelette ) requises pour l'établissement de la
communication inter-processus.
 Exemple de compilation IDL (projection en Java):
idlj –fall –v Hello.idl
 A l'issu de la compilation, plusieurs fichier sont créés :

HelloPOA.java : il s'agit du squelette,

_HelloStub.java : il s'agit de la souche,

Hello.java : il s'agit de l'interface

HelloOperations.java : il s'agit des opérations de l'interface
Conclusion
Exemple
# pragma prefix «ensai.fr»
module annuaire
typedef string Nom;

struct Personne {
Nom nom ;
String tel ;
}




interface Repertoire {
readonly attribute string libelle ;
exception Inconnu (Nom nom ) ;
Personne obtenirPersonne (in Nom nom) raises (Inconnu) ;
}





Anatomie de CORBA
Comparaison
RMI
RPC
DCOM
CORBA
SOAP
Qui
SUN
SUN/OSF
MicroSoft
OMG
W3C
Plate-formes
Multi
Multi
Win32
Multi
Multi
Langages
de Programmation
Java
C, C++, …
C++, VB, VJ,
OPascal, …
Multi
Multi
Langages de
Définition de Service
Java
RPCGEN
ODL
IDL
Réseau
TCP, HTTP, IIOP
customisable
TCP, UDP
IP/IPX
Firewall
Tunneling
HTTP
HTTP Tunneling
CORBA Firewall
XML
RPC,HTTP
SNMP
HTTP
Nommage
RMI, JNDI,JINI
IP+Port
IP+Nom
COS Naming
COS Trader
IP+Port, URL
Transaction
Non
Non
MTS
OTS, XA
Extension applicative
dans le header
Extra
Chargement
dynamique
des classes
GIOP, IIOP,
Pluggable Transport Layer
Services Communs
Services Sectoriels
Merci pour votre attention