Middleware Plan: Middleware / CORBA 1 Lionel Seinturier Middleware / CORBA 2 Lionel Seinturier

Middleware Plan
1. Introduction
2. Architecture
Le bus logiciel CORBA
3. Langage IDL
4. Développement Java
Lionel Seinturier
5. Développement C/C++
Université Pierre & Marie Curie 6. Services
7. Concepts avancés
8. Le futur de CORBA
9. Bibliographie
Middleware / CORBA 1 Lionel Seinturier Middleware / CORBA 2 Lionel Seinturier
1. Introduction 1.1 Motivations

Quelques définitions Objets : entités identifiés qui fournissent des services
- distribués : peuvant être accédés à distance au travers d’un réseau
- hétèrogènes : proviennent de langages et de systèmes ≠
• CORBA : Common Object Request Broker Architecture
Motivations pour CORBA
• ORB ou «bus logiciel» : fournit une infrastructure de
commununication pour des objets hétérogènes et • construire un environnement dont les spécifications sont standardisées
distribués • s’affranchir des solutions purement propriétaires
• offrir une plate-forme multi-systèmes et multi-langages
(analogie avec le bus hardware)
Motivations pour l’approche objet
ORB
• l’application modèlise directement des objets «réels» du domaine
• obtenir une architecture logicielle claire et simple
Objet Objet Objet Objet
serveur BD
• avoir une conception modulaire
imprimeur annuaire courtier
(les détails d’implentation internes sont masqués)

1.2 Principes de base 1.2 Principes de base
Principes fondamentaux de CORBA Définitions (suite)
• Transparence à la localisation • interface : ensemble des opérations et des attributs d’un objet
• Transparence d’accès • implantation : «code» associé aux opérations
• Séparation des interfaces et des implantations • localisation : machine physique sur laquelle réside l’objet
• référence : structure (≈ pointeur) permettant d’accéder à l’objet
• Interfaces typées
• Support de l’héritage multiples d’interfaces
Ö Notion fondamentale de CORBA : l’interface

- l’utilisation d’un service est orthogonal à sa localisation • définie dans un langage dédié (IDL : Interface Definiton Language)
- les services sont accédés en invoquant des opérations sur des objets • contrat entre le client et le serveur
- les clients dépendent des interfaces, pas des implantations • définit de façon exhaustive les services que le serveur offre au client
- les références d’objet sont typées par les interfaces
- l’héritage permet d’étendre, de faire évoluer et de spécialiser les services
2. Architecture 2.1 Consortium OMG
2.1 Consortium OMG Object Management Group http://www.omg.org
2.2 Modèle OMA • Groupe de vendeurs de matériel, de système, d’applications, de conseils, ...
• ≈ 700 membres (Sunsoft, HP, Compag, IBM, Iona, Alcatel, ...)
2.3 Vue générale de CORBA • Produit des spécifications
2.4 Côté client • OMA (Object Management Architecture)
architecture générale pour la gestion d’objets distribués
2.5 Côté serveur
• CORBA
2.6 Référence d’objet un des composants de l’OMA
permet aux objets distribués de communiquer
2.7 Adapteur d’objet
1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000
2.8 Protocole d’invocation de méthodes
11 membres 390 Définition des services
2.9 Fournisseurs d’ORBs CORBA 1.1 membres
OMA v1 200 membres CORBA 2.0 2.2 CORBA2.3 3.0 ?

2.1 Consortium OMG 2.2 Modèle OMA
Fonctionnement du consortium Application Objets Domain Interfaces Common Facilities

Dist. Appl. Info. Task.
Appel d’offre (RFP : Request For Proposal) O1 O2
simul. dev. mgmt. mgmt
• quand un besoin apparaît, l’OMG émet une RFP
User System
• la RFP définit les objectifs de cette nouvelle spécification O3 O4 Manuf. Account. interf. mgmt
• un échéancier est associé à cette RFP
Proposition Object Request Broker (ORB)

• tous les membres intéressés peuvent soumettre une proposition
• une proposition ne peut être acceptée que si un prototype
Naming Event Concur. Relation. Query Time Collect. Persist.
d’implantation est fourni
• les propositions soumises sont révisées jusqu’à ce qu’il n’y en
Lifecycle Transac. Security External. Licensing Trading Propert.
ait plus qu’une seule
• une fois la proposition acceptée, ces auteurs doivent fournir
l’implantantation finale dans l’année Common Object Services
2.2 Modèle OMA 2.2 Modèle OMA

• Bus logiciel (ORB : Object Request Broker)
Les services communs
infrastructure de communication de l’OMA
• abstractions de fonctionalités système courantes (nommage, transaction, ...)
CORBA: spécifications de l’ORB
• indépendants du domaine d’applications
• Services (COS : Common Object Services ou CORBAServices) • 15 services spécifiés actuellement
«librairies» (classes) de services systèmes de base • rassemblés selon leur importance
COSS : spécifications des COS
COS sets 1 & 2 COS sets 3, 4 & 5
• Facilités (Common Facilities ou CORBAFacilities)
«frameworks» logiciels pour des traitements courants - nommage - requête
- événement - gestion de licence
• Interfaces de domaines (Domain Interfaces) - cycle de vie - propriétés
«frameworks» logiciels spécialisés pour des domaines d’activités - persistance - sécurité
- transaction - temps
• Objets d’application (Application Objects)
- concurrence - courtage
applications mises en place par les développeurs
- relation - collection
- externalisation

2.2 Modèle OMA 2.2 Modèle OMA
Les «facilités» communes Les interfaces de domaine
• «frameworks» logiciels de plus hauts niveaux que les services • «frameworks» logiciels de plus hauts niveaux que les services
• indépendantes du domaine d’applications • spécialisées pour un domaine d’applications particulier
• également appelées facilités horizontales • également appelées facilités verticales
• 4 facilités • 8 interfaces de domaine
Common Facilities - imagerie Domain Interfaces

