ORB (1/2)

ORB : Object Request Broker

Middleware qui gère les relations client/serveur entre les objets

Définition du concept de Middleware : Courtier d’objets (en Français).

Ensemble des logiciels nécessaires pour permettre et organiser la communication et l’échange de messages entre client et serveur.

ORB (2/2)Composant central du standard CORBA qui gère :

la localisation d’objet la désignation des objets l’empaquetage des paramètres (marshalling) le dépaquetage des paramètres (unmarshalling) l’invocation des méthodes la gestion des exceptions l ’activation automatique et transparente des objets

De plus, il fournit des caractéristiques telles que : la liaison avec « tous » les langages de programmation un système auto-descriptif l ’interopérabilité entre les bus

“Proxies Make Remote Objects Look Local”

• Un proxy est un objet local qui représente un objet distant– Le proxy est automatiquement créé par l’ORB

• Le proxy a l’interface de l’objet distant– Si l’objet distant est en C++, et le client est en Java, le proxy sera en

Java

CORBA Software Bus

Client Process Server Process

proxy

implementation

Transparence de localisation des objets

Si un objet invoque une opération sur un autre objet CORBA dans le même processus, certaines implémentations peuvent éviter le passage par le réseau.

Process A Process B

Machine 1 Machine 2

Direct Call

Inter-Process Call

Network Call (IIOP)

Bus Corba : fonctions ...

ORB

Clientserveur

Référence -> faire(param1,param2,...)

réseau

010010010110110101111

Marshaling Unmarshaling

faire(param1,param2,...)

Return

Marshaling

10010110110

Return

Unmarshaling

Bus Corba

C++

Souche

Java

Souche

Smalltalk

Souche

Ada

Souche

ORB : Liaison avec « tous » les langages de programmation

Noyau de communication

Interface d’Invocation Statique

Interface d’Invocation Dynamique

Interface du bus

SII DII ORB

SSI DSI

OA

Interface de Squelettes Statiques

Interface de Squelettes Dynamiques

Adaptateur d’objet

IR Référentieldes interfaces ImplR Référentiel

des implantations

CORBA : composantes du bus

pré-compilateur

fichierIDL

Client Implémentation d’objet

DII Stubclient

InterfaceORB

Référentieldes interfaces

Rint

Référentieldes implémentations

Rimp

noyau de l ’Object Request Broker (ORB)

SSI DSI

SII

Adaptateur d’Objet

Architecture générale

Interface de l ’adaptateur

• Projection des descriptions OMG-IDL vers les langages d’implantation des clients et serveurs.– mode « statique »

• Instanciation sous forme d’objets CORBA des descriptions OMG-IDL dans un référentiel des interfaces commun.– mode « dynamique »

OMG-IDL : compilation

• Les clients et serveurs implantent des descriptions OMG-IDL communes, statiquement précisées dans la phase de compilation/projection du source IDL.

CORBA : le mode statique

Contrat IDL

Bus CORBA SqueletteIDL

StubIDL

Fournisseurd ’objets

Clientd ’objets

• Les souches générées encapsulent l’utilisation du bus, l’activation et la distribution des composants et l’hétérogénéité de l’architecture.

Invocation statique

Client Implémentation d’objet

Stubclient

Adaptateur d’Objet

ORB noyau

squelette statique

requête réponse

squelette dynamique

• Un « référentiel des interfaces » stocke sous forme d’objets les descriptions d’interfaces OMG-IDL.

• Une API (DII: Dynamic Invocation Interface) permet de construire des requêtes à l’exécution.

• Une API (DSI : Dynamic Skeleton Interface) permet de comprendre des requêtes à l’exécution.

CORBA : le mode dynamique

Permet la création dynamique de requêtes API (DII) sans passer par des souches pré-générées;

Un objet Request = un nom d’opération, une liste de couples valeur - type (au sens de l’IR) et une structure pour le résultat

invokesend_deferred + get_response, poll_responsesend_oneway

wait

invoke

get_response

send-deferredsend_oneWay

Interface d'invocation dynamique (1)

Interface d'invocation dynamique (2)

Utilisation du référentiel des interfaces pour récupérer les informations relatives aux interfaces IDL;

Avantages :- les interfaces peuvent être découvertes dynamiquement;

- code client générique indépendant d'une interface IDL;.

Etapes1. trouver la référence d ’un objet

2. recherche et interprétation de son interface dans le référentiel des interfaces;

3. obtenir la description de l ’opération à invoquer

4. construction d'un objet requête;construire la liste des arguments à transmettre

5. invocation de la requête

6. traiter les résultats retournés.

(string_to_object)

get_interface -> CORBA::InterfaceDef

lookup_name, describe, …..

create_request, …..

invocation dynamique (3)

Interface de squelette dynamique

• Permet de délivrer une requête à un objet implémentation qui est inconnu lors de la phase de compilation

• Interprète une requête et ses paramètres.

• Analogue au DII mais du côté serveur.

• Utiliser pour créer des ponts entre des ORBs de vendeurs différents.

•Utiliser pour intégrer des applications existantes (legacy application). Les applications peuvent ne pas être conformes aux standard CORBA et peuvent également ne pas être OO.

Object Adapter : fonctions

Fonctions des Adaptateurs d’objets:

1- Enregistrement des objets implémentation.

2- Génération et interprétation des références d'objets.

3- Activation et désactivation des objets implémentation.

4- Invocation des méthodes à travers les squelettes ou le DSI.

5- Participation à la sécurité

Intermédiaire entre le bus et les implantations possibles des objets

Proxy

Servant

POA

POA« Pont entre les requêtes arrivants et les objets d’implémentation leur correspondant »

Un POA gère les relations entre les références d’objets, les identificateurs et les servants

Un serveur peut contenir plusieurs POAs

Un POA gère plusieurs servants, tous avec une même politique déterminée par ses « policies » (immuables).

Le RootPOA a un ensemble fixé de Policies, il est toujours présent.

Un servant est associé à un unique POA.

Active Object Map: table des objet actifs via leur ID

Adapter activator: objet qui peut créer un POA sur demande

Object ID: identification de l'objet au sein de l'adaptateur (unique au sein d'un même adaptateur)

POA manager: objet qui contrôle l'état du POA

Policy: objet qui contrôle le comportement d'un POA et de ses objets

rootPOA: chaque ORB (serveur) est créé avec un POA racine qui permet de créer des POA fils.Servant: code qui implante les méthodes d'un objet. Servant Manager: objet gérant l'association servant-objet

Architecture du POA et terminologie