Cours Middleware orientés objets

@ Vincent Englebert -
UNamur 1
Middlewares Orientés ObjetsMiddlewares Orientés Objets

Conditions
Ces matériaux pédagogiques devenus obsolètes dans notre cursus
sont distribués en l’état et ne sont plus maintenus.
Tout emprunt vers d’autres supports respectera les conditions de la
licence Creative Commons Attribution telle que déclarée dans l’entête
en référençant:
Source: Université de Namur Belgique – Faculté d’informatique – V.
Englebert
Si jamais, une information était incorrectement référencée dans ce
document, les ayants-droits sont priés de me contacter afin de corriger
le document: vincent.englebert (at) unamur.be
@ Vincent Englebert –
Unamur 2

@ Vincent Englebert - UNamur 3
Bibliographie
Les documents de l'OMG
le document de référence de Corba
le document de mapping IDL – Java
le document de référence pour le Naming Service
le document de référence pour le Trading Service
le document de référence pour l'Object Transaction Service
@Book{tanenbaum02-ds,
author = {Andrew S. Tanenbaum, Maarten van Steen},
title = {Distributed Systems: Principles and Paradigms},
publisher = prentice,
year = 2002,
isbn = 0130888931
}

PlanPlan
Introduction
Interface Description Language (IDL)
Architecture
Présentation globale
Le bus CORBA
Intéropérabilité entre bus CORBA
Le protocole GIOP
CDR
GIOP
IIOP
L’adaptateur d’objet (POA)
Procédure de Déploiement d’une Application / Exemple.
Passage par Valeur
Localisation d’Objets Distribués
Négociation de Services
Gestion du Cycle de Vie

IntroductionIntroduction
L'OMG (Object Management Group)
http://www.omg.org
toutes les spécifications sont accessibles en ligne
organisation fondée en 1989
regroupe plus de 800 sociétés membres (privé/public)
produits
UML 2.0
Unified Modeling Language
Langage de modélisation
MOF
Meta-Object Facility
Méta-modèle
CORBA 3.0
Common Object Request Broker Architecture
CCM

Motivation
CORBA peut être considéré comme une architecture de référence qui
permet de comprendre d'autres technologies comme
les web-services
RMI
DCOM
.NET
etc etc

Là où on ne l'attend pas…
[July 13, 2005] PrismTech Achieves Major Technical Breakthrough Porting a C++ CORBA(R) ORB to a Digital Signal Processor (DSP)
WASHINGTON --(Business Wire)-- July 13, 2005 -- Allowing more Real-time and Embedded Applications Developers to Reap the Benefits of
CORBA Technology
Today at the OMG(TM)'s Real-time and Embedded Systems Workshop, PrismTech a leading provider of productivity tools and middleware,
announced it had achieved a major technical breakthrough by porting its OpenFusion e*ORB SDR C++ edition product to a Digital Signal
Processor (DSP).
Digital Signal Processing is a key technology fuelling innovative, high growth applications for many of today's fast growing markets such as
digital wireless, broadband access, digital audio, high-resolution imaging and digital motor control. DSP is unique because it processes data in
real-time making it perfect for applications that cannot tolerate any delays.
Running CORBA middleware on a DSP achieves flexibility and simplifies integration by exposing the services offered by the DSP far more
widely than is possible with any other technology. Any application where a DSP is integrated with external systems of any kind benefits from the
simplified integration and enhanced flexibility provided by CORBA.
Traditional thinking suggested that due to the nature of its highly restricted environment that it was not possible to run a C++ ORB on a DSP.
Now PrismTech has been able to achieve a major breakthrough by porting its OpenFusion e*ORB C++ edition to a DSP. This has been
achieved through the unique micro-kernal architecture of the C++ ORB combined with footprint optimization.
"One example of the significant benefits that can be gained from hosting OpenFusion e*ORB SDR C++ edition on a DSP is in software defined
radio (SDR) development," said Andrew Foster, Product Manager, PrismTech. "Efficiently hosting a C++ ORB on a DSP is a major move
forward in standardizing the interfaces in a SDRs signal processing chain and improving waveform portability. The fact that a C++ CORBA
component can be hosted on a DSP means that a unified C++ language binding can now be used across GPPs and DSPs, something that was
previously impossible."
OpenFusion e*ORB SDR is available for the Texas Instruments C64x family of DSPs.
About PrismTech
Founded in 1992, with offices in the USA and Europe, PrismTech is a privately held software products company. PrismTech serves
international Fortune 500 customers in the telecommunications, data communications, defense and aerospace sectors. PrismTech is an
acknowledged leader in productivity tools and middleware, with solutions ranging from wide-scale integration to embedded real-time systems,
supporting applications from operations support systems (OSS) through to software-defined radio (SDR). For additional information about
PrismTech, visit the web site at http://www.prismtech.com.
CORBA is a registered trademark of the Object Management Group, Inc in the U.S. and other countries. OpenFusion and e*ORB SDR are
trademarks of PrismTech. All other trademarks are the property of their respective owners.
http://www.tmcnet.com/usubmit/2005/jul/1162959.htm

La vision
Le système est perçu comme un ensemble d'objets et
d'applications "utilisatrices".
Ces objets peuvent être répartis
dans des applications différentes
développées avec des langages différents
sur des machines hôtes différentes, géographiquement éloignées
avec des systèmes d'exploitation différents
communicant avec des protocoles réseaux différents
et intégrés à différents environnements de déploiement
serveur de sécurité
serveur transactionnel
serveur de bases de données
…
Conceptuellement, ces objets sont rendus interopérables (ils peuvent
s'appeler l'un l'autre ou être utilisés par d'autres applications
utilisatrices) grâce à un "bus" de communication: l'ORB.

FirewallFirewall
Objets répartis
UNIX
NT
MACOS
W-CE
Java
C++
Cobol
LispC++
Smalltalk
Firewall

Objets répartis
NT

CORBACORBA
Object Request Broker (ORB)
l’ORB est un bus qui permet de répartir des objets distribués et de les rendre interoperables.
Object Services
un ensemble de services généraux au dessus de l’ORB
naming
event
persistent object service
life-cycle
concurrency
externalization
relationship
transaction
query property
time
Common Facilities
modèles d’applications qui résolvent des problèmes communs à de nombreuses architectures distribuées
administration système
gestion des utilisateurs
gestion des tâches
Corba Domains
médecine, transport, simulation, banques, BD génomiques, ...
security
trader
collection
versioning
licence
notification
Site du cours: suivre Corba / OMG

Le langage IDL
(Interface Description Language)
Le langage IDL
(Interface Description Language)

Exemples d’hétérogénéité sémantiqueExemples d’hétérogénéité sémantique
Template
généricité
record
arrays
union
type constructor
list
interface
virtual class
héritage (simple/multiple)
overriding
dynamic typing
IDL (Interface Description Language) est un language de description d’objets
distribués neutre.
Module, objet, méthode, héritage, …
indépendant des langages de programmation et des architectures
L’OMG définit des règles strictes de mapping d’IDL vers les langages de
programmation. Exemples:
héritage multiple vers Java
méthode vers C, COBOL
héritage vers C, COBOL
int vers COBOL
etc.

L’Objet distribué en CORBAL’Objet distribué en CORBA
Un objet distribué en CORBA est perçu comme une entité offrant un
certain nombre de services accessibles à distance.
module NASA {
typedef unsigned long Delai;
typedef sequence<Delai> SequenceBooster;
interface engin {
attribute string comment;
readonly attribute string nom_engin;
void decoller(in Delai d);
boolean statusDecollage(in string reservoire,
out long niv_Hydrogene,
inout Delai t);
};
interface fusee: engin {
oneway void setSequenceBoost(in SequenceBooster boost);
};
};
Définition d’objet
méthode
opération
Attribut d’état
Appel
oneway
(asynchrone)
entrée/sortie/entrée-sortie
Type de données
héritage

Utilisation d’IDLUtilisation d’IDL
C++ COBOLJava
BUS CORBA
IDL
Idl2c++ idl2java idl2cobol
1. Modélisation par un diagramme de classes des composants répartis que l'on va
trouver dans le système d'informations distribué
2. Chaque classe définira un contrat proposant les services offerts par chaque objet
distribué de cette classe à ses clients potentiels.
a) applications
b) objets répartis
3. Chaque classe sera traduite en IDL et deviendra une "interface" corba
4. La compilation de l'IDL produira un framework dans des langages cible que
chaque responsable informatique pourra étendre pour fournir une implémentation.

Commentaires
/* ceci est un commentaire */
// ceci aussi
Identificateur
id :: = lettre caractere*
caractere ::= lettre | chiffre |'_’
lettre::='a’ ..'z’'A’ ..'Z’
chiffre::='0’ ..'9’
Interface
le langage IDL permet de spécifier de manière abstraite les services rendus par un objet distant
indépendamment de son implémentation et de la sémantique du langage dans lequel il a été
implémenté
Un module contient
des définitions de constantes
des types de données
des interfaces
des exceptions
d’autres modules
Un identificateur à une portée locale au module/interface qui le contient
Un module est un espace ouvert qu’il est possible de compléter a posteriori.
Il structure les définitions de données permettant ainsi d’éviter des conflits de nom
module Fortis { module CGER { interface customer … } module Generale { interface customer … } }
Un identificateur peut être référencé dans un module comme suit:
Math::Trigo::PI : l’identificateur PI dans le module Trigo dans le module Math

