Upload
leon-bidault
View
113
Download
5
Embed Size (px)
Citation preview
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