Transcript Diapositive 1

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
Server Process
Client Process
implementation
proxy
CORBA Software Bus
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.
Machine 1
Process A
Direct Call
Inter-Process Call
Network Call (IIOP)
Machine 2
Process B
Bus Corba : fonctions ...
Client
Return
serveur
Référence
-> faire(param1,param2,...)
Return
faire(param1,param2,...)
Unmarshaling
Marshaling
ORB
Unmarshaling Marshaling
010010010110110101111
10010110110
réseau
ORB : Liaison avec « tous » les
langages de programmation
C++
Java
Smalltalk
Ada
Souche
Souche
Souche
Souche
Bus Corba
CORBA : composantes du bus
Interface du bus
Interface d’Invocation Statique
Adaptateur d’objet
Interface de Squelettes Statiques
Interface de Squelettes Dynamiques
Interface d’Invocation Dynamique
SSI
SII
DSI
DII
ORB
OA
Noyau de communication
IR
Référentiel
des interfaces
ImplR
Référentiel
des implantations
Architecture générale
fichier
IDL
Implémentation d’objet
Client
pré-compilateur
SSI
DII
SII
Stub
client
DSI
Interface
ORB
Adaptateur d’Objet
Interface de
l ’adaptateur
noyau de l ’Object Request Broker (ORB)
Référentiel
des interfaces
Rint
Référentiel
des implémentations
Rimp
OMG-IDL : compilation
• 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 »
CORBA : le mode statique
• Les clients et serveurs implantent des descriptions
OMG-IDL communes, statiquement précisées dans la
phase de compilation/projection du source IDL.
Client
d ’objets
Stub
IDL
Contrat
IDL
Bus CORBA
Fournisseur
d ’objets
Squelette
IDL
• 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
Implémentation d’objet
Client
requête
Stub
client
réponse
squelette
statique
squelette
dynamique
Adaptateur d’Objet
ORB noyau
CORBA : le mode 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.
Interface d'invocation
dynamique (1)
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
invoke
send_deferred + get_response, poll_response
send_oneway
invoke
wait
send-deferred
send_oneWay
get_response
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;.
invocation dynamique (3)
 Etapes
1. trouver la référence d ’un objet (string_to_object)
2. recherche et interprétation de son interface dans le
référentiel des interfaces;
get_interface -> CORBA::InterfaceDef
3. obtenir la description de l ’opération à invoquer
lookup_name, describe, …..
4. construction d'un objet requête;
construire la liste des arguments à transmettre
create_request, …..
5. invocation de la requête
6. traiter les résultats retournés.
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
Intermédiaire entre le bus et
les implantations possibles des objets
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é
Servant
Proxy
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.
Architecture du POA et
terminologie
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