IDL est un langage fortement typé
Types scalaires
short entier 16 bits signé
unsigned short idem non signé
long entier 32 bits signé
unsigned long idem non signé
long long entier 64 bits signés
unsigned long long idem non signé
float nombre flottant 32 bits IEEE
double nombre flottant 64 bits IEEE
long double nombre flottant 128 bits
boolean booléen TRUE et FALSE
octet octet 8 bits
char caractère 8 bits ISO latin-1
wchar caractère au format international (unicode)
string chaîne de caractères
wstring chaîne de caractères au format international
Octet: ne subit aucune modification sur le bus CORBA.
String: non borné, mais string<80> est autorisé
Constantes
déclaration ::= const identificateur '=’ expression
const string UneChaine = « Namur, ville capitale » ;
const double PI= 3 + 0.1415 ;
const char accept=‘y’ ;
const long TAILLE=20 ;

Définitions de type
définition-de-type ::= typedef type identificateur
typedef unsigned short Jour
Types complexes
énumérations
énumeration ::= enum identificateur' {‘ identificateur {' ,’ identificateur }*' }’
enum PersonneID { etudiant, enseignant, etranger };
structures
structure ::= struct identificateur' {‘ { champ } +' }’
champ ::= type identificateur' ;’
struct Adresse { string rue; long numero; string ville ; };
unions
union TypePersonne switch (PersonneID) {
case etudiant: long numero_carte;
case enseignant: string numero_securite_sociale;
case etranger: wstring nom_prenom_pays;
};
tableaux
tableau ::= type dimension { dimension } *
dimension ::=' [‘ cst_entier_positif' ]’
typedef float[TAILLE][TAILLE] Matrice;
séquences
séquence::= sequence' <‘ type' >’
| sequence' <‘ type' ,’ cst_entier_positif' >’
Si une borne est précisée, elle mentionne le nombre maximal d’éléments que l’on peut stocker dans une
séquence. La taille de la séquence est disponible à l’exécution.
sequence list_adresse < Adresse , 3 > ;

Interface
Une interface est une description d’un ensemble d’opérations qu’un client peut solliciter d’un
objet. Le langage IDL permet de décrire syntaxiquement les interfaces.
Une interface peut hériter d’autres interfaces
Une interface peut posséder
des attributs (attribute)
des exceptions (exception)
des opérations
des constantes (const)
des déclarations de types (typedef)
Attributs
attribut ::= [ readonly ] attribute type identificateur {' ,’ identificateur }*
Une déclaration d’attribut est équivalente à la déclaration de méthodes d’accès:
readonly attribute String name;
String __get_name();
void __set_name(in String name); /* si pas readonly */
Exceptions
un type d’exception se définit comme une structure à la différence du mot clef exception à la
place de struct.
Ce type d’information est utilisé pour retourner une information lorsqu’un problème survient à
l’exécution d’une opération.
exception division_par_zero { long numerateur; }
Une interface est considérée comme un type et dès lors, il est permis d’utiliser une
interface comme type de résultat, de paramètre, ou d’attribut.

Opération
opération ::= [ oneway ] op_type identificateur paramètres [ raise_exp ] [ context_expr ]
op_type ::= type | void
raise_exp ::=raises' (‘ identificateur {' ,’ identificateur }*' )’
context_exp ::= non abordé dans ce cours
paramètres ::=' (‘ paramètre*' )’
paramètre ::= [ in | out | inout ] type identificateur
si une opération est oneway
l’invocation de cette méthode est réalisée de manière asynchrone
pas de paramètres out ou inout
pas d’exception
sémantique besteffort, l’opération sera exécutée 0 ou 1 fois (exemple: panne de
réseau).
La présence d’une clause raises signifie que l’exécution peut lever une exception, dans ce
cas, les paramètres out et inout sont indéterminés.
Outre les exceptions définies par l’utilisateur, des exceptions système peuvent aussi être
levées.
La surcharge est interdite, un nom = 1! Opération
Héritage
Un sous-type possède l’ensemble des caractéristiques figurant
dans les super-types.
Il ne peut y avoir de conflit de nom.
La structure en diamant ne pose pas de problème.
Tous les objets supportant une interface CORBA héritent implicitement de
l’interface CORBA::Object.
Interface A
Interface B Interface C
Interface D

local: certaines interfaces peuvent être déclarées locales. Ceci signifie
permet de décrire des objets non distribués avec l’IDL. L’OMG définit
ainsi l’architecture interne de chaque application avec l’IDL.
Le passage par valeur
IDL permet de définir des types d'objets dont les instances sont passées
par valeur dans les appels distants plutôt que par référence (dans le cas
des interfaces).
Ce point est présenté dans la suite de l'exposé.

CORBA/IDL C++ Java
short CORBA::Short short
unsigned short CORBA::Ushort short
long CORBA::Long int
unsigned long CORBA::Ulong int
long long CORBA::LongLong long
unsigned long long CORBA::ULongLong long
float CORBA::Float float
double CORBA::Double double
long double CORBA::LongDouble not yet defined
boolean CORBA::Boolean boolean
octet CORBA::Octet byte
char CORBA::Char char
Règles de mappingRègles de mapping