- interface utilisateur Info. Task. - autoroute de l’information
Dist. Appl.
- gestion de l’information mgmt. mgmt - simulation distribuée simul. dev.
- gestion du système - comptabilité
User System
- gestion des tâches interf. mgmt
- industrie pétrolière Manuf. Account.
- construction
- ...
2.3 Vue générale de CORBA 2.3 Vue générale de CORBA

Client Serveur param. entrée Int
Client Obj opération erf. Serveur
Smalltalk
Smalltalk
ref IDL
Cobol
Cobol
param. sortie + retour

C++
C++
Java
Java
Ada
Ada
C
Squelette Squelette
Interface IDL statique dynamique
Souche Souche
statique dynamique Primitives Adaptateur d’objets
Souche Squelette de l’ORB
Noyau de l’ORB
Object Request Broker (ORB)
Référentiel Référentiel
Vocabulaire : souche, squelette, talon sont ici synonymes d’interfaces d’implantation
Ö entités qui préparent et gèrent les appels entre clients et serveurs

2.3 Vue générale de CORBA 2.4 Côté client
Le noyau de l’ORB (ORB core) Souche

Client
• gère la localisation des objets dans l’environnement • prépare les paramètres d’entrée de l’invocation
• implante les protocoles de communication entre objets • décode les paramètres de sortie et le résultat
• accessible au travers d’un ensemble de primitives
Souche Souche
statique dynamique
Le référentiel d’interfaces (Interface Repository) Souche statique
Noyau de l’ORB
• base de données des interfaces des objets serveurs • une par type d’objet serveur à invoquer
• une par environnement (groupement logique de machines) • identique aux souches clientes RPC
• possibilité de fédérer les référentiels de différents environnements • générée à la compilation à partir de l’interface IDL
Le référentiel d’implantation (Implementation Repository) Souche dynamique

• base de données sur les implantations des objets serveurs
• une sur chaque site accueillant des objets serveurs • souche générique construisant dynamiquement tout type de requêtes
• permet d’invoquer des objets serveurs que l’on découvre à l’exécution
(i.e. dont on ne connaît pas l’interface à la compilation)
2.5 Côté serveur 2.5 Côté serveur
Squelette
Serveur Squelette statique Serveur
• symétrique de la souche
• décode les paramètres d’entrée des invocations • un par type d’objet serveur invoquable
Squelette Squelette Squelette Squelette
• prépare les paramètres de sortie et le résultat statique dynamique
• identique aux souches serveurs RPC statique dynamique
Adaptateur d’objets
• généré à la compilation à partir de l’interface IDL Adaptateur d’objets
Noyau de l’ORB Noyau de l’ORB

Squelette dynamique
• réceptacle pour les objets serveurs
• interface entre les objets serveurs et l’ORB • squelette générique prenant en compte dynamiquement tout type de requêtes
• gère l’instantiation des objets serveurs • permet de créer à l’exécution des classes d’objets serveurs
• crée les références d’objets (i.e. que l’on ne connaissait pas à la compilation)
• aiguille les invocations de méthodes vers les objets serveurs
• plusieurs adapteurs (≠ ou identiques) peuvent cohabiter sur une même machine
dans des espaces d’adressage ≠

2.6 Référence d’objet 2.7 Adaptateur d’objet
Référence d’objets (IOR: Interoperable Object Reference)
Différents types d’adaptateurs d’objets
information permettant d’identifier de manière unique et non ambiguë
tout objet dans un ORB • les plus courants : BOA (Basic OA) et POA (Portable OA)
• se différencient par la façon dont ils
Type de l’objet Adresse réseau Clé de l’objet - instancient les objets
- aiguillent les requêtes
Type de l’objet : permet de différencier des types d’objets ≠
- activent les objets
Adresse réseau : adresse IP et numéro de port
acceptant des invocations de méthodes pour cet objet
Clé de l’objet : identité de l’adaptateur sur ce site et
de l’objet sur cet adaptateur Le BOA
• le plus simple
IDL:monObjet:1.0 milo.jussieu.fr:1805 OA7, obj_979 • propose 4 modes d’activation des objets
IOR:000000000000001c49444c3a43616c63756c6174726963652f43616c63756c3a312e30000000000300000000000000330001000000
00000e3133322e3232372e36342e3430000b4e00000017383135313337313834312f00114d4d4d4d4d0e4d390d23000000000000000038
000101000000000e3133322e3232372e36342e3430000b4e00000017383135313337313834312f00114d4d4d4d4d0e4d390d2300000000
00000000010000002c0000000000000001000000010000001c00000000050100010000000100010001000101090000000105010001
2.7 Adaptateur d’objet 2.8 Protocole d’invocation de méthodes

BOA pour serveur partagé BOA pour serveur non partagé
Modes d’invocation de méthodes
O1 O2 O3 O1 O2 O3
Client Serveur Client Serveur Client Serveur
1. Synchrone 2. Asynchrone 3. Semi-synchrone

BOA BOA (synchronous) (asynchronous) (deferred synchronous)
BOA avec serveur par méthode BOA avec serveur persistant Rq: 3 n’est pas disponible avec un talon statique
O1 O2 O3 O1 O2 O3
Sémantique
Ordonnanceur
1 et 3 : «au plus une fois»
2 : «au mieux» (la réception du message n’est pas garantie)
BOA BOA

2.8 Protocole d’invocation de méthodes 2.9 Fournisseurs d’ORBs
GIOP (General Inter-Orb Protocol) Commerciaux
• ORBIX IONA www.iona.com
Protocole comprenant 7 messages pour assurer les communications entre objets • VisiBroker Inprise www.inprise.com/visibroker/
Request invocation d’une méthode (C) • ORBacus OOC www.ooc.com
Reply réponse à une invocation (C) • DSOM IBM www.software.ibm.com/ad/som/
CancelRequest annulation d’une invocation (C)
LocateRequest localisation d’un objet (C) Gratuits
LocateReply réponse de localisation (S) • MICO Univ. Francfort www.mico.org
CloseConnection fermeture de connexion (S) • JacORB Univ. Berlin www.inf.fu-berlin.de/~brose/jacorb/
MessageError signalisation de message erronné (S/C) • OmniORB 2 AT&T www.uk.research.att.com/omniORB/
Fragment fragmentation de messages (S/C) • TAO Univ. Washington www.cs.wustl.edu/~schmidt/TAO.html
• GIOP nécessite un protocole de transport fiable, orienté connexion De nombreux autres sont disponibles
• IIOP (Internet IOP) : implantation de GIOP au-dessus de TCP
voir www.vex.net/~ben/corba/
• Autres implantations de GIOP au-dessus de HTTP, RPC DCE, RPC Sun
ou www.cetus-links.org à la rubrique CORBA
• Associé à un format de d’encodage des données (CDR)
3. Langage IDL 3.1 Introduction

