jean louis pazat irisa insa jean louis pazat@irisa fr n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Common Object Request Broker Architecture (CORBA) PowerPoint Presentation
Download Presentation
Common Object Request Broker Architecture (CORBA)

Loading in 2 Seconds...

play fullscreen
1 / 53

Common Object Request Broker Architecture (CORBA) - PowerPoint PPT Presentation


  • 90 Views
  • Uploaded on

Jean-Louis Pazat - IRISA/INSA Jean-Louis.Pazat@irisa.fr. Common Object Request Broker Architecture (CORBA). Plan. Introduction Architecture de CORBA Communications Service de nommage Langage de description d’interfaces (IDL) Exemple Compléments Services, “Facilities” & Domaines

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

Common Object Request Broker Architecture (CORBA)


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide2
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
motivation
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

Appelant

Souche

Appelant

Appelé

Squelette

Appelé

Network

Comment passer du centralisé au réparti ?
  • Casser les structures existantes
    • insérer des appels de procédure/de méthode à distance
  • Nouveaux problèmes
    • nommage, localisation, transparence, interoperabilité
le concept de bus logiciel
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
What isCORBA ?
  • 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
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
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
slide11

Paramètres d’entrée (in)

Ma_méthode(in mon_paramètre out mon_résultat)

valeur de retourParamètres de sortie (out)

Vue duprogrammeur

DSI

squelette IDL

InterfaceORB

SoucheIDL

DII

Adaptateur d’objet

Protocoles GIOP / IIOP / ESIOP

Coeur de l’ORB

Implementationde l’objet

Client

Niveau interstitiel

(middleware)

slide12
ORB

Implementation de l’objet

client

InterfaceORB

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

Cœur de l’ORB

GIOP / IIOP / ESIOP

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

Object

Implementation

client

IDL skeleton

IDL stub

ORB core

GIOP / IIOP / ESIOP

Implémentation de l’objet

client

Squelette IDL

Compilateur IDL

soucheIDL

Adaptateur d’objet

Cœur de l’ORB

GIOP / IIOP / ESIOP

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)

Spécification IDL

souche idl

Object

Implementation

client

IDL stub

ORB core

GIOP / IIOP / ESIOP

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)
squelette idl

Object

Implementation

client

IDL Skeleton

ORB core

GIOP / IIOP / ESIOP

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

Object

Implementation

client

DSI

DII

ORB core

GIOP / IIOP / ESIOP

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
slide19

Object

Implementation

client

DSI

ORB core

GIOP / IIOP / ESIOP

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
slide20

Object

Implementation

client

DII

ORB core

GIOP / IIOP / ESIOP

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”
utilisation de dsi dii si rien n est connu la compilation

DSI

DII

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

User’s view

Object

Implementation

client

Middleware

IDL

stub

ORB

interface

Object Adapter

ORB core

dii idl skeleton method invocation le serveur poss de une idl mais le client ne la conna t pas

IDL

skeleton

DII

ORB core

Interfacerepository

DII+IDL Skeleton method invocationle serveur possède une IDL mais le client ne la connaît pas …

Object

Implementation

client

ORB

interface

Object Adapter

basic object adapter

Object

Implementation

client

Object Adapter

ORB core

GIOP / IIOP / ESIOP

  • Rôle

Object

Implementation

  • 1. activation de l’implémentation
  • 2. enregistrement des implémentations

1

3

4

IDL

skeleton

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

Object Adapter

2

  • + divers “services”
Basic Object Adapter
  • Pas à l’usage du programmeur
    • sauf pour init/enregistrement
appel de m thode distance
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ètres

in : valeur transmise à la méthode

out : valeur calculée par la méthode

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

appel blocant

x = S2->opB(10.2);

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
appel non blocant 1

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
appel non blocant 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()

communication par passage de messages

pull(event)

pull(event)

pull(event)

Event

Server

Cons 1

push(event)

Prod 1

push(event)

push(event)

Pas en attente

Event

Channel

push(event)

Cons 2

Prod 2

pull(event)

Cons 3

En attente

Communication par passage de messages
  • Modèle d’événements (push / pull)
    • communication asynchrone
    • multiple producteurs / multiples consommateurs
service de nommage
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
pr sentation
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++
exemple de sp cification idl
exemple de spécification IDL

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

};

Interface

specification

attribute

specification

method

specification

l ments du langage idl
éléments du langage IDL
  • Modules
  • Interfaces
    • Opérations (oneway, twoway)
    • Attributs
  • Déclarations de
    • constantes
    • types
    • exceptions
modules
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
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
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
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 données

Any

Types constuits

Référence objet

Sequence

Union

Types de base

Array

Enum

Struct

Floating

Point

Integer

Boolean

Octet

Char

String

UShort

ULong

Float

Double

Short

Long

type dynamique idl 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
  • 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
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
exceptions (suite)
  • Exemple

interface Account {

exception OverdrawnException {};

void deposit( in float amount );

void withdraw( in float amount )

raises ( OverdrawnException );

float balance();

};

idl mappings
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 corba1
Mon premier programme CORBA

interface tty {

void print(in string msg);

};

spécification IDL

class tty_impl : virtual public tty_skel {

public:

tty_impl() {};

~tty_impl() {};

void print(const char* msg) {

cout << msg << endl;

};

};

implementation de l’objet

mon premier programme corba2

Serveur

1. Init ORB + BOA

2. Créer l’objet

Service de nommage

3. Recup. ref. service de nommage

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

5. Activer l’objet puis attendre des invocations

4

ORB

3

4

Client

1

2

1

3

1. Init ORB

2

2. Recup. ref. service de nommage

Client

5

Serveur

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

4. Invoquer une méthode

Mon premier programme CORBA

Geek off

slide48

Implémentation du serveur

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

slide49

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();}

slide50

Implémentation du client

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

// initialisation de l’ORBCORBA::ORB_var orb = CORBA::ORB_init(argc, argv, "mico-local-orb");

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

slide51

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 nommageCORBA::Object_var obj = nc->resolve( name );tty_var proxy = tty::_narrow( obj );

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

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