Common Object Request Broker Architecture

(CORBA)

GL4 G1

05/01/2007

El Amouri Annowar Hammami WaelBen Salem Aicha Farhat Mohamed

Kharrat Houceme Eddine 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

Le bus CORBA

Annuaire Transaction

Services

Médecine Electronique

Objets de domaines

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 ?

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

Common Object Request Broker Architecture

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.

PC Sparc

NT

PC

UNIX UNIX

Le bus CORBA

Le bus CORBA = ORB

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

PC Sparc

NT

PC

UNIX UNIX

ORBPC/NT

ORBPC/UNIX

ORBSparc/UNIX

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.

le bus CORBA

Vue de l'architecture CORBA

souche D.I.I.

CLIENT SERVEUR

Adaptateur d'objets

Squelette D.S.I.

Objet CORBA

La compilation IDL

Une description IDL est compilée pour générer les souches

nécessaires au mécanisme d’invocation à distance.

descriptionIDL

Génération de l'amorce cliente souche

Génération de l'amorce serveur 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)

soucheIDL

Squelette IDL

Cœur de l’ORBGIOP / IIOP / ESIOP

Adaptateur d’objet

clientclientImplémentation

de l’objetImplémentation

de l’objet

Compilateur IDL

Spécification IDL

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

Types de base

Types constuits

sequence

enum

union

array struct

Boolean CharOctet String IntegerFloatingPoint

Short

UShort

Long

ULong

Float Double

Référence objet

Any

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 annuairetypedef 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 annuairetypedef 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

Plate-formes Multi Multi Win32 Multi Multi

Langagesde Programmation Java C, C++, …

C++, VB, VJ,OPascal, … Multi Multi

Langages deDéfinition de Service Java RPCGEN ODL IDL XML

RéseauTCP, HTTP, IIOP

customisable TCP, UDP IP/IPX GIOP, IIOP,Pluggable Transport Layer

RPC,HTTPSNMP

Transaction Non Non MTS OTS, XA Extension applicativedans le header

ExtraChargementdynamiquedes classes

Services CommunsServices Sectoriels

Firewall TunnelingHTTP

HTTP TunnelingCORBA Firewall HTTP

Qui SUN SUN/OSF MicroSoft OMG W3C

Nommage RMI, JNDI,JINI IP+Port IP+Nom COS NamingCOS Trader IP+Port, URL

Merci pour votre attention