Common Object Request Broker

mustardunfInternet και Εφαρμογές Web

21 Οκτ 2013 (πριν από 3 χρόνια και 9 μήνες)

168 εμφανίσεις

Common Object Request Broker
Architecture

(CORBA)

GL
4
G
1

05
/
01
/
2007

El Amouri Annowar Hammami Wael

Ben 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

ORB

PC/NT

ORB

PC/UNIX

ORB

Sparc/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.

description

IDL

souche

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)

souche

IDL

Squelette

IDL

Cœur de l’ORB

GIOP / IIOP / ESIOP

Adaptateur d’objet

client

Implé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 : Exemple
1
, Exemple
2

{


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

Char

Octet

String

Integer

Floating

Point

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

Plate
-
formes

Multi

Multi

Win
32

Multi

Multi

Langages

de Programmation

Java

C, C++, …

C++, VB, VJ,

OPascal, …

Multi

Multi

Langages de

Définition de Service

Java

RPCGEN

ODL

IDL

XML

Réseau

TCP, HTTP, IIOP

customisable

TCP, UDP

IP/IPX

GIOP, IIOP,

Pluggable Transport Layer

RPC,HTTP

SNMP

Transaction

Non

Non

MTS

OTS, XA

Extension applicative

dans le header

Extra

Chargement

dynamique

des classes

Services Communs

Services Sectoriels

Firewall

Tunneling

HTTP

HTTP Tunneling

CORBA Firewall

HTTP

Qui

SUN

SUN/OSF

MicroSoft

OMG

W
3
C

Nommage

RMI, JNDI,JINI

IP+Port

IP+Nom

COS Naming

COS Trader

IP+Port, URL

Merci pour votre attention