Règles de mappingRègles de mapping
CORBA/IDL C++ Java
module namespace package
type élémentaire définition de type type élémentaire
constante constante attribut constant
définition de type typedef classe
énumération enum classe
structure structure classe
union classe classe
tableau tableau tableau
séquence classe tableau
interface classe interface
référence d'objet instance instance
attribut 1/2 fonctions 1/2 fonctions
opération fonction fonction
invocation appel -> appel .
passage de paramètres val/&/* valeur/Holder
exception classe classe

ArchitectureArchitecture

Client
IDLStub
Client
IDLStub
Client
IDLStub
ORB
Dynamic
Invocation
Client
IDLStub
ORB API
ClientClient
• Object
• Process
• DBMS
Stub/ Static Invocation Interface (SII)
C’est le résultat de la projection des
descriptions IDL dans un langage de
programmation donné. Le stub est le proxy
qui représente un objet distant, et par lequel
l’application cliente pourra émettre ses
requêtes. Le stub emballe les requêtes,
déballe les résultats, et procède aux appels
nécessaires à l’ORB pour envoyer la requête.
Un objet distant peut posséder plusieurs
stubs selon le langage utilisé pour
implémenter l’application cliente (COBOL/C+
+/Java/…).
Dynamic Invocation Interface (DII)
Permet de construire des requêtes
dynamiquement. Ce mécanisme est plus
complexe. Il permet néanmoins d’écrire des
applications clientes qui découvrent leur
contexte (la nature des composants distribués
qui les entourent) au moment de l’exécution.
Exemple: browser, compilateur,
administration, ...
ORB Core
Il assure le transport des invocations entre les
objets. Cette couche utilise le protocole IIOP
pour communiquer avec des objets sur des
machines différentes.
L’ORB est caché de l’utilisateur et seules
quelques fonctions élémentaires sont
accessibles.

Dynamic Skeleton Interface (DSI)
Ce composant répond aux requêtes émanant
des clients. Cette couche peut répondre à des
requêtes sans que le skeleton statique ne soit
disponible.
Exemple
- smalltalksmalltalk: ce langage peut créer de nouveaux
types d’objets distribués dynamiquement
- bridgebridge inter-ORB
Static Skeleton Interface
Chaque type d’objet sur le serveur peut avoir
un skeleton (généré à partir de la description
IDL) qui déballe les requêtes et emballe les
résultats.
ORB
Client
IDLStub
Client
IDLStub
Client
IDLStub
Client
IDLStub
Client
IDLStub
Dynamic
Skeleton
Dynamic
Skeleton
Static
Skeleton
Static
Skeleton
ORB APIORB API
ServerServer
• Object
• Process
• DBMS
ServerServer
• Object
• Process
• DBMS
Object AdapterObject Adapter
Object
Adapter
Interface
Object
Adapter
Interface
Object Adapter
génération et interprétation des références
d’objets
invocation des méthodes
sécurité des invocations
dés/activation des objets
enregistrement des objets

ORB
Interface
Repository
Implementation
Repository
Interface Repository (IR)
L’IR est un service qui fournit des objets
persistants qui représentent l’information
définie par les spécifications IDL et qui sont
disponibles au moment de l’exécution.
L’IR est utilisé par les compilateurs IDL pour
effectuer du type checking, et par toutes les
applications qui découvrent leur
environnement au moment de l’exécution
(Browser, administration, …)
L’IR est standardisé par l’OMG.
Implementation Repository
Ce repository est spécifique à chaque
constructeur d’ORB.

CORBA::ObjectCORBA::Object
Tous les objets supportant une interface CORBA héritent implicitement de l’interface
CORBA::Object qui est standardisée.
interface ObjectObject {
ImplementationDef get_implementation ();
InterfaceDef get_interface ();
boolean is_nil();
Object duplicate ();
void release ();
boolean is_a (in string logical_type_id);
boolean non_existent();
boolean is_equivalent (in Object other_object);
unsigned long hash(in unsigned long maximum);
Status create_request (in Context ctx,
in Identifier operation,
in NVList arg_list,
inout NamedValue result,
out Request request,
in Flags req_flags
);
Policy get_policy(in PolicyType policy_type);
DomainManagersList get_domain_managers();
};

Exemple
Établir une plateforme de communication entre des courtiers en
assurances et des compagnies d’assurance.
Les courtiers peuvent disposer de matériels hétérogènes
Les assurances peuvent disposer de serveurs différents
Les assurances offrent des services communs mais peuvent aussi se
différencier en offrant des services supplémentaires.
BUS Corba
Objets: compagnies d’assurance
Objets: les courtiers
Objets: les clients des compagnies

Stub
compagnie
Zurich
ORB
Dynamic
Invocation
Stub
Assuré
ORB API
Courtier en assurances
Dynamic
Skeleton
skeleton
compagnie
AXA
ORB API
AXA Assurance ServeurAXA Assurance Serveur
Object
Adapter
ORB
Stub
compagnie
AXA
skeleton
Assuré
Exemple 1
Stub
compagnie

Dynamic
Skeleton
skeleton
Compagnie
Zurich
ORB API
Zurich Assurance ServeurZurich Assurance Serveur
Object
Adapter
skeleton
Assuré
ORB

module MediateurAssurance {
typedef string<80> T_police;
exception PasEnregistre { string motif; };
interface Assure {
readonly attribute string nom;
readonly attribute string prenom;
readonly attribute string adresse;
}
interface Compagnie {
readonly attribute string nom_compagnie;
readonly attribute string adresse;
Assure get_client(in string nom, in string prenom) raises PasEnregistre;
float eval_prime(in short bonus_malus, in short puissance);
void annule_contrat(in T_police num_police) raises PasEnregistre;
}
module AXA {
interface CompagnieAssur : Compagnie {
oneway void demande_nvelle_police (
in string nom;
in string prenom;
in string courtier;
in string adresse_client );
};
};
module ZURICH {
interface CompagnieAssur : Compagnie {
boolean demande_nvelle_police (
in string nom;
in string prenom;
in string courtier;
in string adresse_client;
in short bonus_malus );
};
};
};

P
«interface»
ZURICH_compagnie
demande_nvelle_police
«interface»
AXA_Compagnie
«oneway» demande_nvelle_police
«interface»
Compagnie
«readonly» nom
«readonly» adresse
get_client
eval_prime
annule_contrat

ORB
ORBORB
Client
IDLStub
Client
IDLStub
Client
IDLStub
Client
IDLStub
Client
IDLStub
Client
IDLStubDIIDII StubStub ORB
API
ORB
API
ClientClient
• Object
• Process
• DBMS
ClientClient
• Object
• Process
• DBMS
Client
IDLStub
Client
IDLStub
Client
IDLStubDSI
Static
Skel.
ORB
API
ServerServer
• Object
• Process
• DBMS
OA
Client
IDLStub
Client
IDLStub
Client
IDLStub
Client
IDLStub
Client
IDLStub
Client
API
ORB
API
ClientClient
• Object
• Process
• DBMS
ClientClient
• Object
• Process
• DBMS
Client
IDLStub
Client
IDLStub
Client
IDLStubDSI
Static
Skel.
ORB
API
ServerServer
• Object
• Process
• DBMS
OA
Client
IDLStub
Client
IDLStub
Client
IDLStub
Client
IDLStub
Client
IDLStub
Client
API
ORB
API
ClientClient
• Object
• Process
• DBMS
ClientClient
• Object
• Process
• DBMS
Client
IDLStub
Client
IDLStub
Client
IDLStubDSI
Static
Skel.
ORB
API
ServerServer
• Object
• Process
• DBMS
OA
ORB
ORB
Client
IDLStub
Client
IDLStub
Client
IDLStub
Client
IDLStub
Client
IDLStub
Client
API
ORB
API
ClientClient
• Object
• Process
• DBMS
ClientClient
• Object
• Process
• DBMS
Client
IDLStub
Client
IDLStub
Client
IDLStubDSI
Static
Skel.
ORB
API
ServerServer
• Object
• Process
• DBMS
OA

Stub
Compagnie
Zurich
Stub
Compagnie
Zurich
Dynamic
Invocation
Dynamic
Invocation
Stub
Assuré
Stub
Assuré
ORB APIORB API
Stub
Compagnie
AXA
Stub
Compagnie
AXA
Dynamic
Skeleton
Carte de
Visite
ORB API Object
Adapter
Agenda
Exemple 2
ORB
Application
Application

Le Bus CORBALe Bus CORBA
L’OMG définit les services rendus par le bus (ORB), paspas son implémentation.
Cela permet des solutions à des problèmes spécifiques.
Bus Processus
Le client et les objets sont dans un espace d’adressage unique (i.e. processus).
Temps de réponse minimal
Interopérabilité → portabilité (langages, OS, constructeurs)
Embedded systems: permet une meilleurs portabilité des composants sur des matériels très
spécifiques.
Bus Système d’exploitation
La communication se fait entre processus sur une même machine.
Hypothèses de simplification (format des données, erreur de transmission, …)
Gnome/Orbit (slide suivant)
Bus Serveur
Les requêtes sont adressées à un (ou plusieurs) serveur(s) qui distribue(nt) les
requêtes vers les objets distants.
Gestion centralisée du BUS (écoute, auditing, …)
Bus Réseau
Implantation la plus courante.
Orbix, Tao, Orbacus, eOrb, Mico, OpenOrb, Jacorb, Omniorb, jonathan, quelques dizaines
de distribution …

local interface ORB {
typedef string ObjectId;
typedef sequence <ObjectId> ObjectIdList;
string object_to_string (in Object obj );
Object string_to_object (in string str);
// Dynamic Invocation related operations
void create_list (in long count, out NVList new_list );
void create_operation_list (in OperationDef oper, out NVList new_list);
void get_default_context (out Context ctx);
void send_multiple_requests_oneway(in RequestSeq req);
void send_multiple_requests_deferred(in RequestSeq req);
boolean poll_next_response();
void get_next_response(out Request req);
// Service information operations
boolean get_service_information (in ServiceType service_type,
out ServiceInformation service_information);
ObjectIdList list_initial_services ();
// Initial reference operation
Object resolve_initial_references (in ObjectId identifier) raises (InvalidName);
// Thread related operations
boolean work_pending( );
void perform_work();
void run();
void shutdown(in boolean wait_for_completion);
void destroy();
// Policy related operations
Policy create_policy(in PolicyType type, in any val ) raises (PolicyError);
};

Le protocole GIOPLe protocole GIOP
L’OMG a défini un protocole générique réseau à usage général nommé GIOP.
indépendance % des couches de transport sous-jacentes
simplicité de son implémentation
spécification générique
faible coût de son utilisation (efficacité)
GIOP définit:
1. Représentation commune des données (Common Data Representation)
i.e. représentation physique des types IDL
2. Référence d’objets interopérables (IOR: Interoperable Object Reference)
représentation standardisée des références d’objets distants
3. Pré-requis sur la couche de transport
Exemple: les messages émis doivent être reçus dans le même ordre qu’à l’émission.
4. Format des messages
Exemple: appel de méthode, exception, …
GIOP peut être considéré comme un véhicule pour transporter des données qui ont été
définies avec le CDR. GIOP définit huit types de véhicules (i.e. messages).
GIOP ne définit pas l'IOR avec précision et délègue cette responsabilité aux protocoles
concrets.

A. Le format CDRA. Le format CDR
Ce format spécifie un format de données pour représenter
tous les types élémentaires IDL sous la forme d’une suite
d’octets transportables par les couches de communication.
Alignement des bytes
Ordre des bytes
CDR ne fait pas d’encodage à la source, le récepteur effectue
le décodage à la réception uniquement si son format de
données internes est différent de celui de l’émetteur.
Le nombre de conversions est donc réduit.

Exemple d’alignement
Alignment of Data Items
Developers who undertake the migration to the 64-bit operating environment will discover that a small set of issues tend to recur most
frequently, on both Win64* and Linux* platforms.
One of these is the alignment of data items – their location in memory in relation to addresses that are multiples of four, eight or 16 bytes.
Under the 16-bit Intel architecture, data alignment had little effect on performance, and its use was entirely optional. Under IA-32, aligning data
correctly can be an important optimization, although its use is still optional with a very few exceptions, where correct alignment is mandatory.
The 64-bit environment, however, imposes more-stringent requirements on data items. Misaligned objects cause program exceptions. For an
item to be aligned properly, it must fulfill the requirements imposed by 64-bit Intel architecture (discussed shortly), plus those of the linker used
to build the application.
The fundamental rule of data alignment is that the safest (and most widely supported) approach relies on what Intel terms "the natural
boundaries." Those are the ones that occur when you round up the size of a data item to the next largest size of two, four, eight or 16 bytes.
For example, a 10-byte float should be aligned on a 16-byte address, whereas 64-bit integers should be aligned to an eight-byte address.
Because this is a 64-bit architecture, pointer sizes are all eight bytes wide, and so they too should align on eight-byte boundaries.
It is recommended that all structures larger than 16 bytes align on 16-byte boundaries. In general, for the best performance, align data as
follows:
Align 8-bit data at any address
Align 16-bit data to be contained within an aligned four-byte word
Align 32-bit data so that its base address is a multiple of four
Align 64-bit data so that its base address is a multiple of eight
Align 80-bit data so that its base address is a multiple of sixteen
Align 128-bit data so that its base address is a multiple of sixteen
A 64-byte or greater data structure or array should be aligned so that its base address is a multiple of 64. Sorting data in decreasing size order
is one heuristic for assisting with natural alignment. As long as 16-byte boundaries (and cache lines) are never crossed, natural alignment is
not strictly necessary, although it is an easy way to enforce adherence to general alignment recommendations.
Aligning data correctly within structures can cause data bloat (due to the padding necessary to place fields correctly), so where necessary and
possible, it is useful to reorganize structures so that fields that require the widest alignment are first in the structure. More on solving this
problem appears in the article, "Preparing Code for the IA-64 Architecture (Code Clean).«
http://www.intel.com/cd/ids/developer/asmo-na/eng/170533.htm?prn=Y

Caractéristiques
Les valeurs IDL ont une longueur déterminée par leur type dans le flux
(size=1,2,4,8 bytes).
Big-endian ou little-endian : pas de conversion
Decimal(305 419 896)
= big-endian(0x12 0x34 0x56 0x78)
= little-endian(0x78 0x56 0x34 0x12)
little-endian: Intel,
big-endian: sparc, 68000
Les valeurs sont alignées sur des multiples de leur taille
[boolean=True, long=132, short=56, char=‘Q’, long long=234.663 ]
[0x01 0x00 0x00 0x00 0x84 0x00 0x38 0x51 0x00 0x00 0x00 0x00 0x00
0x03 0x94 0xA7]
[0 :0 :0x01 0x20 0x20 0x20
4 :4 :0x00 0x00 0x00 0x84
8 :8 :0x00 0x38
10:10:0x51 0x20 0x20 0x20 0x20 0x20
16:16:0x00 0x00 0x00 0x00 0x00 0x03 0x94 0xA7]
 Le récepteur doit connaître la nature des valeurs afin de les lire
→ typage statique
 Question: Quels avantages pourrait-on avoir si le type de chaque donnée
(et donnée agrégée) était véhiculé avec les données ?

B. Interoperable Object Request / IORB. Interoperable Object Request / IOR
1. Numéro de version du protocole transport utilisé sur le serveur
2. L'adresse du serveur resp. % au protocole spécifié ci-dessus
3. une suite d'octets identifiant l'objet sur le serveur

C. Hypothèses sur la couche transportC. Hypothèses sur la couche transport
connection-oriented
fiable
ordre des paquets respecté
pas d'erreurs dans les paquets
pas de paquets perdus
pas de paquets dupliqués
la couche transport doit pouvoir être perçue comme une suite de bytes
pas de limitation sur la taille du message transféré
impose de transférer un message de GIOP à la couche transport en un bloc contigu
en mémoire vive: exemple fichier vidéo de +Mb
GIOP 1.1 permet de fragmenter des messages GIOP, la couche GIOP est donc
capable de réassembler les sous-messages.
La couche transport doit aviser la couche supérieure d’une perte de connexion
l’entité distante ne répond pas → récupérer la connexion pour une autre entité
(polling limité de connexions)
Le mode opératoire est imposé (calqué sur le modèle TCP-IP).

D. Les messages GIOPD. Les messages GIOP
Type de message Émetteur Tag Version de GIOP
Request Client 0 1.0, 1.1, 1.2
Reply Serveur 1 1.0, 1.1, 1.2
CancelRequest Client 2 1.0, 1.1, 1.2
LocateRequest Client 3 1.0, 1.1, 1.2
LocateReply Server 4 1.0, 1.1, 1.2
CloseConnection Server 5 1.0, 1.1, 1.2
MessageError Client & Serveur 6 1.0, 1.1, 1.2
Fragment Client & Serveur 7 1.1, 1.2
Magic number GIOP Version Flags(endian;more) Tag Size
4 bytes 2 bytes 1 byte 1 byte 4 bytes
Magic number: « GIOP »
GIOP Version: exemple, version 1.2
Flags: 8 bits.
Little/big endian; more=cfr. Fragment Ce message est suivi d’un autre message
Tag: type du message
Size: taille du message
Message Header:

Request
Ce message encode les invocations
d’opération et les accesseurs. Le
message est constitué de:
IOR de l’objet distant
nom de l’opération
paramètres (in,inout)
Reply
Message envoyé par le serveur en
réponse à une requête. Ce message
contient les réponses à la requête
(paramètres out et inout) ou l’exception
si un problème est apparu lors de
l’exécution de la requête.
CancelRequest
Message envoyé par un client à un
serveur pour l’informer qu’il n’attend plus
après sa réponse.
LocateRequest
Message « blanc » envoyé à un objet
identifié par un IOR pour tester sa
validité (~ping)
LocateReply
Message envoyé en réponse à un
LocateReply par un serveur. (vrai ou
faux)
CloseConnection
Le serveur informe un client qu’il ne
répondra plus aux requêtes (en cours et
à venir). Le client ne doit donc plus
attendre après une réponse.
MessageError
Le récepteur n’a pas compris un
message précédent (mauvais magic
number, mauvaise version, erreur
interne au bus, …).
Fragment
Message utilisé pour véhiculer des
fragments d’un autre message trop
important pour la couche transport.
Si flag more=1, alors d'autres messages
du type fragment vont suivre jusqu'à ce
que flag more=0.

Request

Reply
LOCATION_FORWARD.
The server asks the client to send the request to another object. Its IOR is placed in the body
of the message.
LOCATION_FORWARD_PERM = deprecated
NEEDS_ADDRESSING_MODE
Ask the client to send the request again with another configuration (see reference manual)

Cancel & LocateRequest & LocateReply

Spécialisation de GIOP: IIOPSpécialisation de GIOP: IIOP
GIOP
TCP-IP
IIOP
...OSIIPX
IIOP: Internet Inter-ORB Protocol
Mise en œuvre du protocole GIOP
avec TCP-IP.
Une distribution CORBA conforme
doit offrir ce protocole.
D’autres protocoles existent
indépendamment de GIOP. Par
exemple, pour l’architecture DCE, le
protocole ESIOP définit un mapping
des données IDL en termes du
langage de définition de données
défini par DCE. Néanmoins, une
telle architecture doit supporter le
passage de requêtes ORB2ORB.
Référence IOR pour IIOP:
numéro de version IIOP
adresse IP de la machine
(symbolique ou #. #. #. #)
port sur lequel le serveur écoute
identifiant de l’objet sur le serveur.

Interopérabilité entre Bus CORBAInteropérabilité entre Bus CORBA
Motivations
L’OMG définit l’interface du Bus plutôt que son implémentation.
≠ constructeurs peuvent faire des choix d’implémentations incompatibles.
Protocoles différents
≠ niveaux de sécurité (secured sockets)
Domaines : garantit la « non interopérabilité »
accroître l’autonomie d’un système en l’isolant au sein d’un ORB distinct des
autres
finance / personnel / mécanique
développement / test / production
un même ORB ou des ORB de constructeurs différents
Des passerelles sont néanmoins indispensables
Néanmoins la plupart des Bus sont intéropérables entre eux.

Inter-ORB Bridge (Half-Bridge)
même CPU (cfr. exemple)
deux CPUs avec un protocole commun
DSI DII DSI DII
Half Bridge Half Bridge
Inter-ORB protocols: GIOP & IIOP
traduction des requêtes vers un format standard et commun
I love you! Te quiero!
Bridge

L’Adaptateur d’objets: POAL’Adaptateur d’objets: POA
ORB
Client
IDLStub
Client
IDLStub
Client
IDLStub
Client
IDLStub
Client
IDLStub
Dynamic
Skeleton
Dynamic
Skeleton
Static
Skeleton
Static
Skeleton
ORB APIORB API
ServerServer
• Object
• Process
• DBMS
ServerServer
• Object
• Process
• DBMS
Object AdapterObject Adapter
Object
Adapter
Interface
Object
Adapter
Interface
L’adaptateur d’objet est le mécanisme qui
connecte une requête en utilisant la
référence d’objet qui se trouve à l’intérieur
de la requête avec le servant
(processus,programme,thread, …) qui
représente l’activité de l’objet référencé.
Le servant est l’entité qui implante une
interface décrite par le langage IDL.
Des requêtes envoyées à des objets
différents (IOR≠) peuvent être servies par
un même servant.

Fichier IDL = Collection d’interfaces
Fichier IDL
IDL2xxx
xxx=java, cpp, cobol, …
fichier STUB
dans le langage cible
fichier STUB
fichier SKELETON
fichier STUB
fichier SKELETON
Application
utilisatrice d’une interface
Application
hôte d’objets
call
MonServant
« GenServant » isa
iof
« Proxy »
fichier SKELETON
iof
produces
used by
used by
POA::Servant

RootPOA
Default servant
POA 1
Object id
Object id
Object id
Object id
Object id
Object id
Active Object Map
Default servant
Object id
Object id
Object id
Object id
Object id
Object id
Active Object Map
POA 2
Object id
Object id
Active Object Map
Default servant
Policy
Policy
Policy
ServantManager
ServantManager
POA Manager
manages

Il existe un POA remarquable: « RootPOA »
Un POA peut être le père de plusieurs POA
Un POA est responsable de Servants
Un POA associe des « object ID » à des Servants
< « DEXIA » , new BanqueImplementation(« DEXIA », « BXL ») >
< « Crédit Lyon. » , new BanqueImplementation(« LYON », « Paris ») >
Un "objet distribué" est référencé sur le serveur par la séquence des POA Ids et l’Object ID.
cette information se retrouve donc dans l’IOR !
Un POA peut posséder un ServantManager qu’il invoque lorsqu’il doit traiter une requête
contenant un Object ID auquel aucun de ses Servants n’est associé.
local Interface ServantManager {
Servant incarnate (in ObjectId oid, in POA adapter);
}
Un contexte peut être associé à chaque POA qui influence son comportement:
L’Object ID peut il être assigné automatiquement à un servant lors de son enregistrement dans le
POA par le POA ou l'utilisateur doit-il donner explicitement l'object-id (exemple: primary-key d'une
table SQL)?
Un servant peut il posséder plusieurs Object ID ?
Plusieurs Threads peuvent ils accéder au POA simultanément ?
Les Objects Ids sont ils persistants ?

Default servant

CORBA fait une distinction entre « transient IOR » et « persistent IOR » (cfr.
Lifespan policy du POA).
Transient IOR: une référence IOR est valide tant que le servant de l'autre côté est
actif. Dès que le servant est tué (panne, kill, …), l'IOR désigne un objet qui n'existe
plus!
L'exception OBJECT_NOT_EXIST est renvoyée au client.
Un magic number est généré dans l'IOR de sorte que même si l'on redémarre le serveur, il
y ait peu de chance que l'IOR désigne un nouveau servant qui n'a plus rien à voir avec
celui qui a disparu.
Persistent IOR
la période de validité de cet IOR est indépendante de la période d'activité du servant
« persistent » ne signifie pas que l'état de l'objet est persistant !
C'est au moment où l'on enregistre un objet auprès du POA que l'on précise la
nature de la référence que le POA va construire.

Le gestionnaire de POAsLe gestionnaire de POAs
Le POA Manager peut gérer
simultanément plusieurs POA dont il
contrôle l’état de traitement.
Le gestionnaire de POA possède quatre
états:
Inactif
Actif
Suspendu
Rejet
Create_POA
Discard_requests
Hold_requestsactivate
Discard_requests
activate
deactivate
deactivate
destroy
Actif. Toutes les requêtes destinées à un
POA lui sont transférées. Le POA les
empilera et les traitera selon sa "policy".
Inactif. État temporaire avant la destruction
d’un POA. Les requêtes sont rejetées.
Suspendu. Empile les requêtes dans une
file d’attente du POA cible.
Rejet. Toutes les requêtes sont rejetées en
masse.

@ Vincent Englebert - UNamur 63@jacorb

Les servants sont créés à la volée et
placés dans la table du POA. Ils
pourront être désalloués par la suite
(opération deactivate du POAManager
par exemple)

Les servants sont créés à la volée
mais à la seule fin d’exécuter une
et une seule requête.
preinvoke est appelé pour créer le
servant, postinvoke est invoqué
pour libérer le servant.
La définition des ces deux
opérations sont à charge du
programmeur

Cette architecture permet de
De gérer des objets persistants
le ServantManager peut charger une donnée d’une BD et associer un nouveau
servant.
D’avoir des politiques différentes dans un même serveur
persistant/éphémère
single thread/multi thread
transactionnel ou non
...
Quelques cas d’utilisation:
Activation explicite du servant pour chaque objet
Un seul servant pour tous les objets.
Tous les objets ont le même type
exemple Ligne SQL
module purement fonctionnel (i.e. sans état)
Le même servant traite des requêtes destinées à des objets implémentant des
interfaces différentes.
Activation à la demande pour la durée d’exécution d’une méthode
stateless object (fonctionnalité sans état, exemple: factorielle(n) )

Procédure de déploiementProcédure de déploiement
module Business {
interface Compte;
interface Banque {
Compte creer_compte(in string Nom);
void ajout_interet(in Compte cpt);
};
interface Compte {
readonly attribute string Nom;
attribute string Adresse;
readonly attribute long Solde;
void credit(in long somme);
void debit(in long somme);
};
};
Business.idl
banque

import java.io.*;
import Business.*;
public class Serveur {
private static void printReference(String reference){
try {
FileOutputStream file=new FileOutputStream("ObjectId");
PrintStream pfile=new PrintStream(file);
pfile.println(reference);
file.close();
}
catch (IOException ex){
System.out.println("Impossible de creer le fichier ObjectID");
}
}
public static void main (String args[]){
try {
org.omg.CORBA.ORB orb=org.omg.CORBA.ORB.init(args,null);
org.omg.CORBA.Object objetPOA=orb.resolve_initial_references("RootPOA");
org.omg.PortableServer.POA rootPOA=org.omg.PortableServer.POAHelper.narrow(objetPOA);
BanqueImpl banque=new BanqueImpl();
byte[] objectId=rootPOA.activate_object(banque);
org.omg.CORBA.Object obj=rootPOA.id_to_reference(objectId);
String reference=orb.object_to_string(obj);
printReference(reference);
rootPOA.the_POAManager().activate();
System.out.println("Le serveur est pret...");
orb.run();
}
catch (org.omg.CORBA.ORBPackage.InvalidName e){...}
catch (org.omg.PortableServer.POAPackage.WrongPolicy e){...}
catch (org.omg.PortableServer.POAPackage.ObjectNotActive e){...}
catch (Exception e){...}
}
}
Serveur.java

public class CompteImpl extends Business.ComptePOA {
private String nom;
private int solde;
private String adresse;
CompteImpl (String nom){
this.nom=nom;
solde=0;
adresse="<adresse inconnue>";
}
// Nom read attribute
public java.lang.String Nom () {return nom; }
// Adresse read attribute
public java.lang.String Adresse () {return adresse; }
// Adresse write attribute
public void Adresse( java.lang.String value ) { adresse=value; }
// Solde read attribute
public int Solde (){return solde; }
// Operation credit
public void credit (int somme) {solde=solde+somme; }
// Operation debit
public void debit (int somme) {solde=solde-somme; }
}
CompteImpl.java

//
// Interface implementation definition : Banque
//
public class BanqueImpl extends Business.BanquePOA {
private final static float taux= (float) 1.04;
// Operation creer_compte
public Business.Compte creer_compte (java.lang.String Nom) {
try {
CompteImpl cpt=new CompteImpl(Nom);
byte[] id=_poa().activate_object(cpt);
Object obj=_poa().id_to_reference(id);
return Business.CompteHelper.narrow(obj);
}
catch (Exception e){
e.printStackTrace();
System.exit(0);
}
return null;
}
// Operation ajout_interet
public void ajout_interet (Business.Compte cpt) {
try {
cpt.credit((int)(cpt.Solde()*taux-cpt.Solde()));
}
System.exit(0);
}
}
}
défini par le mapping IDL-Java

//
// Interface implementation definition : Banque
//
public class BanqueImpl extends Business.BanquePOA {
private final static float taux= (float) 1.04;
// Operation creer_compte
public Business.Compte creer_compte (java.lang.String Nom) {
try {
CompteImpl cpt=new CompteImpl(Nom);
byte[] id=_poa().activate_object(cpt);
Object obj=_poa().id_to_reference(id);
return Business.CompteHelper.narrow(obj);
}
System.exit(0);
}
return null;
}
// Operation ajout_interet
public void ajout_interet (Business.Compte cpt) {
try {
org.omg.PortableServer.Servant servant=_poa().reference_to_servant(cpt);
CompteImpl compte=(CompteImpl)servant;
compte.credit((int)(compte.Solde()*taux-compte.Solde()));
}
System.exit(0);
}
}
}
BanqueImpl.java
défini par le mapping IDL-Java
optimisation, différence entre référence
interopérable et objet local

import java.io.*;
import Business.*;
public class Client {
/** Creates new Client */
public Client() { }
private static String getReference(){
try {
FileInputStream file=new FileInputStream("ObjectId");
InputStreamReader input=new InputStreamReader(file);
BufferedReader reader=new BufferedReader(input);
return reader.readLine();
}
catch (IOException e){ e.printStackTrace(); }
return "";
}
public static void main (String args[]) {
try {
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args,null);
String reference=getReference();
org.omg.CORBA.Object object=orb.string_to_object(reference);
Business.Banque banque=Business.BanqueHelper.narrow(object);
Business.Compte compte=banque.creer_compte("Englebert");
compte.credit(100);
banque.ajout_interet(compte);
System.out.println(compte.Solde());
}
catch (Exception e){ e.printStackTrace(); }
}
}
Client.java