IDL (Interface Definition Language)
3.1 Introduction
• Langage de définition des services proposés par un objet
3.2 Conventions syntaxiques • Une interface comprend les opérations et les attributs d’un objet
• Langage déclaratif (i.e. l’implantation ne se fait pas à ce niveau)
3.3 Types de données
• Mapping : correspondance entre IDL et un langage de programmation
3.4 Constantes - 6 mappings normalisés OMG (C, C++, Java, Ada, Cobol, Smalltalk)
- d’autres + exotiques existent (Tcl, Perl, CLOS, Eiffel, Python, Modula)
3.5 Exceptions
3.6 Modules De nombreux autres IDLs existent :
OSI ASN.1, SNMP SMI, Sun ONC XDR, DCE IDL, Microsoft IDL
3.7 Interfaces
IDL de CORBA
3.8 Résumé • orienté objet
• supporte l’héritage
• dedié à la programmation distribuée

3.1 Introduction 3.2 Conventions syntaxiques
Structure d’un fichier IDL • Proche de la syntaxe C++
• Commentaires /* */ ou //
<types> typedef string Tadresse; • Identificateurs : séquence de caractères alphabétiques, chiffres ou _
<constantes> const Tadresse adresseJussieu = «...»; (doivent commencer par un caractère alphabétique)
<exceptions> exception jourFerie {}; • La casse des identificateurs n’est pas déternimante
<modules> module DESSISI { attribute long age; et attribute long Age; sont considérés
<interfaces> interface Etudiant { comme une redéfinition du même attribut
<attributs> attribute long age; • Néanmoins, toutes les références à un identificateur doivent respecter
<operations> boolean present( in long jour ) la casse de sa définition. typedef float CoordX; devra être utilisé CoordX
raises jourFerie;
}
} • Mots clés IDL
any enum Object struct
attribute exception octet switch
• Les modules peuvent être emboîtés les uns dans les autres boolean FALSE oneway TRUE
• Les types, constantes, exceptions peuvent être déclarés à ≠ niveaux
case float out typedef
char in raises union
(globalement, localement à un module, localement à une interface) const inout readonly unsigned
context interface sequence voif
default long short wchar
double module string wstring
3.2 Conventions syntaxiques 3.3 Types de données

