l`ORB

III. Corba
CORBA
Common Object Request Broker Architecture
Architecture permettant de développer des applications
distribuées :
 standardisées
dans des environnements hétérogènes indépendants
des langages de programmation et des systèmes
d’exploitation;
basées sur la technologie objet.
© ²2004, Mireille Fornarino, E.S.S.I.
-1-
ORB (1/2)
I.5. OMA
ORB
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.
© ²2004, Mireille Fornarino, E.S.S.I.
-2-
ORB (2/2)
I.5. OMA
ORB
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
© ²2004, Mireille Fornarino, E.S.S.I.
-3-
“Proxies Make Remote Objects Look
Local”
I.5. OMA
ORB
• 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
© ²2004, Mireille Fornarino, E.S.S.I.
-4-
Transparence de localisation des objets
I.5. OMA
ORB
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
Machine 2
Process B
Direct Call
Inter-Process Call
Network Call (IIOP)
© ²2004, Mireille Fornarino, E.S.S.I.
-6-
I.5. OMA
ORB
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
© ²2004, Mireille Fornarino, E.S.S.I.
-7-
ORB : Liaison avec « tous » les
langages de programmation
C++
Java
Smalltalk
Ada
Souche
Souche
Souche
Souche
I.5. OMA
ORB
Bus Corba
© ²2004, Mireille Fornarino, E.S.S.I.
-8-
Services objet communs
I.5. OMA
Services
Les Services Objet (CORBA Services) :
Fonctionnalités système de bas niveau communes à la majorité
des applications distribuées.
 objectif : étendre les fonctions de l ’ORB
 interfaces indépendantes des domaines d’application;
 spécification par des interfaces IDL;
 leurs fonctionnalités peuvent être étendues ou spécialisées par
héritage;
© ²2004, Mireille Fornarino, E.S.S.I.
-9-
Services CORBA
• Naming
– How are objects found?
• Events
– Standardized mechanism for
client notifications.
• LifeCycle
– How are objects created, moved,
duplicated and deleted?
• Trader
– Find objects that have certain
properties
• Transactions
– Distributed 2-phase commit
• Security
– Complete distributed security
© ²2004, Mireille Fornarino, E.S.S.I.
I.5. OMA
Services
• Persistent Object
– Save objects to databases
• Concurrency
– Managing simultaneous access
• Licensing
– Managing licensed services
• Externalization
– External representation of objects
• Relationship
– Manage relationships between
objects that don't know about
each other
• Query
– Query objects on the network
- 10 -
Utilitaires communs
I.5. OMA
Services
Les utilitaires communs (CORBA Facilities)
(aussi dits canevas horizontaux):
ensemble de services orientés utilisateur de plus haut niveau
fournissant des fonctionnalités utiles dans de nombreuses
applications;
 spécification par des interfaces IDL;
 leurs fonctionnalités peuvent être étendues ou spécialisées par
héritage;
indépendants des domaines d’application;
Exemples : interface utilisateur, gestion de l ’information,
administration du système et gestion de la tâche.
© ²2004, Mireille Fornarino, E.S.S.I.
- 11 -
Utilitaires communs :
L ’interface Utilisateur
I.5. OMA
Services
Collection de composants pour standardiser l ’utilisation des IHM
sophistiquées.
gestion du rendu :
affichage des fenêtres et des éléments graphiques de dialogue
avec l ’utilisateur final.
 Gestion des documents composites :
Coopération visuelle d’applications distinctes (OPenDoc).
support de l ’utilisateur :
aide en ligne, vérificateur de texte, tableur, ….
gestion du bureau
scripts
© ²2004, Mireille Fornarino, E.S.S.I.
- 12 -
Interfaces des domaines
I.5. OMA
Services
Les interfaces ou objets des domaines (CORBA Domains) (aussi
dits canevas verticaux, objets métiers):
spécifiques à un domaine d’application (médical, financier,
télécommunications, commerce électronique, ...);
 spécification d’interfaces IDL;
 standardisées par l’OMG;
 leurs fonctionnalités peuvent être étendues ou spécialisées
par héritage;
© ²2004, Mireille Fornarino, E.S.S.I.
- 13 -
Objets applicatifs
I.5. OMA
Services
Les Objets applicatifs (CORBA Applications) :
 spécification par des interfaces IDL;
 définis par une application de l’utilisateur;
 hors du champ de standardisation de l’OMG;
 possibilité de standardisation pour des objets émergents.
© ²2004, Mireille Fornarino, E.S.S.I.
- 14 -
Vers une industrie du composant
logiciel
Objets applicatifs
(0A)
OA
SO
UC
Interfaces de domaine
(ID)
Utilitaires communs
(UC)
ID
ID
I.5. OMA
Services
SO UC
UC
SO
Bus d’objets répartis (O.R.B.)
Services objet communs (SO)
© ²2004, Mireille Fornarino, E.S.S.I.
- 15 -
CORBA : les 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
© ²2004, Mireille Fornarino, E.S.S.I.
Référentiel
des interfaces
ImplR
Référentiel
des implantations
- 18 -
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
© ²2004, Mireille Fornarino, E.S.S.I.
Référentiel
des implémentations
Rimp
- 19 -
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 »
© ²2004, Mireille Fornarino, E.S.S.I.
- 20 -
III. Corba
CORBA : le mode statique
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.
© ²2004, Mireille Fornarino, E.S.S.I.
- 21 -
III. Corba
mode statique
La projection client
Fichier
OMG-IDL
Référence d’objet
Requête
stubs
Compilation
vers client
ex : IDL/C++
© ²2004, Mireille Fornarino, E.S.S.I.
Cl_a
Cl_b
Cl_c
vers le bus
- 22 -
III. Corba
mode statique
La projection serveur
Fichier
OMG-IDL
squelettes
Compilation
vers serveur
ex : IDL/Java
Impl_a
Cl_a
Impl_b Impl_c
Cl_b
Cl_c
Obj
Requête du bus
© ²2004, Mireille Fornarino, E.S.S.I.
- 24 -
III. Corba
Invocation statique
mode statique
Implémentation d’objet
Client
requête
Stub
client
réponse
squelette
statique
squelette
dynamique
Adaptateur d’Objet
ORB noyau
© ²2004, Mireille Fornarino, E.S.S.I.
- 26 -
Exemple ORBACUS
© ²2004, Mireille Fornarino, E.S.S.I.
- 27 -
III. Corba
CORBA : le mode dynamique
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.
© ²2004, Mireille Fornarino, E.S.S.I.
- 28 -
III. Corba
Interface d'invocation dynamique (1)
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
invoke
send_deferred + get_response, poll_response
send_oneway
invoke
wait
© ²2004, Mireille Fornarino, E.S.S.I.
send-deferred
send_oneWay
get_response
- 29 -
III. Corba
Interface d'invocation dynamique (2)
mode
dynamique
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;.
© ²2004, Mireille Fornarino, E.S.S.I.
- 30 -
III. Corba
invocation dynamique (3) mode dynamique
 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.
© ²2004, Mireille Fornarino, E.S.S.I.
- 31 -
4. Corba
Interface de squelette dynamique
Composants
• 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.
© ²2004, Mireille Fornarino, E.S.S.I.
- 32 -
Composants du bus
© ²2004, Mireille Fornarino, E.S.S.I.
- 33 -
Référentiel d’interfaces
III. Corba
Référentiels
Maintient les informations sur les types, les interfaces etc.....;
Un graphe d ’objets « concepts » d ’IDL :
ModuleDef, InterfaceDef, OPerationDef, ..
Par navigation dans ce graphe ou à partir d’une référence d’objet,
on peut retrouver le contenu d’une interface, la signature d’une
opération, …
Informations pour une interface :
• son module
• son nom
• ses attributs
• ses opérations (nom, nom et types des paramètres,
exceptions, contexte)
• ses héritages
© ²2004, Mireille Fornarino, E.S.S.I.
- 34 -
Référentiel d’implémentations
III. Corba
Référentiels
. Responsable de l’enregistrement des serveurs dans le système
(enregistrement de la commande exécutable).
. Spécifié par une interface IDL.
(( Avec Orbix
• Controlé par la commande putit dans les commandes associées
lsit, catit, rmit, chmodit.
• Implémenté par un processus démon.))
© ²2004, Mireille Fornarino, E.S.S.I.
- 35 -
Interfaces de base du Bus
Object
III. Corba
module CORBA {
exception COMM_FAILURE { … };
// Autres exceptions systèmes.
interface Object {
// Duplique une référence d’objet CORBA.
Object _duplicate();
// Libère une référence d’objet.
void _release();
// Teste si une référence ne dénote aucun objet.
boolean _is_nil();
// Teste si un objet référencé n’existe plus.
boolean _non_existent(); ………………………………………...
© ²2004, Mireille Fornarino, E.S.S.I.
- 36 -
III. Corba
Object Adapter : fonctions
Adaptateur
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
© ²2004, Mireille Fornarino, E.S.S.I.
POA
- 37 -
III. Corba
Interfaces : Portable Object Adapter
Adaptateur
Interfaces IDL définies dans le module PortableServer :
• POA : Interface principale côté serveur
-quels servants sont instanciés?
-Activation/désactivation, destruction des servants
-Création de références, …
• POAManager
- Contrôle du flot des requêtes vers plusieurs POAs
• Servant
native Servant;
• POA Policies (7 interfaces)
• Servant Managers (3 interfaces)
- initialisation paresseuse des servants
• POACurrent
• AdapterActivator (Factory d’adaptateurs)
© ²2004, Mireille Fornarino, E.S.S.I.
- 38 -
III. Corba
POA
Adaptateur
« 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.
© ²2004, Mireille Fornarino, E.S.S.I.
- 39 -
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
© ²2004, Mireille Fornarino, E.S.S.I.
- 40 -
III. Corba
POA manager
Adaptateur
• Associé à un POA lors de la création de ce dernier (il ne peut pas
être changé)
Application serveur
dispatch
Requête
ORB
POA
Manager
Servants
POA
Les états possibles d’un POA manager :
• Active : routage normale des requêtes
• Holding : Requêtes stockées
• Discarding : Requêtes rejetées avec TRANSIENT
• Inactive : Requêtes rejetées ; les clients peuvent être redirigés
vers un serveur différent pour ré-essayer.
© ²2004, Mireille Fornarino, E.S.S.I.
- 41 -
III. Corba
POA Policies
Adaptateur
Chaque POA a un ensemble de politiques.
Lorsqu'un nouveau POA est créé on peut utiliser les valeurs par défaut
ou les fixer selon les besoins.
Un POA n'hérite pas des politiques de son père.
• LifespanPolicy (références transitoires ou persistantes)
• IdAssignmentPolicy (gestion de la clef)
• IdUniquenessPolicy (association servant et objets d’implémentation)
• ImplicitActivationPolicy (activation automatique ou non des servants)
• RequestProcessingPolicy (gestion ID-to-servant)
• ServantRetentionPolicy (gestion mémoire des servants)
• ThreadPolicy
© ²2004, Mireille Fornarino, E.S.S.I.
- 43 -
III. Corba
Root POA Policies
Life Span Policy
TRANSIENT ( PERSISTANT)
ID Assignment Policy
SYSTEM_ID ( USER_ID)
ID Uniqueness Policy
UNIQUE_ID ( MULTIPLE_ID)
Servant Retention Policy
RETAIN ( PERSISTANT)
Adaptateur
Request Processing Policy
USE_ACTIVE_OBJECT_MAP_ONLY ( USE_SERVANT_MANAGER )
Implicit Activation Policy
IMPLICIT_ACTIVATION
Thread Policy
ORB_CTRL_MODEL
© ²2004, Mireille Fornarino, E.S.S.I.
- 44 -
Etapes de mise en œuvre
• Définition de l ’interface IDL
• Pré-compilation du fichier IDL et Projection vers des langages
de programmation.
• Code du serveur :
Implantation des interfaces IDL
Implantation du serveur
• Implantation des clients
• Installation et configuration des serveurs
• Diffusion et configuration des clients
• Exécution répartie de l’application.
© ²2004, Mireille Fornarino, E.S.S.I.
- 47 -
III. Corba
Interopérabilité
Interopérabilité
Avant CORBA 2.0, Problème d'interopérabilité entre ORBs.
Interopérabilité
Capacité pour un ORB A d'invoquer une opération définie
en IDL sur un objet résidant sur un ORB B.
L'ORB A et B étant des implémentations de CORBA différentes.
© ²2004, Mireille Fornarino, E.S.S.I.
- 48 -
Interopérabilité d’applications avec
CORBA
III. Corba
Deux problèmes :
1- communication d’applications distribuées au sein d’un même
environnement;
2- interopérabilité d’applications distribuées entre environnements
hétérogènes.
Problème 1
Problème 1
Communication
A1
Problème 2
Interopérabilité
...
An
Environnement X
© ²2004, Mireille Fornarino, E.S.S.I.
Communication
B1
...
Bn
Environnement Y
- 49 -
Portabilité d’applications avec
CORBA1.2
III. Corba
Interopérabilité
CORBA 1.2 permet de :
• résoudre le problème de communication d’applications distribuées
au sein d’un même environnement;
Problème 1 résolu
Problème 1 résolu
Communication
IDL
A1
IDL
...
Binding
??
Communication
IDL
An
B1
Binding
Binding
ORB 1.2 vendeur x
Environnement X
© ²2004, Mireille Fornarino, E.S.S.I.
Problème 2
IDL
...
Bn
Binding
ORB 1.2 vendeur y
Environnement Y
- 50 -
Portabilité d’applications avec
CORBA 1.2
III. Corba
Interopérabilité
CORBA 1.2 permet de :
• simplifier le portage d’applications entre environnements
hétérogènes grâce au langage IDL, aux standardisations des bindings.
IDL
A1
Binding
...
IDL
IDL
An
B1
Binding
Binding
IDL
...
Bn
Binding
ORB 1.2 vendeur y
Environnement Y
© ²2004, Mireille Fornarino, E.S.S.I.
- 51 -
Interopérabilité d’application avec
CORBA 2.0
III. Corba
Interopérabilité
CORBA 2.0 permet de résoudre le problème d’interopérabilité
d’applications distribuées entre des environnements hétérogènes
grâce au protocole de communication commun
GIOP (General Inter ORB Protocol).
IDL
A1
IDL
...
Binding
An
Interopérabilité
Binding
ORB 2.0 vendeur x
Environnement X
© ²2004, Mireille Fornarino, E.S.S.I.
Problème 2 résolu
IDL
B1
Binding
GIOP
IDL
...
Bn
Binding
ORB 2.0 vendeur y
Environnement Y
- 52 -
III. Corba
GIOP et IIOP
Interopérabilité
 GIOP (General Inter-ORB Protocol) spécifie un ensemble de
formats pour les messages ainsi qu'une représentation commune
des données échangées entre les ORBs.
La représentation des données communes est basée sur la
spécification CDR (Common Data Representation).
 IIOP (Internet Inter-ORB Protocol) est l'implémentation du
protocole GIOP basé sur TCP/IP.
© ²2004, Mireille Fornarino, E.S.S.I.
- 54 -
III. Corba
IOR
 IOR (Interoperable Object Reference)
 interface OMG IDL : repository ID
adresse + port IP
clé de format libre (identifie le POA et l’objet dans le POA)
Spécifique à l’ORB
possède une forme externe diffusable
chaîne IOR : IOR: ….
© ²2004, Mireille Fornarino, E.S.S.I.
- 55 -
Services communs CORBA
© ²2004, Mireille Fornarino, E.S.S.I.
- 56 -
III. Corba
Les services communs CORBA
Services
 Service de recherche d’objets : pour retrouver un objet
Nommage (Naming) : par un nom : service de « pages blanches »
Vendeur (Trader) : par des propriétés: service de « pages jaunes
 Services concernant la vie des objets :
Life Cycle, Property, Relationship, Externalization, Persistent
Object, Query, Collection, Versionning, Time, Licencing
Services de sûreté de fonctionnement :
Security, Transactions, Concurrence
 Services de communications asynchrones:
Events, Notification, Messaging
© ²2004, Mireille Fornarino, E.S.S.I.
- 57 -
Les services de recherche d’objets
CORBA
Client Java
Traitement
Services
Serveur C++
Service de
recherche
d’objets
IOR
III. Corba
Repertoire
IOR
Bus d’objets répartis CORBA sur Internet (IIOP)
Services Nommage et/ou Vendeur
© ²2004, Mireille Fornarino, E.S.S.I.
- 59 -
III. Corba
Le service de Nommage
Services
Le service de Nommage ou Namming service permet :
 d’associer un nom à une référence d’objet CORBA, relativement
à un contexte de noms;
 de retrouver la référence d’objet ainsi que l’objet associé;
 de naviguer à l'intérieur d’un contexte de noms.
Opérations principales
ajouter une association : bind, rebind, ...
résoudre une association : resolve
détruire une association : unbind
lister le contenu : list
détruire le contexte : destroy
© ²2004, Mireille Fornarino, E.S.S.I.
- 60 -
III. Corba
Le contrat IDL du service Nommage
Services
module CosNaming
// Le service Nommage.
{ typedef string Istring;
struct NameComponent { // Un nom d’association.
string id;
string kind; };
// Un chemin d’accès = une suite de noms.
typedef sequence<NameComponent> Name;
interface NamingContext {
// Un contexte.
enum NotFoundReason { missing_node, not_context, not_object };
exception NotFound {NotFoundReason why; Name rest_of_name;};
exception CannotProceed {NamingContext cxt; Name rest_of_name;};
exception InvalidName { };
exception AlreadyBound { };
exception NotEmpty { };
// Associer un nom à une référence.
void bind(in Name n, in Object obj) raises(NotFound, CannotProceed, InvalidName, AlreadyBound);
// Rechercher une association.
Object resolve (in Name n) raises(NotFound, CannotProceed, InvalidName);
// Autres opérations :
// rebind bind_context rebind_context unbind
// new_context bind_new_context
// destroy list
};
};
© ²2004, Mireille Fornarino, E.S.S.I.
- 61 -
Comment retrouver la référence du
service de nommage ?
III. Corba
Services
C’est un « objet notoire » du bus CORBA
de nom NameService
Quelque soit le langage, le scénario est
a. opération CORBA::ORB::resolve_initial_references
b. conversion en CosNaming::NamingContext
// En C++, obtenir la référence du service Nommage.
CORBA_Object_var contextObj =
orb->resolve_initial_references ("NameService");
CosNaming::NamingContext_var context =
CosNaming::NamingContext::_narrow(contextObj);
© ²2004, Mireille Fornarino, E.S.S.I.
- 62 -
III. Corba
Utilisations du service Nommage
Services
Enregistrer une référence
diffusion par un serveur de ses références d’objet
• création d’un chemin
• opération bind ou rebind
CosNaming::Name_var nsNom = new CosNaming_Name();
nsNom->length(1);
nsNom[0].id = (const char*) "BNP";//nom du serveur
nsNom[0].kind = (const char*) "BANKSERVER";
context->bind (nsNom, bnpServeur);
Rechercher une référence
(2) création d’un chemin valide
(3) opération resolve
(4) conversion vers le type nécessaire
CORBA::Object_var objRef = context->resolve (nsNom);
bankServer_var bnp = bankServer::_narrow (objRef);
© ²2004, Mireille Fornarino, E.S.S.I.
- 63 -
III. Corba
Le service Vendeur
Services
Le service vendeur ou Trader service permet :
 d ’enregistrer des objets auprès de ce service en les caractérisant
par un ensemble de propriétés.
 de retrouver un service en précisant son type et les critères le
caractérisant (différentes politiques de recherche possibles)
Opérations principales
découvrir et importer des services : Interface LookUp :
query (type de service recherché, contraintes, préférences, politique de recherche, ….)
parcourir les réponses : Interface OfferIterator
mise à jour du service Vendeur : Interface Register
export, withdraw
…...
© ²2004, Mireille Fornarino, E.S.S.I.
- 64 -
III. Corba
Services
Le service de notification d'événements
La plupart des requêtes CORBA se traduisent par l’exécution
synchrone d’une opération (le client connaît la référence de
l’objet auquel la requête s’adresse et le client ainsi que l’objet
doivent être tous deux actifs) et sinon?
Le service d'Evénements ou Event service permet de
découpler la communication entre objets.
Mode de communication découplé :
 lorsque le client et l’objet ne se connaissent pas;
 lorsque le client et l’objet ne sont pas actifs simultanément.
© ²2004, Mireille Fornarino, E.S.S.I.
- 65 -
Communication événementielle
principes de fonctionnement
• concepts de base : événements, réactions (traitements
associés à l’occurrence d’un événement)
• principe d’attachement : association dynamique entre
un nom d’événement et une réaction
• communication anonyme : indépendance entre
l’émetteur et les “consommateurs” d’un événement
© ²2004, Mireille Fornarino, E.S.S.I.
- 66 -
Un canal d’évènements : notification
III. Corba
Services
PushConsumer
Consommateur
PushSupplier
Push
Producteur
void push(in any data) raises(Disconnected);
Consommateur
Producteur
Push
Canal
Consommateur
Consommateur
Producteur actif / Consommateur réactif
Le canal diffuse les évènements
© ²2004, Mireille Fornarino, E.S.S.I.
- 68 -
Un canal d’évènements : demande
III. Corba
Services
Consommateur
Pull()
Producteur
Consommateur
Producteur
Pull()
Canal
Consommateur
PullSupplier {
//demande de production d’un événement
demande
any pull() raises(Disconnected);
Consommateur
// présence d’un événement
any try_pull(out boolean has_event) raises(Disconnected);
Producteur réactif / Consommateur actif
Le canal procure les évènements
© ²2004, Mireille Fornarino, E.S.S.I.
- 69 -
Un canal d’évènements : file
d’évènements
III. Corba
Services
Consommateur
Pull()
Producteur
Consommateur
Producteur
Push()
Canal
Consommateur
Consommateur
Producteur actif / Consommateur actif
Le canal gère des files d’évènements
© ²2004, Mireille Fornarino, E.S.S.I.
- 70 -
Un canal d’évènements : collecte
d’évènements
III. Corba
Services
Consommateur
Push()
Producteur
Consommateur
Producteur
Pull()
Canal
Consommateur
Consommateur
Producteur réactif / Consommateur réactif
Le canal est une entité active voire intelligente
© ²2004, Mireille Fornarino, E.S.S.I.
- 71 -
III. Corba
Le service de Transaction
Services
Le service de Transaction ou Transaction service permet d’assurer
la consistance des traitements en respectant les propriétés ACID
(Atomicité, Consistance, Isolation et durabilité) des transactions.
Il permet :
 de commencer et de terminer une transaction;
 de contrôler la propagation d’une transaction;
 d’associer plusieurs objets répartis à une seule et même transaction;
 de coordonner la terminaison d’une transaction (2 phase commit).
© ²2004, Mireille Fornarino, E.S.S.I.
- 72 -
III. Corba
Le service de Concurrence
Services
Le service de Concurrence ou Concurrency control service permet
de contrôler l’accès à un objet de manière à gérer la cohérence et la
consistance des opérations entre cet objet et les objets qu’il accède ou
bien qui l’accèdent.
Il permet de créer des verrous répartis et de spécifier le type de
verrou crée (lecture, écriture, mise-à-jour etc...).
© ²2004, Mireille Fornarino, E.S.S.I.
- 73 -
Le service d’Externalisation
III. Corba
Services
Le service d’Externalisation ou Externalization service permet :
 l’externalisation d’un objet, c’est à dire la représentation de
l’état de l’objet dans une séquence d’octets (en mémoire,
sur disque, sur réseau) transportable, de durée de vie illimitée
indépendante de l’environnement (ORB) d’origine.
 l’internalisation des données, impliquant la création d’un nouvel
objet dans le même environnement ou dans un environnement
différent.
© ²2004, Mireille Fornarino, E.S.S.I.
- 74 -
III. Corba
Le service Cycle de vie
Services
Le service Cycle de vie ou Life cycle service permet :
 de gérer la création, la destruction, la copie et le déplacement
des objets du bus;
 les objets sont créés par l’intermédiaire d’objets appelés Factories
dont la référence est accessible au client;
 un objet est détruit, copié ou déplacé à l’aide d’opérations définies
dans l’interface de base LifeCycleObject;
© ²2004, Mireille Fornarino, E.S.S.I.
- 75 -
III. Corba
Sécurité et temps
Services
Le service de Sécurité (Security) permet de gérer les
fonctions suivantes :
 authentification
 autorisation
 sûreté et intégrité des communications
 encryptage
 administration de la sécurité
Le service de Temps (Time) permet la synchronisation périodique
d’horloges dans tous les composants d’un système réparti.
© ²2004, Mireille Fornarino, E.S.S.I.
- 77 -
III. Corba
4ème RFP
Services
Le service de Propriétés (Properties) permet d’associer
dynamiquement une liste de propriétés à un objet. Il est possible
d’ajouter, de supprimer, de modifier et de retrouver toute propriété
associée à un objet.
Le service d’interrogations (Query) permet d’exprimer des requêtes
sur des ensembles d’objets CORBA.
Le service de License (Licensing) contrôle et gère les rémunérations
associées à l’utilisation d’un service objet donné.
© ²2004, Mireille Fornarino, E.S.S.I.
- 78 -
III. Corba
5ème RFP
Services
Le service de Gestion des versions (Change Management) permet
de gérer l’évolution des versions des interfaces des objets ainsi que
de l'adéquation avec leurs implémentations.
Le service d’Annuaire par fonctionnalités (Trader) permet d’associer
des fonctionnalités à des objets CORBA. Le client utilise ce service
comme l’annuaire des pages jaunes.
Le service de Collection (Collection) permet de créer et de manipuler
des collections d’objets.
© ²2004, Mireille Fornarino, E.S.S.I.
- 79 -
III. Corba
Taxonomie des services
Services
Nommage + Annuaire par fonctionnalités
Persistance + Externalisation
Cycle de vie + Relation
Serveur de requêtes + Collections + Properties
Transaction + Concurrence
Sécurité + License
Gestionnaire des versions
Time
Event
© ²2004, Mireille Fornarino, E.S.S.I.
- 80 -
III. Corba
CORBA 3.0
Une suite de spécifications
• Intégration de Java et l’Internet
– Passage par valeur (Corba 2.3)
– Java to IDL : Interopérabilité des objets RMI (2.3)
– (Firewall specification) Mid-2001
– Interopérabilité et service de nommage (2.4)
• Amélioration de la qualité de service
– Asynchronous Messaging (2.4 fin 2000)
– Corba minimum pour les systèmes embarqués
– Temps réel,
• Modèle de composants, langage de script
© ²2004, Mireille Fornarino, E.S.S.I.
- 82 -
Integration de Java RMI avec CORBA
: RMI-IIOP
• RMI est une solution tout-java
– Un modèle simple de programmation
– “An immature middleware infrastructure”
• CORBA est un standard pour les objets distribués
– Un modèle de programmation pas si simple et non dédié spécifiquement à
Java
– “A mature middleware infrastructure”
• RMI s’exécute via IIOP
– Utilisation des spécifications sur le passage par valeur de l’OMG
– Java-to-IDL
– Mais pas de chargement dynamique des stubs
© ²2004, Mireille Fornarino, E.S.S.I.
- 83 -
RMI/CORBA via IIOP
RMI
client
implementation
d’un Objet
CORBA
RMI
stub
CORBA
Squelette
ORB
ORB
Réseau via IIOP
© ²2004, Mireille Fornarino, E.S.S.I.
- 84 -
Pourquoi CORBA?
• Infrastructure largement adoptée pour la distribution d’objets
• Plate-forme indépendant, il permet l’intégration de systèmes
propriétaires
• Langage indépendant : Clients et serveurs peuvent être
implémentés dans des langages différents
• CORBA est indépendant d’une compagnie (donc d’Un produit ou
d’une architecture)
• De nombreux services
• Fournit un accès multi-langages pour les EJBs.
« CORBA is the only middleware platform that is both
vendor- and language-independent. »
« You still need to know what you are doing and CORBA cannot do your thinking for you ».
© ²2004, Mireille Fornarino, E.S.S.I.
- 85 -
CORBA …
• Pas d’approche standard du déploiement
– (connexion entre IMR et serveurs non standardisé)
– Quels services sont disponibles sur le site de déploiement
• Pas de support des idioms de développement des serveurs CORBA
– Comment « bootstrapper » les références? (naming, trader, …)
– Mise en place de factories gérant le cycle de vie…
• Difficulté pour l’extension des fonctionnalités des objets.
– Nécessité d’une construction par composition plutôt que par héritage
• Pas de gestion automatique du cycle de vie des objets.
– Qui gère l’activation des objets? Pas de standard IMR…
© ²2004, Mireille Fornarino, E.S.S.I.
- 86 -
COMPOSANTS, besoins
• Des unités interchangeables
– Spécification de ce qui est offert
– Spécification de ce qui est nécessaire
• Déploiement standardisé semi-automatique
• Génération de code pour la mise en œuvre de certains « services »
(D.P.) (Factory, persistance, sécurité, …)
© ²2004, Mireille Fornarino, E.S.S.I.
- 87 -
CORBA Component Model (CCM)
• Modèle de composants côté serveur, il étend le modèle Objet
CORBA
• Proche des EJB et COM : standardisation de
– Services offerts au client : Évènements, Transactions, Sécurité, persistance
– Déploiement
– Interfaces multiples d’un même composant
• Non limité à Java ou Windows : langage indépendant
Intégré à CORBA 3.0 spec
© ²2004, Mireille Fornarino, E.S.S.I.
- 88 -
CCM: extensions à CORBA
• Modèle de composants
- Extensions IDLs (CIDL) , I.R. et ORB
-Modèle de containeur
-Component Implementation Framework (CIF)
-Modèle de « packaging » et déploiement
-Support aux EJBs et interworking
© ²2004, Mireille Fornarino, E.S.S.I.
- 89 -
En cours, … MDA
Over the past decade or more, companies have endured a succession of
middleware platforms.
Jon Siegel, OMG Director of Technology Transfer
I think the requirements for business software will continue to evolve faster than
the technology solutions and that business developers will continue to have
"programming" jobs for the rest of my career.
Carol Burt, 2AB, Inc., and OMG Architecture Board Member
© ²2004, Mireille Fornarino, E.S.S.I.
- 90 -
Références
Client/Server Programming with Java and CORBA - R. Orfali, D. Harkey John Wiley Sons 1997.
CORBA, ActiveX et Java Beans - J. M. Chauvet Eyrolles 1997.
Architecture J2EE, Khin Chhoung LAO, Cnam.
Éléments fondamentaux des systèmes distribués, Karim Khelifi
Distributed Computing and Client-Server Systems, Prentice Hall - Amjad Umar .
Client/Server Computing - Byte Special Report, avril 95.
Systèmes d ’exploitation - Systèmes centralisés - Systèmes distribués, Prentice Hall - Andrew
Tanenbaum, 1994
Enterprise JavaBeans Specifications JavaSoft (http://www.javasoft.com/ejb)
CORBA Specifications: Object Management Group (http://www.omg.org)
http://www.ooc.com/ob/training_download.html
© ²2004, Mireille Fornarino, E.S.S.I.
- 91 -
Références
Composants CORBA : http://umeet.uninet.edu/conferencias/acsdsevilla/ccm
CORBA Junction: IDL for CORBA 3.0,
Extending the relationship between interfaces, http://www-106.ibm.com/developerworks/components/
Client-Serveur, Etude de cas: CORBA – OMG Portable Object Adapter; C. Toinard, ENSERB-3 ième
année Informatique
Intégration des Systèmes Clients/Serveurs, André Freyssinet,
HTTP://dyade.inrialpes.fr/~freyssin
Cours Technologie Internet: Modèles de programmation Jarle HULAAS
http://cui.unige.ch/tios/co rs/TechInternet.html
Model Driven Architecture by Richard Soley and the OMG Staff Strategy Group
Object Management Group, White Paper
Draft 3.2 – November 27, 2000
© ²2004, Mireille Fornarino, E.S.S.I.
- 92 -