Common Object Request Broker Architecture (CORBA)

Common Object Request Broker Architecture

(CORBA)

Jean-Louis Pazat - IRISA/INSA

[email protected]

Plan

Introduction Architecture de CORBA Communications Service de nommage Langage de description d’interfaces (IDL) Exemple Compléments

Services, “Facilities” & Domaines CORBA et le parallélisme

Conclusion

Introduction

motivation

Calcul réparti le réseau est au cœur du calcul

Pratiques du “génie logiciel” modélisation et programmation objet/composant

Indépendance vitale pour les applications

vis à vis des plateformes vis à vis des vendeurs

Integration de programmes existants nécessaire

Comment passer du centralisé au réparti ?

Casser les structures existantes insérer des appels de procédure/de méthode

à distance

Appelant

Appelé

AppelantAppelé

Souche Squelette

Network

Nouveaux problèmes nommage, localisation, transparence, interoperabilité

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 vais à vis de la localisation des

objets

What is 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 et surtout des vendeurs

CORBA = Common Object Request Broker Architecture

interopérabilité

Le modèle objet de CORBA

Types (Types) : définis sur des domaines de valeurs indépendants des langages d’implémentation

Objets (objects) : entité encapsulée qui offre des services à des

clients peut être créé/détruit

méthodes (operation) entité qui définit les points d’entrée qu’un client

peut invoquer

Le modèle objet de CORBA (suite)

Interfaces (Interfaces) signature des méthodes qu’un client peut invoquer

sur un objet

Requêtes (requests) : action créée par un client et dirigée vers un objet contient des infos sur la méthode à invoquer et les

paramètres réels

Architecture de CORBA

Ma_méthode(in mon_paramètre out mon_résultat)Paramètres d’entrée (in)

valeur de retourParamètres de sortie (out)

Implementationde l’objet

Implementationde l’objet

ClientClientVue du

programmeur

DII SoucheIDL

squelette IDL

DSI

Adaptateur d’objetInterface

ORB

Coeur de l’ORB

Niveau interstitiel(middleware)

Protocoles GIOP / IIOP / ESIOP

ORB

Niveau interstitiel (Middleware) n’est pas partie intégrante du système sépare le reste de l’architecture du système

Permet l’ interopérabilité indépendant des plateformes matérielles ou

logicielles différents ORB peuvent communiquer

à travers un protocole “Inter ORB” (xIOP)

InterfaceORB

Implementation de l’objet

Implementation de l’objet

clientclient

Cœur de l’ORB

GIOP / IIOP / ESIOP

ORB (suite)GIOP / IIOP / ESIOP

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

ORB (suite)IIOP

Livré avec toute implémentation de CORBA Utilise CDR

plus efficace que XDR (0/1 codage/décodage max)

Certains serveurs WEB peuvent dialoguer via IIOP

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)

IDL stub

IDL skeleton

ObjectImplementation


clientclient

ORB coreGIOP / IIOP / ESIOP

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

Souche IDL

Contient les proxies des objets distants auxquels le client accède

génère les requêtes à partir de l’invocation de méthode locale

encapsule requête et arguments envoie la requête sur le bus (ORB Core)

IDL stub



clientclient


Squelette IDL

Contient un aiguilleur de requêtes compilé (dispatcher)

extrait l’invocation de méthode et les paramètres de la requête reçue du bus

transmet l’invocation de méthode vers le bon objet

IDL Skeleton



clientclient


DII / DSI

Interfaces dynamique d’invocation de méthodes (Dynamic Invocation/Skeleton Interface) permet de découvrir dynamiquement de nouvelles

interfaces ou de les enregistrer pas recommandé aux programmeurs débutants historiquement était la seule interface disponible en

CORBA beaucoup moins efficace que les interfaces statiques

DII

DSI



clientclient


DSI

Dynamic Skeleton Interface utile lorsqu’une implémentation n’a pas d’IDL peut tenir compte d’objets créés/enregistrés

dynamiquement transfère les invocations de méthodes du coté

serveur

DSI



clientclient


DII

Dynamic invocation interface API prédéfinie pour tout appel de méthode permet de découvrir dynamiquement des interfaces les requêtes doivent être construites “à la main” syntaxiquement différent d’une invocation de