Types de base et construits Exemple
Différences / à la syntaxe C++ • short, unsigned short (2 octets)
- un identificateur doit être fourni pour chaque paramètre d’une opération • long, unsigned long (4 octets) typedef long age;
- une liste de paramètres avec seulement le toker void ne peut pas être • long long, uns. long long (8) struct personne {
utilisé pour indiquer une liste vide • float (4 octets) string nom;
- les types entiers ne peuvent pas être déclarés comme des int • double (8), long double (16) long age;
ou des unsigned. Il faut préciser short ou long. • boolean (TRUE, FALSE) };
- les caractères ne peuvent pas être associés aux modificateurs • octet (1 octet, transmis tel quel) enum couleur {rouge, vert, bleu};
signed ou unsigned. • char (1 octet, ISO Latin 1)
• wchar (2 octets, Unicode) union carre switch(couleur) {
Préprocesseur • void (type vide) case rouge: short num;
default: char n;
- identique à celui de C/C++ };
- substitution de macros (#define) • struct (structures)
- compilation conditionnelle (#ifdef et #ifndef) • enum (énumération) string <16> chaine;
• union (type discriminé) string nom;
- inclusion de sources (#include)
- directives de compilation (#pragma) • string, wstring (chaînes)
sequence <long> vecteur;
• sequence (tableau) sequence <float,8> tableau;
• any (type indifférencié)
3.4 Constantes 3.5 Exceptions
Des variables typées dont la valeur est fixe Des structures de données qui signalent une situation exceptionnelle
const <type> <ident> = <expr>; • définies par le programmeur

• levées par le système
Types autorisés pour les constantes
• long, unsigned long
• short, unsigned short Exceptions spécifiées par l’utilisateur Quelques exceptions système
Exemple
• long long, unsigned long long
exception <ident> { <donnée>* }; OBJECT_NOT_EXIST
• float, double, long double const long max = 255; BAD_PARAM
• boolean COMM_FAILURE
const long taille = 8; Exemple
• char, wchar const long segments = 1024/taille;
NO_MEMORY
• string INV_OBJREF
exception overflow { ...
const string usage = «Hello»; float limit;
Opérateurs autorisés };
• unaires + - ~
long exp( in float x )
• binaires + - * / % << >> & | ^ raises(overflow);
3.6 Modules 3.7 Interfaces

Des conteneurs de définitions Les points d’accès aux objets CORBA
(identiques aux interfaces Java ou aux classes abstraites C++)
Peuvent contenir : types, constantes, exceptions, interfaces, modules
Ö hiérarchies de modules permettent de structurer les applications • Peuvent contenir : types, constantes, exceptions, attributs, opérations
• Peuvent hériter leur structure d’une ou +sieurs autres interfaces
module <ident> { ... };
• Peuvent être prédéclarées en vue d’une utilisation ultérieure
Exemple interface <ident> : <heritage> { ... };
module mesAnimaux {
...
Exemple
module alaVille { ... };
module alaCampagne { ... }; interface Carre : Parallelepipede { ... };
...
}; interface A; // prédéclarée (le compilateur «sait» que
// l’ident. A est associé à une interface
interface B { ... }; // utilise A
Toutes les définitions d’un module sont «visibles» grace à l’opérateur interface A { ... }; // utilise B
de résolution de portée ::
Ex : mesAnimaux::alaVille::...

3.7 Interfaces 3.7 Interfaces
Opérations
Attributs
• Prennent des paramètres et retournent un résultat
• Les variables publiques des interfaces (i.e. accessibles par tous les clients)
• Passage par référence pour les objets, par valeur pour tous les autres
• Peuvent être lus ou écrits par les clients (sauf si déclarés readonly)
• in : entrée inout : entrée/sortie out : sortie
• Chaque attribut est associé à 2 méthodes (appelées setter/getter)
• Peuvent lever une ou +sieurs exceptions
permettant de le lire et de l’écrire (seulement setter pour readonly)
oneway <type retour> <ident> ( <liste paramètres> )
attribute <type> <ident>; raises( <exceptions> ) context( <ident> );
readonly attribute <type> <ident>;
float op1( in short x, out long y ) raises(depassement);
IDL Langage de programmation
• Peuvent être déclarée asynchrone (oneway)
attribute float rayon; float rayon();
void rayon( float value ); pas de paramètres de retour, ni inout, ni out, pas d’exception
oneway void op2( in long x );
readonly attribute long age; int age();
• Contexte d’exécution (≈ variables d’environnement d’un shell)
informations mises à la disposition du serveur par le client

Héritage d’interfaces Héritage d’interfaces (suite)
Simple Redéfinitions : règle de la «liaison au plus tôt» (early binding)
interface ouvrier : employe { ... }; Une sous-interface

• peut redéfinir les types, constantes, exceptions d’une super-interface
Multiple • ne peut pas redéfinir les attributs, les opérations
Ö éviter qu’un même nom ne soit associé à 2 traitements ≠
interface ouvrier : employe, personne { ... };
interface A { Le mécanisme de liaison au plus

• L’ordre de déclaration des interfaces n’a pas d’importance const long L = 3; tôt garantit que la signature
• Une sous-interface hérite de tous les éléments de sa ou ses super-interfaces void f( in sequence<float,L> s );
de C::f est
• Une sous-interface peut ajouter de nouveaux éléments };
• Possibilité d’héritage «en losange» ( A←B A←C B,C←D ) interface B { const long L = 4; }
interface C : B, A {} void f(
in sequence<float,3> s );
Il aurait certainement été + simple d’interdire toute redéfinition

3.8 Résumé 4. Développement Java
IDL : langage de définition des interfaces des objets CORBA
Interface = attributs + opérations 4.1 Principe

4.2 Types de base (traduction IDL vers Java)
Différences entre IDL et des langages comme C++ ou Java
4.3 Types construits (traduction IDL vers Java)
• Pas de code • Modes de passage de paramètres 4.4 Interfaces (traduction IDL vers Java)
• Pas de pointeur • Sémantique d’appel oneway
• Pas de constructeur • Attributs readonly
4.5 Implantation des interfaces
• Pas de destructeur • Type sequence 4.6 Programme serveur
• Pas de surcharge • Unions nécessitent un discriminant
d’opérations 4.7 Programme client
• Pas de polymorphisme
4.1 Principe 4.2 Types de base

Développement d’une application client/serveur CORBA/Java L’étape 2 nécessite de connaître la traduction (mapping) Java des éléments IDL
1. Ecrire en IDL les interfaces des objets serveurs Types de base

2. Implanter en Java ces interfaces
3. Ecrire le programme Java qui instancie les objets serveurs IDL Java
4. Ecrire le programme Java qui réalise les appels des objets serveurs [unsigned] short short
[unsigned] long int
4 1 2 3
[unsigned] long long long
Prog. Interface Prog. float float
Implantation
client IDL serveur double double
char, wchar char
string, wstring java.lang.String
Souche générés par Squelette boolean boolean
le compilateur
statique de langage IDL statique octet byte
any org.omg.CORBA.Any
void void
Noyau de l’ORB long double non supporté

4.3 Types construits 4.3 Types construits
Types construits
Cas spéciaux (struct, enum, union)
IDL Java
module package Ö une classe de nom identique à celui du type déclaré est créée
interface interface
attribute méthodes setter/getter
opération méthode Java IDL Java
enum Couleur { public final class Couleur {
struct, enum, union classes Java rouge, public static int _rouge = 0;
sequence tableau Java vert, public static int _vert = 1;
const static final bleu public static int _bleu = 2;
}
exception sous-classe de
public Couleur(int);
java.lang.Exception public int value();
}
Rq : les constructions IDL qui n’ont pas d’équivalent en Java

sont traduites par des classes

Pour chaque interface IDL, le traducteur IDL vers Java génère
Exemple de correspondance IDL - Java
• une interface Java <interface>
• une classe pour le squelette _<interface>ImplBase
IDL Java
• une classe pour la souche StubFor<interface>
module M { package M;
interface I { interface I { • une classe dite Helper <interface>Helper

long meth( in long arg ) int meth( int arg ) • une classe dite Holder <interface>Holder
raises (e); throws e;
attribute float a; float a();

void a( float value ); La classe <interface>Helper permet de
readonly
attribute double d; double b(); • lire et écrire des objets implantant cette interface dans un flux
} } • convertir un objet CORBA vers le type représenté par cette interface
exception e { ... } class e
• insérer et extraire un objet implantant cette interface dans un objet de
} extends Java.lang.Exception type Any
{ ... } • les classes Helper existent également pour les types simples (IntHelper, ...)

<interface>Holder gère les modes de passage inout et out Les classes Holder existent également pour les types simples (IntHolder, ...)
#1 final public class IntHolder {

public int value;
maCl obj = new maCl(); class autreCl {
public IntHolder() {}
autreCl appel = new autreCl(); void uneMeth(maCl param) {
public IntHolder ( int initial ) {
appel.uneMeth(obj); param = new maCl();
value = initial;
System.out.println(obj); } }
#2 }
}
en Java : #1
avec la sémantique inout, on voudrait que obj vaille #2 (même pb pour out) Exemple de traduction IDL - Java
IDL Java
Ö Solution : des classes conteneurs (dite holder)
interface I { interface I {
void meth( inout long arg ); int meth( IntHolder arg );
class Holder { maCl value; } class autreCl { } }
Holder hold = new Holder(); void uneMeth(Holder param) {
hold.value = new maCl(); param.value = new maCl();
appel.uneMeth(hold); } }
Le programmeur lit et écrit
l’entier arg.value
4.5 Implantation des interfaces 4.5 Implantation des interfaces

2 2 Implantation
1ère approche : héritage 2ème approche : délégation
Interface Class ... Class
Implantation Interface tie impl
IDL
La classe d’implantation hérite du squelette Inconvénient de l’approche précédente IDL
l’héritage simple de Java limite les
Exemple généré par Squelette possibilités de réutilisation
le compilateur généré par Squelette
de langage IDL statique le compilateur
Interface IDL Solution : une classe (dite tie) délègue de langage IDL statique
module M {
l’implantation à une autre classe
interface Interf {
void ping();
} } Exemple
Avantage
InterfImpl peut hériter
Implantation Java par héritage Implantation Java par délégation d’une autre classe
package M; package M;
class InterfImpl extends _InterfImplBase { class InterfImpl implements InterfOperations {
void ping() { System.out.println(«ping reçu»); } void ping() { System.out.println(«ping reçu»); }
} }

4.6 Programme serveur 4.6 Programme serveur
3 3
Mise en service des objets serveurs Mise en service des objets serveurs
Prog. Implantation Prog.
Implantation
1. Initialiser l’ORB et le BOA serveur 1. Initialiser l’ORB et le BOA serveur
2. Instancier les objets serveurs 2. Instancier les objets serveurs
3. Publier leur référence 3. Publier leur référence
4. Les lancer 4. Les lancer
Cas de l’implantation par délégation
Cas de l’implantation par héritage
package M;
package M; class InterfImpl implements InterfOperations {
class InterfImpl implements InterfOperations { void ping() { System.out.println(«ping reçu»); }
void ping() { System.out.println(«ping reçu»); } public static void main(String[] args) {
public static void main(String[] args) { 1. ORB orb = ORB.init(args,null);
1. ORB orb = ORB.init(args,null); BOA boa = orb.BOA_init();
BOA boa = orb.BOA_init(); 2. InterfImpl test = new InterfImpl();
2. InterfImpl test = new InterfImpl(); Interf skel = new _tie_Interf(test);
3. ns.bind(test,«objetTest»); /* ns = name server */ 3. ns.bind(skel,«objetTest»);
4. boa.impl_is_ready(); 4. boa.impl_is_ready();
} } } }
4.7 Programme client 5. Développement C++

4
Appel des objets serveurs
Prog. 5.1 Types de base (traduction IDL vers C++)
client
1. Initialiser l’ORB côté client
2. Rechercher les objets serveurs 5.2 Types construits (traduction IDL vers C++)
3. Les invoquer Souche 5.3 Interfaces (traduction IDL vers C++)
statique
5.4 Implantation des interfaces
class client {
public static void main(String[] args) {
1. ORB orb = ORB.init(args,null);
5.5 Programme serveur
2. CORBA.Object o = ns.resolve(«objetTest»);
Interf obj = InterfHelper.narrow(o); 5.6 Programme client
3. obj.ping();
} } 5.7 A propos du développement en C

5.1 Types de base 5.2 Types construits
Développement d’une application client/serveur CORBA/C++ Types construits
Même étapes que pour le développement CORBA/Java IDL C++

module, interface class (*)
Types de base IDL C++

attribute méthodes setter/getter
[unsigned] short CORBA::Short [UShort]
opération méthode C++
[unsigned] long CORBA::Long [ULong]
En C++, la taille [unsigned] long long CORBA::LongLong
struct, enum, union struct, enum, union
d’un int, float, ... float CORBA::Float
sequence classe C++
varie selon les double CORBA::Double
const static const
compilateurs char, wchar CORBA::Char, WChar
exception sous-classe d’une
string, wstring CORBA::String, WString
classe Exception
Ö les définitions long double CORBA::LongDouble
CORBA::... boolean CORBA::Boolean
masquent ces ≠ octet CORBA::Octet
any CORBA::Any (*) : si disponible, utilisation du mot-clé C++ namespace pour les modules
void void
5.3 Interfaces 5.4 Implantation des interfaces

2
IDL C++
module M { class M_I { La classe d’implantation hérite
Interface
interface I { CORBA::Long meth( du squelette Implantation
long meth( in long arg ); CORBA::Long arg );
IDL
attribute float a; CORBA::Float a();
readonly void a(CORBA::Float value); Exemple
attribute double d; CORBA::Double b();
généré par Squelette
le compilateur
} } } de langage IDL statique
Interface IDL
module M {
interface Interf {
Pour chaque interface IDL, le traducteur IDL vers C++ génère void ping();
} }
• une classe C++ <interface>
• un type <interface>_var
• un type <interface>_ptr Implantation C++
class M_InterfImpl: M_sk_Interf {
void ping() { cout << «ping reçu» << nl; }
• <interface>_var : objet de type <interface> (alloc. mem. automatiques) }
• <interface>_ptr : référence à un objet de type <interface>

5.5 Programme serveur 5.6 Programme client
3 4
Mise en service des objets serveurs
Prog. Appel des objets serveurs
Implantation Prog.
1. Initialiser l’ORB et le BOA serveur client
1. Initialiser l’ORB côté client
2. Instancier les objets serveurs
2. Rechercher les objets serveurs
3. Publier leur référence
3. Les invoquer Souche
4. Les lancer
statique
int main( int argc, char *argv[] ) {

1. CORBA::ORB_ptr orb = CORBA::ORB_init(argc,argv); int main( int argc, char *argv[] ) {
CORBA::BOA_ptr boa = orb->BOA_init(argc,argv); 1. CORBA::ORB_ptr orb = CORBA::ORB_init(argc,argv);
2. M_InterfImpl test = new M_InterfImpl(); 2. CORBA::Object o = ns->resolve(«objetTest»);
3. ns->bind(test,«objetTest»); M_Interf obj = M_Interf_narrow(o);
4. boa->impl_is_ready(); 3. obj->ping();
} }
5.7 Développement C 6. Services

But
• permettre d’intégrer de «vieilles» applications C à un environnement CORBA

6.1 Introduction
• développer des applications CORBA light et performantes
(voir GNOME et ORBit) 6.2 Nommage
Problème : C n’est pas orienté objet 6.3 Courtage
Solution : utilisation de conventions de nommage pour tout traduire
en fonctions C et simuler un environnement OO 6.4 Evénement
6.5 Transaction
IDL C
module M { CORBA_Long M_I_meth( 6.6 Aperçu des autres services
interface I { CORBA_Long arg );
long meth( in long arg );
} }

6.1 Introduction 6.2 Nommage
Services système pour les applications CORBA Permet de localiser un objet CORBA
• ensemble d’objets serveurs remplissant des fonctions courantes • ≡ à un annuaire (pages blanches), DNS, ...
• chaque service est défini par une ou +sieurs interfaces IDL • organisé de façon hiérarchique ( ≡ hiérarchie de fichiers)
• 15 services actuellement
• chaque répertoire est appelé un «contexte de nommage»
• l’opération d’enregistrement d’un objet : une «liaison»
• l’opération de recherche d’un objet : «résolution» de nom
Object Request Broker (ORB)
root
Naming Event Concur. Relation. Query Time Collect. Persist.

Mexique Hawaii Racine
Lifecycle Transac. Security External. Licensing Trading Propert.
Contexte de nommage
....
Objet
Common Object Services Ixtapa Cancun Playa
Blanca
6.2 Nommage 6.2 Nommage

Deux façons de localiser un objet CORBA • Interfaces graphiques pour visualiser le contenu des serveurs de noms
• à partir de son nom Exemple
• en parcourant la hiérarchie
module CosNaming {
interface NamingContext {
void bind( in Name n, in Object o ); // enregistre un nom
void bind_context( in Name n, // enregistre un contexte
in NamingContext nc );
void unbind( in Name n ); // supprime un nom
Object resolve( in Name n ); // résoud un nom
void list( out BindingList bl ); // liste des noms, ctx RootContext : la racine du serveur de nom
} }
Name : le nom de l’objet
La norme prévoit que l’on puisse (en pratique ??) : Kind : une chaîne précisant le «type» de service fournit par l’objet
• fédérer les services de nommage Type : l’interface IDL implantée par l’objet
• les faire intéropérer avec d’autres annuaires (DNS, DCE CDS, OSI X500, NIS+) Host : l’adresse IP et le port servant des requêtes pour l’objet

6.3 Courtage 6.4 Evénement
Permet de rechercher un type d’objet CORBA Permet de s’abonner auprès d’objets CORBA diffuseurs
• ≡ à un annuaire de pages jaunes 2 rôles
• on recherche un objet CORBA à partir de ses fonctions • producteur d’événements ( ≡ d’information)
• utilise un courtier • consommateur d’événements (s’abonne auprès d’1 ou +sieurs producteurs)
1. le serveur s’enregistre auprès du courtier
2. le client interroge le courtier Notion de canal d’événements
3. le client invoque le serveur c1 p1
• liaison (n-m) entre producteurs et
consommateurs par laquelle transitent les évts .... Canal ....
2 courtier 1
2 modes de diffusion cn pm
• «push» : initié par le producteur
client serveur
3 • «pull» : initié par le consommateur
push pull
Rq : le service de courtage est souvent utilisé conjointement au DII prod. cons. prod. cons.
info. info.
6.5 Transaction 6.5 Transaction

Permet d’effectuer des transactions sur des objets CORBA 3 types d’acteurs
• client transactionnel
Propriétés «habituelles» des transactions (ACID) • serveur transactionnel : implante l’algorithme de validation à 2 phases
• atomicité : transac. effectuée complètement ou pas du tout • serveur de recouvrement
• cohérence : transac. préserve la cohérence des données gère les ressources (données) sur lesquelles s’effectue la transaction
• isolation : exéc. // équivalentes à exéc. séquentielles
• duralibité : résultats de la transac. persistants Interfaces
• serveur transactionnel
Algorithme de validation à 2 phases Modèle de transactions imbriquées • Current : interf. entre le client et le serveur transac.
• Coordinator : interf. entre le serveur transac. et les serveurs de recouvr.
client Transac. • serveur de recouvrement
commit/ princ.
rollback • Resource : interf. de gestion des ressources transactionnelles
serveur 1 Sous
prepare oui/non transac.
serveur 2 ... Cur serveur Coord Resso serveur
client
rent transac. inator urces recouvr.
Optimisation : valid. 1 phase lorsque 1 seul serveur

6.5 Transaction 6.6 Aperçu des autres services
Scenario de fonctionnement - Exemple 11 autres services disponibles
Débit de x frs sur le compte d’une banque A et
Crédit de x frs sur le compte d’une banque B - cycle de vie gestion de l’évolution des objets (déplacement, copie, ...)
- persistance sauvegarde de l’état des objets
client current coordinator resource resource - concurrence gestion de verrous
begin - relation gestion d’associations (E/A) entre objets
débit - externalisation mécanisme de «mise en flux» pour des objets
get_control - requête envoi de requête «à la SQL» vers des objets
register_resource - licence contrôle de l’utilisation des objets
crédit - propriétés gestion d’attributs dynamiques pour des objets
get_control - sécurité gestion sécurisée de l’accès aux objets
register_res - temps serveur de temps et synchronisation d’horloges
commit - collection gestion de groupes d’objets
prepare
commit
Rq : peu d’ORBs offrent tous ces services
banque A banque B
7. Concepts avancés 7.1 Invocation dynamique

DII : Dynamic Interface Invocation
• Permet d’invoquer des objets dont on ne connaît pas l’interface

7.1 Invocation dynamique (DII)
au moment de la compilation
7.2 Squelette dynamique (DSI) • L’interface est «découverte» à l’exécution
7.3 Intercepteurs
Les interfaces sont stockées dans le référentiel d’interfaces
7.4 Adaptateur d’objet portable (POA) • base de données des interfaces des serveurs
• une par environnement (groupement logique de machines)
• possibilité de fédérer les référentiels de ≠ environnements
• organisé de façon hiérarchique, c’est un ensemble d’éléments dont la

structure reflète celle des interfaces qui y sont stockées
• chaque éléments stocké possède un identifiant unique (global repository ID)
ex : IDL:milo/M/I:1.0

7.1 Invocation dynamique 7.1 Invocation dynamique
Référentiel d’interfaces • Interfaces graphiques pour visualiser le contenu des référentiels d’interfaces
• Référentiel d’interface ≡ objet serveur CORBA comme un autre
Exemple
Repository Exemple
|-> ConstantDef module M {
|-> TypeDef interface I {
|-> ExceptionDef long meth( in long arg );
|-> InterfaceDef } }
|-> ModuleDef
|-> ... est stockée
|-> InterfaceDef
|-> ... Repository
|-> AttributeDef |-> M
|-> OperationDef |-> I
|-> ParameterDef |-> (meth,long)
|-> ExceptionDef |-> (in,long,arg)

• Le référentiel fournit des requêtes (interrogation, maj, ...) classe mère Exemple
• Les éléments qu’il contient sont des objets qui ∈ à des classes
organisées selon une hiérarchie d’héritage classe fille
CORBA.Obj o = ... ; 1. on récupère une réf. d’obj. CORBA
InterfDef i = 2. on lui demande la descript. de son interf.
o._get_interface();
IRObject Repository
Request req = 3. on crée une requête
o._request( «meth» );
PrimitiveDef AddArg( req, 12 ); 4. on ajoute les paramètres d’appel
req.set_return_type( 5. on spécifie le type du résultat attendu
Contained Container tk_long );
IDLType req.invoke(); 6. on invoque
int ret = req.return_value(); 7. on récupère le résultat
TypeDef ExceptionDef AttributeDef ModuleDef
ConstantDef ParameterDef InterfaceDef OperationDef _get_interface interroge le référentiel pour retrouver le descr. de l’interface
invoke est bloquante tant que le résultat n’est pas disponible

Plusieurs sémantiques d’invocation possibles
Avantages
• invoke appel bloquant
• send_oneway appel asynchrone (oneway)
• il n’est pas nécessaire de connaître les interfaces à la compilation
• send_deferred appel non bloquant
• plus flexible que l’invocation statique
• poll_response teste la présence de la réponse
• sémantiques d’invocations plus riches
• get_response récupère la réponse
• permet de manipuler les contextes d’exécutions des clients
• send_multiple_request_oneway envoi +sieurs requêtes oneway
• send_multiple_request_deferred envoi non bloquant de +sieurs requêtes Inconvénients
• poll_next_response teste la présence d’une réponse
• get_next_response récupère une réponse • plus difficile à manipuler
• pas de vérification de type
• plus lent
7.2 Squelette dynamique 7.3 Intercepteurs

DSI : Dynamic Skeleton Interface Intercepteurs
• Fournit un squelette générique pour les objets serveurs dont on ne connaît pas • Mécanisme permettant d’intercepter et de modifier les communications
l’interface au moment de la compilation • 2 niveaux d’interceptions : requête et message
• Equivalent côté serveur du DII • Permet d’implanter de façon transparente : filtrage, sécurité, audit, ...
Idée du fonctionnement
Squelette Squelette
• on implante une classe et une méthode qui aiguille les appels entrants
statique dynamique
• cette méthode travaille sur des objets request identiques à ceux du DII Souche Souche
statique dynamique Intercepteur requêtes
Avantages Inconvénients
Intercepteur requêtes Adaptateur d’objets
• plus flexible • plus difficile à manipuler
• interface langages de script (Perl, ...) • pas de vérification de type Intercepteur messages Intercepteur messages
• ponts génériques entre ORB et • plus lent Noyau de l’ORB
autres systèmes (DCE, DCOM, ...)

7.3 Intercepteurs 7.3 Intercepteurs
Intercepteurs de requêtes Intercepteurs de messages
• Permet d’intercepter les requêtes (appels de méthodes) • Permet d’intercepter les messages IIOP échangés par l’ORB
• Les requêtes sont manipulées comme des requêtes DII • Une requête ne correspond pas nécessairement à un seul message
• On peut ajouter des pré et post actions à la requête • Ne s’appliquent qu’aux invocations distantes
• On peut changer le destinataire de la requête
• Peuvent s’appliquer aux invocations locales et distantes
Interface de l’intercepteur de messages
Interface de l’intercepteur de requêtes interface MessageInterceptor: Interceptor

{
void send_message( in Message mess, Object target );
interface RequestInterceptor: Interceptor
void receive_message(in Message mess, Object target );
{
}
void client_invoke( inout Request req );
void target_invoke( inout Request req );
}
7.4 Adaptateur d’objet portable 8. Le futur de CORBA

POA : Portable Object Adapter
¾ CORBA 3.0 (prévue en 2000 ?)
• réceptacle pour les objets serveurs Communication en mode message (MOM : Message-Oriented Middleware)
• interface entre les objets serveurs et l’ORB • communication par boîtes à lettres + souple que le deferred synchronous
• gère l’instantiation des objets serveurs • 2 modèles : callback et pooling
• crée les références d’objets
• aiguille les invocations de méthodes vers les objets serveurs Qualité de service (QoS : Quality of Service)
• plusieurs adapteurs (≠ ou identiques) peuvent cohabiter sur une même machine • permet d’indiquer la QoS voulue en terme de priorité des messages
Depuis CORBA 2.2, le POA remplace le BOA Passage d’objet par valeur
• référence d’objet persistante • permettre le passage d’objets par valeur plutôt que par référence
• meilleure gestion des threads
• +sieurs références possibles pour le même objet ¾ RFP Tolérance aux fautes
• activation implicite des serveurs à partir du référentiel d’implantation ¾ RFP Temps réel
• possibilité d’avoir +sieurs POA dans un même espace d’adressage
• meilleure intégration avec le service de persistance

9. Bibliographie
• J.M. Geib, C. Gransart, P. Merle, CORBA: des concepts à la pratique, InterEditions, 1997
• R. Orfali, D. Harkey, J. Edwards, Instant CORBA, Wiley, 1996
• J. Siegel, CORBA Fundamentals and Programming, Wiley, 1996
• T. Mowbray, R. Zahavi, The Essential CORBA, Wiley, 1995
• OMG, The Common Object Request Broker: Architecture and Specification,

version 2.3, Décembre 1998. http://www.omg.org
• S. Vinoski, New Features for CORBA 3.0, Communications of the ACM,

41(10):44-52, Octobre 1998
Middleware / CORBA 89 Lionel Seinturier

Langue

Bienvenue sur Scribd !

Middleware Plan: Middleware / CORBA 1 Lionel Seinturier Middleware / CORBA 2 Lionel Seinturier

Transféré par

Informations du document

Date du transfert

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Description :

Droits d'auteur :

Formats disponibles

Middleware Plan: Middleware / CORBA 1 Lionel Seinturier Middleware / CORBA 2 Lionel Seinturier

Titre original :

Transféré par

Description :

Droits d'auteur :

Formats disponibles

Titres liés

Middleware Plan

Middleware / CORBA 1 Lionel Seinturier Middleware / CORBA 2 Lionel Seinturier

1. Introduction 1.1 Motivations

Middleware / CORBA 3 Lionel Seinturier Middleware / CORBA 4 Lionel Seinturier

Ö Notion fondamentale de CORBA : l’interface

Middleware / CORBA 5 Lionel Seinturier Middleware / CORBA 6 Lionel Seinturier

2. Architecture 2.1 Consortium OMG

2.1 Consortium OMG Object Management Group http://www.omg.org

Middleware / CORBA 7 Lionel Seinturier Middleware / CORBA 8 Lionel Seinturier

Fonctionnement du consortium Application Objets Domain Interfaces Common Facilities

Proposition Object Request Broker (ORB)

Middleware / CORBA 9 Lionel Seinturier Middleware / CORBA 10 Lionel Seinturier

2.2 Modèle OMA 2.2 Modèle OMA

Middleware / CORBA 11 Lionel Seinturier Middleware / CORBA 12 Lionel Seinturier

Les «facilités» communes Les interfaces de domaine

Common Facilities - imagerie Domain Interfaces

Middleware / CORBA 13 Lionel Seinturier Middleware / CORBA 14 Lionel Seinturier

2.3 Vue générale de CORBA 2.3 Vue générale de CORBA

param. sortie + retour

Middleware / CORBA 15 Lionel Seinturier Middleware / CORBA 16 Lionel Seinturier

Le noyau de l’ORB (ORB core) Souche

Le référentiel d’implantation (Implementation Repository) Souche dynamique

Middleware / CORBA 17 Lionel Seinturier Middleware / CORBA 18 Lionel Seinturier

2.5 Côté serveur 2.5 Côté serveur

Noyau de l’ORB Noyau de l’ORB

Middleware / CORBA 19 Lionel Seinturier Middleware / CORBA 20 Lionel Seinturier

Middleware / CORBA 21 Lionel Seinturier Middleware / CORBA 22 Lionel Seinturier

2.7 Adaptateur d’objet 2.8 Protocole d’invocation de méthodes

1. Synchrone 2. Asynchrone 3. Semi-synchrone

Middleware / CORBA 23 Lionel Seinturier Middleware / CORBA 24 Lionel Seinturier

Middleware / CORBA 25 Lionel Seinturier Middleware / CORBA 26 Lionel Seinturier

3. Langage IDL 3.1 Introduction

Middleware / CORBA 27 Lionel Seinturier Middleware / CORBA 28 Lionel Seinturier

Middleware / CORBA 29 Lionel Seinturier Middleware / CORBA 30 Lionel Seinturier

3.2 Conventions syntaxiques 3.3 Types de données

const <type> <ident> = <expr>; • définies par le programmeur

Middleware / CORBA 33 Lionel Seinturier Middleware / CORBA 34 Lionel Seinturier

3.6 Modules 3.7 Interfaces

Middleware / CORBA 35 Lionel Seinturier Middleware / CORBA 36 Lionel Seinturier

Middleware / CORBA 37 Lionel Seinturier Middleware / CORBA 38 Lionel Seinturier

3.7 Interfaces 3.7 Interfaces

Simple Redéfinitions : règle de la «liaison au plus tôt» (early binding)

interface ouvrier : employe { ... }; Une sous-interface

interface A { Le mécanisme de liaison au plus

Il aurait certainement été + simple d’interdire toute redéfinition

Middleware / CORBA 39 Lionel Seinturier Middleware / CORBA 40 Lionel Seinturier

Interface = attributs + opérations 4.1 Principe

Middleware / CORBA 41 Lionel Seinturier Middleware / CORBA 42 Lionel Seinturier

4.1 Principe 4.2 Types de base

1. Ecrire en IDL les interfaces des objets serveurs Types de base

Middleware / CORBA 43 Lionel Seinturier Middleware / CORBA 44 Lionel Seinturier

Rq : les constructions IDL qui n’ont pas d’équivalent en Java

Middleware / CORBA 45 Lionel Seinturier Middleware / CORBA 46 Lionel Seinturier

4.4 Interfaces 4.4 Interfaces

interface I { interface I { • une classe dite Helper <interface>Helper

attribute float a; float a();