Passage par valeur en Corba.Passage par valeur en Corba.
Par défaut, les objets corba sont passés par adresse à l'exception des valeurs
élémentaires (string, long, …). Néanmoins, il est possible de passer des « objets » par
valeur depuis CORBA 3.0.
Généralement, le passage des arguments est une caractéristique des paramètres des
opérations. Exemple:
C++: void f(Client c, Facture& f);
Pascal: procedure f(c: Client; var f: Facture)
En Corba, cette caractéristique est attachée au type et non à l'argument. Exemple:
IDL: void f(Client c,FactureValue f)
Les types qui sont passés par valeur sont des « valuetypevaluetype » (en lieu et place de
« interfaceinterface »).

idl2java
valuetype Bouchon {
private long code;
private Emetteur emetteur;
public string route;
public string heure;
public string commentaire;
void confirmer(in string commentaire);
void dementir(in string commentaire);
factory initialiser(in long code, in Emetteur emetteur, in string route,
in string heure, in string commentaire);
};
abstract class Bouchon {
attributes & operations
}
interface CORBA.portable.StreamableValue
interface BouchonValueFactory{
bouchon initialiser(…)
interface CORBA.portable.ValueFactory
implements extends

public interface ValueFactory {
java.io.Serializable read_value(org.omg.CORBA.portable.InputStream stream);
};
public class ValueFactoryExample implements org.omg.CORBA.portable.ValueFactory {
/**
* This function is used by the ORB to unmarshal a value type.
*
* We need to create a new value type and call the _read value of
* this value type to unmarshal it.
*/
public java.io.Serializable read_value( org.omg.CORBA.portable.InputStream is ) {
// 1. We create a new value type
MessageValueImpl value = new MessageValueImpl();
// 2. Now, we unmarshal this value
((org.omg.CORBA_2_3.portable.InputStream)is).read_value( ( java.io.Serializable ) value );
// 3. Then, we return the unmarshalled value
return value;
}
}

abstract class Bouchon {
attributes & operations
}
interface CORBA.portable.StreamableValue
interface BouchonValueFactory{
bouchon initialiser(…)
interface CORBA.portable.ValueFactory
implements extends
class RtbfBouchon {
// définition des opérations
}
class RtbfBouchonFactory {
// définition de bouchon initialiser(…):
bouchon initialiser(args … ){
…
return new RtbfBouchon(…);
}
extends implements

interface Emetteur {
void confirmer(in long code, in string commentaire);
void dementir(in long code, in string commentaire);
Bouchon get_info();
};
RtbfEmetteur
emetteur_BXL
RtbfBouchonFactory
fabrique_SPA007
AdvCarSyst
autoradio
RtbfBouchon
copy of n7
1. get_info()
2.initialiser(10,this,
«N7»,«18:05»,«
»)
3.new
4. return n7
5. confirmer(« 2H attente »)RtbfBouchon
n7
6.confirm
er(10,«
2H
attente
»)

Serveur Factory Client Factory
x:avaluetype
init
requête
x':avaluetype
ORB
t:repository Id(avaluetype); m:CDR(x)
m
? quel est le factory de t
x'

mode dynamique
L'héritage est étendu aux value types et aux interfaces indifféremment:
hérite de interface value type
interface plusieurs non
value type non 1
Un value type peut "supporter" une interface.
le value type doit définir toutes les opérations spécifiées dans l'interface
par un mécanisme de délégation, on peut mettre en œuvre un mode de passage par valeur et
par adresse pour un même objet.

interface Exemple {
void print();
}
valuetype ExempleVal supports Exemple {
void printLocal();
}
interface ExempleVal extends Exemple
class ExempleImpl implements Exemple {
private Exemple clone;
ExempleImpl(Exemple autre){
clone=autre;
}
public void print(){
clone.print();
}
}
interface Exemple
idl2java
idl2java
class ExempleValImpl implements ExempleVal {
public void print(){
System.out.println("Je suis içi");
}
}
implements
extends
implements
les relations d'héritage et d'implémentation ontles relations d'héritage et d'implémentation ont
été simplifiées pour des raisons d'ordreété simplifiées pour des raisons d'ordre
pédagogiques et peuvent nepédagogiques et peuvent ne
pas respecter les règles officielles de mapping.pas respecter les règles officielles de mapping.
Lorsqu'un client demande un résultat,
le serveur peut décider de le lui renvoyer
par valeur ou par adresse selon le contexte.

interface ExempleVal extends Exemple
class ExempleImpl implements Exemple {
}
interface Exemple
class ExempleValImpl implements ExempleVal {
}
implements
extends
implements
reference
par valeurpar valeurpar valeurpar valeurpar valeur
par référencepar référencepar référencepar référence

le passage par valeur permet de « délocaliser » des appels d'opération.
Ainsi des appels (client-serveur) deviennent (client-client).
Le passage par valeur implique que l'argument est à l'abri de toute
modification qui serait opérée sur le site d’origine de l’objet.
le passage par valeur/adresse est déterminé par le type des arguments et
non par le mode des paramètres.
les factories d'objets peuvent être distincts d'un hôte à un autre.
Le passage par valeur permet de mettre en œuvre des politiques avancées
de gestion comme:
Transformation d'invocations (client-serveur) en invocation (client-client) avec
post-synchronisation.
diminution du nombre de requêtes distantes
Permet d'améliorer l'indépendance d'un client vis-à-vis des objets distants en
cas de faible QoS du réseau ou du serveur
bornes touristiques
hôtes mobiles
communications orientées connexion (modem)

Le repository d'interfacesLe repository d'interfaces

CORBA::ObjectCORBA::Object
Tous les objets supportant une interface CORBA héritent implicitement de l’interface
CORBA::Object qui est standardisée.
pseudo interface ObjectObject {
ImplementationDef get_implementation ();
InterfaceDef get_interface ();
boolean is_nil();
Object duplicate ();
void release ();
boolean is_a (in string logical_type_id);
boolean non_existent();
boolean is_equivalent (in Object other_object);
unsigned long hash(in unsigned long maximum);
Status create_request (in Context ctx,
in Identifier operation,
in NVList arg_list,
inout NamedValue result,
out Request request,
in Flags req_flags
);
Policy get_policy(in PolicyType policy_type);
DomainManagersList get_domain_managers();
};

Le repository d'interfaces contient une description des interfaces,
modules, … définis dans le système. Chaque fois qu'un nouveau type
de composant est inséré dans le système, le repository d'interfaces
doit être mis à jour afin de pouvoir le décrire.
Il en est de même lorsque l'on met à jour la définition d'un composant.
Exemple:
interface Client {
attribute string name;
};
interface Client {
attribute string address;
};
chaque interface du repository est étiqueté d'un numéro de version
« IDL:MediateurAssurance/AXA/AXA_compagnie:1.1 » (repository Id)
Le repository d'interfaces contient une version de chaque interface.
Des composants de « même type » peuvent donc coexister dans le
système tout en ayant des versions d'interface différentes.
Le système peut donc évoluer en douceur

interface Client {
};
interface Client {
attribute string address;
};
ORB
« IDL:.../AXA_compagnie:1.0 » « IDL:.../AXA_compagnie:1.1 »

Localisation d’Objets DistribuésLocalisation d’Objets Distribués
Inventaire des objets distribués [QUOI/OÙ]: « répertoire ».
Accroître la transparence de la localisation des différents composants.
Le répertoire des objets distribués de CORBA est lui-même un objet
distribué qui propose ses services à d’autres objets distribués.
Afin de structurer et d’optimiser les accès au bottin, les objets sont
arrangés en hiérarchie.
DollarAndCo
Banque
Assurance
Prêt
Compte
Courant
Dépôt
gestion
gestion
CalculInteret
incendie
vol

module CosNaming {
typedef string Istring;
struct NameComponent { Istring id; Istring kind; };
typedef sequence <NameComponent> Name;
enum BindingType {nobject, ncontext};
struct Binding {
Name binding_name;
BindingType binding_type;
};
typedef sequence <Binding> BindingList;
interface BindingIterator;
interface NamingContext {
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{};
void bind(in Name n, in Object obj) raises(NotFound, CannotProceed, InvalidName, AlreadyBound);
void rebind(in Name n, in Object obj)raises(NotFound, CannotProceed, InvalidName);
void bind_context(in Name n, in NamingContext nc) raises(NotFound, CannotProceed, InvalidName, AlreadyBound);
void rebind_context(in Name n, in NamingContext nc) raises(NotFound, CannotProceed, InvalidName);
Object resolve (in Name n) raises(NotFound, CannotProceed, InvalidName);
void unbind(in Name n) raises(NotFound, CannotProceed, InvalidName);
NamingContext new_context();
NamingContext bind_new_context(in Name n) raises(NotFound, AlreadyBound, CannotProceed, InvalidName);
void destroy( ) raises(NotEmpty);
void list (in unsigned long how_many,out BindingList bl, out BindingIterator bi);
};
interface BindingIterator {
boolean next_one(out Binding b);
boolean next_n(in unsigned long how_many, out BindingList bl);
void destroy();
};
};

high availability !
stable 
accès fréquents et
cruciaux , mais les
données peuvent être
cachées

Techniques de résolution
Résolution récursive (Corba Naming Service)
Object resolve(in Name n)
Contexte.resolve(<c1,c2,…,cn>)=(Contexte.resolve(<c1>)).resolve(<c2,…, cn>)
void bind (in Name n, in Object id)
Contexte.Bind(<c1,c2,…,cn>,object)=Contexte.resolve(<c1,…,cn-1>).bind(<cn>,object)
Mais aussi
rebind
unbind
list(…)
@tanenbaum

Techniques de résolution
Résolution itérative
Object resolve(in Name n)
Contexte.resolve(<c1,c2,…,cn>)
NamingContext current=Contexte;
for (string S in <c1,c2,…,cn-1>) do {
current=current.resolve( S);
}
return current.resolve(cn) ;
@tanenbaum

Comparaison
Itérative
 les serveurs sont moins chargés
- (mais) plus de gestion sur le client
le client doit posséder du code spécifique
(librairie) pour itérer sur les serveurs
- le client doit pouvoir accéder à plusieurs
serveurs
pas de problème sur un intranet
avec des firewalls, il peut être difficile de
joindre des serveurs que l'on découvre
dynamiquement.
- la seule façon de l'optimiser est
d'installer un cache sur le client. Mais on
a un cache pour chaque client
- utiliser un serveur de nom proxy qui
factorisera et cachera les requêtes
- problème des incohérences: comment
distinguer les noms stables et les noms
instables
- les communications se font toujours
client ↔ serveur, a priori sur de longues
distances.
Récursive
- la méthode récursive surcharge les
serveurs
un serveur est responsable de résoudre
C1
il est aussi responsable de la résolution
de <C2,…,CN>
les serveurs dans la couche globale ne
peuvent pas supporter la charge induite
par la méthode récursive
 le client ne discute qu'avec un seul
serveur de noms
 plus élégante
la résolution incombe complètement au
serveur de nom
le serveur sert de façade à une
complexité arbitraire
 les messages échangés sont de proches
en proches (on peut l'espérer)
@tanenbaum

résolution récursive de <nl,vu,cs,ftp>
avec caching et résultats étendus
@tanenbaum
information stockée dans le répertoire avant la mise en cache

Les répertoires fournis dans les packages ne sont généralement pas prévus pour gérer
de grandes quantités d’information
Répertorier les « grands » composants: oui
répertorier les clients (i.e. dupont) d’une banque: certainement pas.
 Un répertoire n’est pas conçu pour remplacer une base de données classique
Les services d’un répertoire sont assez simples: possibilité d’implémenter son propre
service de répertoire compatible avec l’interface CORBA au dessus de SQL par
exemple.
Le répertoire est un composant vital, colonne vertébrale du système :
tolérant aux pannes
persistant
efficace
Il est probable que les clients feront de nombreux accès au répertoire:
rapprocher le répertoire des clients (même réseau, même machine)
multiplier les répertoires
par domaine (assurance,banque,gestion, …)
Il est important de gérer l’information du répertoire
conventions, guidelines, consensus, … sur les règles de nommage
Le répertoire permet de délocaliser un composant:
< banque.assurance, objet_namur >  < banque.assurance, objet_BXL >
De par son rôle crucial, le répertoire est une donnée sensible sur le plan de la sécurité
rien n’est prévu dans CORBA sur ce plan (cfr. service de sécurité)
qui peut modifier, qui peut consulter, ...

L’ORB offre une opération pour obtenir le répertoire principal (root)
module CORBA {
interface ORB {
[…]
typedef string ObjectId;
typedef sequence <ObjectId> ObjectIdList;
exception InvalidName{};
ObjectIdList list_initial_services();
Object resolve_initial_references( in ObjectId identifier) raises(InvalidName);
};
};
Mais comment l’ORB peut-il connaître l’adresse du naming service ?

Référencer un IOR sous format textuel
URL Corba:
CORBALOC
corbaloc://{[version du protocole @ ] nom de machine [ :numéro de port ]}/ clef de l'objet
{ } plusieurs fois ♦ [ ] optionel ♦ protocole par défaut: 1.0 ♦ port par défaut: 9999
Si plusieurs adresses, l'objet doit se trouver sur l'une des adresses (séparées par un ;)
Exemple:corbaloc://iiop:1.2@fiatlux.info.UNamur.ac.be:4315/NameService
IOR
Représentation hexadécimale de l'IOR.
IOR: suite de bytes
IOR:000000000000001849444C3A427573696E6573732F42616E7175653A312E300000000001000000000000006C00
01020000000019666961746C75782E696E666F2E66756E64702E61632E626500000E4200000014004F4F0120B87FB7
E8000000504F41FEE27CF18A00000001000000010000002400000000100204E400000003000100010001000F000100
20000101090000000100010100
CORBANAME
référence un objet par son entrée dans un Naming Service (indirection…)
Exemple: corbaname:iiop:1.2@fiatlux.info.UNamur.ac.be:4315/universite.UNamur/GestionInscriptions
Autres
ftp: , http: , file: fichier où se trouve un IOR

Négociations de servicesNégociations de services
Le concept de répertoire offre une description très statique et très
simple du domaine applicatif.
Le concept de trading permet de répondre à des questions plus
complexes sur la localisation de composants distribués
Principe
Fournisseur Négociateur Demandeur
Je peux imprimer
Qui peut imprimer ?
Imprime !
Naming=Pages Blanches; Trading=Pages jaunes

Un trader décrit un (des) objet en terme d’un ensemble de services
qu’il peut rendre.
Exemple: service impression {
interface Imprimante;
mandatory readonly property string Type;
mandatory property boolean is_busy;
readonly property boolean is_fast;
property long quality;
property long cost_per_page;
};
Les services sont représentés par une interface que l’objet fournisseur supporte.
Les services sont décrits par des attributs
mandatory/optional
Cette propriété n’est pas obligatoire pour décrire le service
readonly or not
Le fournisseur peut modifier a postériori la valeur de cette propriété.
Le négociateur doit consulter le fournisseur chaque fois qu’il souhaite connaître la valeur de cette propriété
Le demandeur interroge le négociateur afin d’obtenir la référence d’un fournisseur qui répond à sa demande.

interface ImprimanteMatricielle;
Type=« matricielle »;
is_busy=true;
is_fast=true;
quality=5;
cost_per_page=1;
interface ImprimanteHPCL
Type=« InkJet »;
is_busy=false;
is_fast=false;
quality=8;
cost_per_page=3;
impression
Query: not is_busy and quality>=4
pref: min cost_per_page
Hergé GregFranquin
interface ImprimantePS
Type=« PS »;
is_busy=false;
is_fast=true;
quality=10;
cost_per_page=1;
[ Franquin, Greg ]

Fédération de tradersFédération de traders
QUERY
Local/if_no_local/always
Local/if_no_local/always
Les traders peuvent s’organiser
en communauté pour répondre à
une question.
Le trader délègue la requête
auprès d’autres traders et
fusionne les résultats avant de
les présenter au demandeur.
Les liens sont orientés et seul le
trader origine connaît le trader
cible du lien.
Problème de circularité dans
l’émission de la requête:
réponses multiples
non-terminaison
Configuration dynamique
Configuration transitive
Disposition optimale des traders
efficacité
par domaine
proximité géographique
département / thème
couverture exhaustive des
domaines par fédération

interface
CosTrading::ImportAttributes
+def_search_card:unsigned long
+max_search_card:unsigned long
+def_match_card:unsigned long
+max_match_card:unsigned long
+def_return_card:unsigned long
+max_return_card:unsigned long
+max_list:unsigned long
+def_hop_count:unsigned long
+max_hop_count:unsigned long
+def_follow_policy:FollowOption
+max_follow_policy:FollowOption
enum
CosTrading::FollowOption
local_only:
if_no_local:
always:
interface
CosTrading::SupportAttributes
+supports_modifiable_properties:boolean
+supports_dynamic_properties:boolean
+supports_proxy_offers:boolean
+type_repos:TypeRepository
exception
CosTrading::PropertyTypeMism...
type:ServiceTypeName
prop:Property
struct
CosTrading::Property
name:PropertyName
value:PropertyValue
interface
CosTrading::Link
+add_link:void
+remove_link:void
+describe_link:LinkInfo
+list_links:LinkNameSeq
+modify_link:void
LinkInfo
IllegalLinkName
UnknownLinkName
DuplicateLinkName
DefaultFollowTooPermissive
LimitingFollowTooPermissive
interface
CosTrading::Register
+export:OfferId
+withdraw:void
+describe:OfferInfo
+modify:void
+withdraw_using_constraint:void
+resolve:Register
OfferInfo
InvalidObjectRef
UnknownPropertyName
InterfaceTypeMismatch
ProxyOfferId
MandatoryProperty
ReadonlyProperty
NoMatchingOffers
IllegalTraderName
UnknownTraderName
RegisterNotSupported
interface
CosTrading::Proxy
+export_proxy:OfferId
+withdraw_proxy:void
+describe_proxy:ProxyInfo
ProxyInfo
IllegalRecipe
NotProxyOfferId
interface
CosTrading::Lookup
+query:void
HowManyProps
SpecifiedProps
IllegalPreference
IllegalPolicyName
PolicyTypeMismatch
InvalidPolicyValue
interface
CosTrading::LinkAttributes
+max_link_follow_policy:FollowOption
interface
CosTrading::Admin
+request_id_stem:OctetSeq
+set_def_search_card:unsigned long
+set_max_search_card:unsigned long
+set_def_match_card:unsigned long
+set_max_match_card:unsigned long
+set_def_return_card:unsigned long
+set_max_return_card:unsigned long
+set_max_list:unsigned long
+set_supports_modifiable_properties:boolean
+set_supports_dynamic_properties:boolean
+set_supports_proxy_offers:boolean
+set_def_hop_count:unsigned long
+set_max_hop_count:unsigned long
+set_def_follow_policy:FollowOption
+set_max_follow_policy:FollowOption
+set_max_link_follow_policy:FollowOption
+set_type_repos:TypeRepository
+set_request_id_stem:OctetSeq
+list_offers:void
+list_proxies:void
interface
CosTrading::OfferIdIterator
+max_left:unsigned long
+next_n:boolean
+destroy:void
interface
CosTrading::OfferIterator
+max_left:unsigned long
+next_n:boolean
+destroy:void
interface
CosTradingDynamic::DynamicPropEval
+evalDP:any
interface
CosTradingRepos::ServiceTypeRepository
+incarnation:IncarnationNumber
+add_type:IncarnationNumber
+remove_type:void
+list_types:ServiceTypeNameSeq
+describe_type:TypeStruct
+fully_describe_type:TypeStruct
+mask_type:void
+unmask_type:void
PropertyMode
PropStruct
IncarnationNumber
TypeStruct
ListOption
SpecifiedServiceTypes
ServiceTypeExists
InterfaceTypeMismatch
HasSubTypes
AlreadyMasked
NotMasked
ValueTypeRedefinition
DuplicateServiceTypeName
interface
CosTrading::TraderComponents
+lookup_if:Lookup
+register_if:Register
+link_if:Link
+proxy_if:Proxy
+admin_if:Admin

Questions
Trouvez des applications qui pourraient bénéficier du support du
trading service.
Comparez ce service à la norme UDDI dans le domaine des web-
services
http://www.uddi.org

Gestion du cycle de vie (création)Gestion du cycle de vie (création)
Dans un langage de programmation:
customer=new Customer(« dupont »);
Mais ces instructions retournent une référence ou une adresse spécifique à l’espace
mémoire du client.
Customer=create_Customer(123.32.56.12:2345, « dupont » )
transparence de la localisation ?
Solution:
expliciter le mécanisme de création par un objet dédié: la fabrique (factory)

Tentative 1
:Client
c:Compte
fc:FabriqueCompte:Naming
Resolve(« FabriqueCompte »
fc
Create_compte(« dupont »)
New Compte(« dupont »)
c
Il y a une fabrique par hôte
La fabrique doit créer l’objet et l’enregistrer (POA, Naming, …)
S’il y a plusieurs fabriques pour un même type d’objet, le client doit lui-même
lever l’ambiguïté en faisant un choix de localisation.

Tentative 2
:Client
c:Compte
fc:FabriqueCompte:Naming
resolve(« FactoryFinder »
ff
find_factory(« compte »)
new Compte(« dupont »)
ff:FactoryFinder
fc
create_compte(« dupont »)
c

La localisation des objets nécessaires à la création d’objets distribués
est maintenant cachée de l’entité cliente.
La fabrique peut être configurée dynamiquement par les
administrateurs
:Client
c:Compte
fc1:FabriqueCompte fc2:FabriqueCompte
find_factory(« compte »)
new Compte...
ff:FactoryFinder
if condition then fc1 else fc2
create_compte(« dupont »
c

Gestion du cycle de vie (destruction)Gestion du cycle de vie (destruction)
Détruire un objet distribué signifie
supprimer l’objet de l’espace d’adressage (comme un objet local)
le désinscrire du POA
maintenir les contraintes référentielles:
registry/répertoire
Trading services
tout autre objet qui référencerait cet objet.
Supprimer un type d’objet distribué T signifie
supprimer les instances de T (cfr. ci-dessus)
supprimer toutes les « fabriques » qui créent des objets de type T
supprimer les types des fabriques concernées (si l’on peut)
supprimer T du repository d’interfaces
supprimer les informations sur T dans le repository d’implémentations.

Localisation des objets mobilesLocalisation des objets mobiles

Problème
Soit C un composant qui peut migrer d'une machine à une autre.
Identifier ce composant par une référence liée à la localisation
physique du composant ne convient pas
Exemple: Adresse IP et port !
Comment faire ?
En plus d'être identifiant, la référence d'un composant devrait être stable
dans le temps!
L'IOR n'est donc pas un bon identifiant.

Application 1 Application 2
Solution 1. Chaîne de Proxy.
proxy C
Client
+ Le client conserve sa référence, transparence ok
+ Simple
- la chaîne peut être longue si l'objet migre souvent  performance
- chaque élément en plus est une cause d'échec supplémentaire

s
s
foo’: actif
ortho: servants, suspendus
foo’

Solution 2. Correction du client
Corriger l'information du client
Client
BA
FOO:
foo
REQUEST( IORfooA , …)
REQUEST( IORfooB , …)
IORfooA
→ IORfooB
POA POA
LOCATION_FORWARD( IORfooA → IORfooB )
en régime, les requêtes arrivent directement sur le
composant
si le composant se déplace souvent, la correction
initiale de la référence peut prendre du temps

A
a →B, b →B,c →B
B
a →E, b →E, c → E
C D
E
a → I, b → I, c → J
F G H
I
a → 1, b → 2
J
c → 98
L MK
b
IP2:
IP1:
a
IP98:
c
Solution 3. Mécanisme d'indirection distribué

A
B
a →E, b →E, c → E
C D
E
a → I, b → I, c → J
F G H
I
a → 1, b → 2
J
c → 98
L MK
b
IP2:
IP1:
a
IP98:
c
IP200:
c
B
a →E, b →E, c →F
F
c→K
K
c→200
1:insert(c,ip200)
2:insert(c,K)
3:insert(c,F)
déplacé versdéplacé vers

A
B
a →E, b →E, c → E
C D
E
a → I, b → I, c → J
F G H
I
a → 1, b → 2
J
c → 98
L MK
b
IP2:
IP1:
a
IP98: IP200:
cc
E
a → I,b →I
B
a →E, b →E, c →F
F
c→K
K
c→200
J
4:nomore(c,ip98)
5:nomore(c,J)
6:nomore(c,E)

A
B
a →E, b →E, c → E
C D
E
a → I, b → I, c → J
F G H
I
a → 1, b → 2
J
c → 98
L MK
b
IP2:
IP1:
a
IP98:
c
IP200:
c
B
a →E, b →E, c →F
F
c→K
K
c→200
Quel est le problème ?
Dans quelles circonstances,
cette situation peut elle
être tolérée?

Exercices
Si pour un raison quelconque, l'ordinateur hébergeant un nœud de
l'arbre doit être éteint, quelles sont les solutions envisageables
si la durée d'indisponibilité est très courte
si la durée d'indisponibilité est très longue
Proposer une architecture en Corba permettant de mettre en œuvre ce
principe
définissez votre propre concept d'identifiant/adresse
quels sont les types de composant dont vous aurez besoin
écrivez le fichier IDL correspondant
quelle architecture OO va-t-on mettre en place localement pour faire face ?

Limitations
On doit en permanence parcourir l'arbre pour retrouver l'adresse d'une entité
Introduire du caching.
si le composant migre en
dehors de son "super domaine"
stable, il faut remettre tous les
caches à jour
Exercice:
si l'on utilise les "transient
IORs" de corba, doit on
corriger les caches ?
si non, quelle est l'efficacité
de cette approche ?
dans quels contextes cette
stratégie peut-elle être efficace ?
Scalabilité: La racine peut devenir un point névralgique du système
Taille: Stocker les références de nombreux composants
1 Million de composants  1Ko = 1 Teraoctet = 10 disques de 100Giga
Charge: de nombreux lookup et update !
organiser le nœud root en cluster ou sur un ordinateur plus puissant (parallèle)
le problème de la charge du réseau persiste !
organiser le nœud en plusieurs sous nœuds répartis géographiquement.

Gestion des référencesGestion des références

Introduction
À partir du moment où l'on peut référencer des entités distantes (IOR
par exemple), à partir de quelles conditions peut on détruire une entité
qui est potentiellement référencée ailleurs ?
Hypothèses
Un applicatif qui détient une référence sur un objet distant peut passer
cette référence à d'autres applications et ainsi de suite.
À tout moment, une application peut ne plus avoir besoin d'une référence.
Un programme ne peut accéder un objet distant que si il détient une
référence vers cet objet.
Par facilité, ceci est aussi valable pour l'application qui héberge l'objet lui-
même.
Un objet qui n'est plus référencé de cette sorte est devenu inutile.
Remarque:
des objets peuvent être référencés et être pour autant inutiles: gestion des
cycles:
référenceréférenceréférenceréférence
objet distribuéobjet distribuéobjet distribuéobjet distribué

La gestion des références avec des objets locaux
Principe du Mark & Sweep
98.2928
'a'
123
toto
1
1
1
1
1
1
2
2
2
2
2
2
2
2
2
3
3
3
Magic NumberMagic NumberMagic NumberMagic Number Quel est l’intérêt du magic number par
rapport à un drapeau booléen dans les
objets ?

Comptage de référence
Idée: le skeleton maintient un compteur avec le nombre de stubs dans
le système distribué qui le référencent.
Principe:
Chaque stub demande au skeleton d'incrémenter le compteur
le skeleton confirme l'incrément
le stub peut être utilisé
(idem pour une suppression de référence)
Problèmes:
si un hôte utilisateur tombe en panne, un objet ne pourra plus jamais être
libéré.
problème dans la synchronisation des messages
problème de « race concurrence » entre incrément et décrément.

Problème de synchronisation
Il faut détecter la perte de messages
Il faut détecter la réplication de messages
Pourquoi ne pas utiliser une communication synchrone tout simplement ?
@tanenbaum2002

Problème de race concurrence
Race concurrence
P1 passe une référence à P2
P1 informe le skeleton de la suppression de son stub
P2 tarde à informer le skeleton de cette nouvelle référence
Correction
se mettre dans les conditions d'une transaction
P2 ne peut utiliser un stub que lorsque le skeleton a confirmé qu'il connaissait bien l'emplacement de cette nouvelle référence.
Hypothèse supplémentaire !
la communication est fiable
pas de perte
messages ordonnés
pas de duplication
Inconvénients:
L'objet O est concerné par trois messages suite à une "transaction" effectuée entre P1 et P2 a priori indépendante du "business" de
l'objet O.
problèmes de passage à l’échelle.
@tanenbaum2002
+1

Technique Weight Watcher
Un poids est assigné à chaque objet distribué
Lorsqu'un stub est associé à un skeleton, on confie une partie du poids du skeleton au stub.
@tanenbaum2002

Question
Que se passe t il avec ce type de programme ?
Soit X une référence vers O

exécuter X.opération
envoyer X à P2
détruire la référence X
attendre X de P2
goto 
P1

attendre une référence Y
exécuter Y.opération
envoyer Y à P1
détruire la référence Y
attendre Y de P1
goto
P2

Amélioration du weight watcher avec des chaînes
lorsque le poids local d'un stub devient 1, le processus ne peut plus engendrer de
nouvelles références à partir de son stub
régénérer un compteur en créant un skeleton frais qui jouera le rôle de proxy vis-à-vis
des nouveaux demandeurs de référence vers l'objet.
Inconvénients
indirection supplémentaire
fragilité de la chaîne
longueur de la chaîne
@tanenbaum2002

Gestion avec une liste des référents
plutôt que maintenir un simple compteur, l'idée est de maintenir une liste des processus qui
référencent l'objet distribué.
Chaque object aura une liste L de processus qui le référencent
Comme les opérations add et remove sont idempotentes, elle peuvent être répétées sans affecter
l'état de l'objet.
un processus peut donc invoquer ces opérations dans une boucle jusqu'à avoir un acknowledgment de l'objet.
Lorsqu'un process P1 passe son stub à un autre process P2, P2 doit faire un add sur l'objet
Problème de race concurrence ???
Si P1 parvient à faire un remove avant que P2 ne fasse un add, l'objet pourrait être détruit.
utiliser le même principe que dans le comptage de référence !
Avantages
ce protocole convient pour des infrastructures où le réseau n'est pas fiable:
résistance aux pannes
pas besoin de gérer la réplication
possibilité de résister aux pannes des processus: le skeleton peut vérifier l'état des processus utilisateurs.
Désavantages:
la liste des références peut-être longue
changer la sémantique: un processus n'obtient une référence que pour une certaine durée, au-delà le
skeleton est autorisé à casser le lien à moins que le processus n'ait confirmé à nouveau sa détention
d'une référence pour une nouvelle période.
interface DistributedObject {
void add(in Processus p);
/* L := L union { p } */
void remove(in Processus p);
/* L := L minus { p } */
}

Garbage collector distribué
Gestion des références cycliques
Le problème des références cycliques n'est pas géré par les
mécanismes de comptage de références
Idée: étendre le principe du Mark & Sweep au système distribué
Difficulté: il faut stopper le système distribué dans un état valide durant
l'exécution de l'algorithme!
cette hypothèse n'est pas réaliste dans la plupart des cas !

Cours Middleware orientés objets

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Cours Middleware orientés objets

Similaire à Cours Middleware orientés objets (20)

Cours Middleware orientés objets

Notes de l'éditeur