méthode utilisée aussi dans des cas particuliers

“deferred synchronous call”

DII



clientclient


Utilisation de DSI+DIIsi rien n’est connu à la compilation

IDLstub

DSI

Object AdapterORB

interface



clientclientUser’s view

Middleware

DII

ORB core

DII+IDL Skeleton method invocationle serveur possède une IDL mais le client ne la

connaît pas …

IDLskeleton

Object AdapterORB

interface



clientclient

DII

ORB core Interfacerepository

Basic Object Adapter

Pas à l’usage du programmeur sauf pour init/enregistrement

Object Adapter



clientclient


2

2. enregistrement des implémentations 3

3. activation des objets

+ divers “services”

1

1. activation de l’implémentation Object

ImplementationObject

Implementation

4

4. invocation des méthodes (“upcalls” sur l’implémentation via le squelette

IDLskeleton

Object Adapter

Rôle

Communication

Appel de méthode à distance

paramètres passés par valeur types de base, types construits références aux objets

modes de passage de paramètresin : valeur transmise à la méthode

out : valeur calculée par la méthode

inout : valeur transmise puis renvoyée (modifiée)

Appel blocant

“twoway method invocation” l’appelant est bloqué jusqu’à la terminaison de la

méthode appelée out, inout et des resultats ou des exceptions

peuvent être retournées

x = S2->opB(10.2);

Appel non blocant 1

“oneway method” l’appelant n’est pas bloqué aucun résultat ou paramètre inout ou out ne peuvent être utilisés

S2->opB(10.2);

Appel non blocant 2

“asynchronous call” uniquement en utilisant le DII permet de récupérer des résultats

méthodes du DII :

send_deferred()

get_response()

poll_response()

Prod 1

Prod 2

Cons 1

Cons 2

Cons 3

Pas en attente

En attente

EventServer

EventChanne

l

Communication par passage de messages

Modèle d’événements (push / pull) communication asynchrone multiple producteurs / multiples consommateurs

push(event)

pull(event)

push(event)

push(event)

push(event)

pull(event)

pull(event)

pull(event)

Service de nommage

Un des serveurs standard livrés avec l’ORB (service)

Service de nommage générique Associe des noms et des références CORBA (IOR) nommage uniforme

Contexte de nommage organisé en DAG conventions de nommage

Opérations bind / unbind / rebind / resolve

Interface Definition Language (IDL)

présentation

Est indépendant des langages Peut être “mappé” dans de nombreux langages :

C++, C++, C++, C++, C, Java, ...

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

const long N = 10;

typedef double Vector[N]; interface example {

typedef double Matrix[N][N];

attribute short status;

boolean operation( in Vector A, out Matrix B ); };

const long N = 10;

typedef double Vector[N]; interface example {

typedef double Matrix[N][N];

attribute short status;

boolean operation( in Vector A, out Matrix B ); };

exemple de spécification IDL

Interfacespecification

attributespecification

methodspecification

éléments du langage IDL

Modules Interfaces

Opérations (oneway, twoway) Attributs

Déclarations de constantes types exceptions

Modules

espaces de nommage pour les définitions IDL évite les conflits de noms

les modules peuvent être imbriqués les noms sont visibles (préfixer)

module simulation {typedef ::MatrixComputation::Matrix constraints;… };

module MatrixComputation {typedef double Matrix[N][N]; …};

Interfaces

Description de la partie publique d’un objet Héritage entre interfaces possible (restrictions)

redéfinitions interdites héritage multiple autoriséinterface coffee {// coffee interface definitions};interface Drinks: coffee {// inherits all coffee definitions// then adds other definitions};

Constantes

Seulement pour certains types integer, character, Boolean, Floating point, String,

renamed types peuvent être des expressions pas de constantes pour les types construits

const char etoileu_des_neigeu = ‘*’

typedef Long Entier;

Entier 600+60+6

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;

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

type dynamique IDL Any

N’est pas un type générique au sens objet Défini des types “auto-identifiés”

contient des informations sur son type dynamique (CORBA type code) sa valeur

les types définis par l’utilisateur ont un “type code”

utile pour définir des services “génériques”

attributs

attributs public des objets peuvent être en “lecture seule” ou en

“lecture/écriture” (par défaut) seuls les types nommés sont autorisés

interface time {

attribute unsigned long nanosecond;

readonly attribute date Y2K;

attribute long notAllowed[10];

…

}

Interdit !

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 (suite)

Exemple

interface Account {

exception OverdrawnException {};

void deposit( in float amount );

void withdraw( in float amount )

raises ( OverdrawnException );

float balance();

};

IDL mappings

Existent pour plusieurs langages orientés objet non orienté objet

Un nouveau “mapping” ne peut pas être facilement ajouté nécessite la modif du compilateur IDL, du BOA, … son intégration dans la norme connecter 2 ORBs est plus simple ...

mapping trivial pour C++, assez simple pour Java

Mon premier programme CORBA


interface tty { void print(in string msg);};

interface tty { void print(in string msg);};

class tty_impl : virtual public tty_skel {public: tty_impl() {}; ~tty_impl() {}; void print(const char* msg) { cout << msg << endl; };};

class tty_impl : virtual public tty_skel {public: tty_impl() {}; ~tty_impl() {}; void print(const char* msg) { cout << msg << endl; };};

spécification IDL

implementation de l’objet

ORB

Serveur

Serveur


ClientClient

Client1

1. Init ORB2

2. Recup. ref. service de nommage

3

3. construire le nom de l’objet et recup. ref. objet à partir du nom

1

1. Init ORB + BOA

2

2. Créer l’objet

3

3. Recup. ref. service de nommageService de nommage

Service de nommage

4

4. construire le nom de l’objet et l’enregistrer (ref + nom)

4. Invoquer une méthode

4

5

5. Activer l’objet puis attendre des invocations

Geek off

int main( int argc, char* argv[] ) {

// initialisation de l’ORB et du BOACORBA::ORB_var orb = CORBA::ORB_init(argc, argv, "mico-local-orb");CORBA::BOA_var boa = orb->BOA_init( argc, argv, "mico-local-boa" );

// Créer l’objettty_impl *afficheur = new tty_impl;

// Récupérer la référence du service de nommageCORBA::Object_var nsobj = orb->resolve_initial_references("NameService");CosNaming::NamingContext_var nc = CosNaming::NamingContext::_narrow( nsobj );

Implémentation du serveur

// Construire le nom de l’objetCosNaming::Name name;name.length( 1 );name[0].id = CORBA::string_dup( "mytty" );name[0].kind = CORBA::string_dup( "" );

//l’enregistrer sur le service de nommagenc->bind( name, afficheur );

//activer l’objet attendre les invocationsboa->impl_is_ready(CORBA::ImplementationDef::_nil() );orb->run();}

Implémentation du serveur

int main( int argc, char* argv[] ) {

// initialisation de l’ORB

CORBA::ORB_var orb = CORBA::ORB_init(argc, argv, "mico-local-orb");

// Récupérer la référence du service de nommage

CORBA::Object_var nsobj = orb->resolve_initial_references("NameService");

CosNaming::NamingContext_var nc = CosNaming::NamingContext::_narrow( nsobj );

Implémentation du client

//Construire le nom de l’objetCosNaming::Name name;name.length (1);name[0].id = CORBA::string_dup( "mytty" );name[0].kind = CORBA::string_dup( "" );

//Retrouver la référence grâce au //service de nommage

CORBA::Object_var obj = nc->resolve( name );tty_var proxy = tty::_narrow( obj );

// Invocation de la méthodeproxy ->print( ”là haut sur la montagne ..." );}

Implémentation du client

Conclusion

Nombreuses mise en œuvre existantes Orbix (Iona), Visibroker (Inprise), ... comm MICO (Université de Francfort) ORBit, TAO, JacORB, ...

Intérêts Utilisation assez facile Réelle interopérabilité !

Défauts Trop bas/haut niveau :-) Architecture complexe Performances limitées sur les réseaux haut débit

Et ...

Common Object Request Broker Architecture (CORBA)

Documents

Transcript of Common Object Request Broker Architecture (CORBA)