Cor Bals

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

1. Introduction

2

Lionel Seinturier

1.1 Motivations

Quelques définitions • CORBA : Common Object Request Broker Architecture • ORB ou «bus logiciel» : fournit une infrastructure de commununication pour des objets hétérogènes et distribués (analogie avec le bus hardware)

Objets - distribués - hétèrogènes

: entités identifiés qui fournissent des services : peuvant être accédés à distance au travers d’un réseau : proviennent de langages et de systèmes ≠

Motivations pour CORBA • construire un environnement dont les spécifications sont standardisées • s’affranchir des solutions purement propriétaires • offrir une plate-forme multi-systèmes et multi-langages

Motivations pour l’approche objet ORB Objet serveur BD

Middleware / CORBA

Objet imprimeur

Objet annuaire

3

• l’application modèlise directement des objets «réels» du domaine • obtenir une architecture logicielle claire et simple • avoir une conception modulaire (les détails d’implentation internes sont masqués)

Objet courtier

Lionel Seinturier

Middleware / CORBA

4

Lionel Seinturier

1.2 Principes de base

1.2 Principes de base

Principes fondamentaux de CORBA

Définitions (suite)

• Transparence à la localisation • Transparence d’accès • Séparation des interfaces et des implantations • Interfaces typées • Support de l’héritage multiples d’interfaces

• interface : ensemble des opérations et des attributs d’un objet • implantation : «code» associé aux opérations • localisation : machine physique sur laquelle réside l’objet • référence : structure (≈ pointeur) permettant d’accéder à l’objet

Ö

Notion fondamentale de CORBA : l’interface

- l’utilisation d’un service est orthogonal à sa localisation - les services sont accédés en invoquant des opérations sur des objets - les clients dépendent des interfaces, pas des implantations - 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

Middleware / CORBA

5

Lionel Seinturier

• définie dans un langage dédié (IDL : Interface Definiton Language) • contrat entre le client et le serveur • définit de façon exhaustive les services que le serveur offre au client

Middleware / CORBA

2. Architecture

6

Lionel Seinturier

2.1 Consortium OMG

2.1 Consortium OMG

Object Management Group

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, ...) • Produit des spécifications

2.3 Vue générale de CORBA 2.4 Côté client

http://www.omg.org

• OMA (Object Management Architecture) architecture générale pour la gestion d’objets distribués • CORBA un des composants de l’OMA permet aux objets distribués de communiquer

2.5 Côté serveur 2.6 Référence d’objet 2.7 Adapteur d’objet

1989

2.8 Protocole d’invocation de méthodes

11 membres

2.9 Fournisseurs d’ORBs Middleware / CORBA

1990

OMA v1

7

Lionel Seinturier

Middleware / CORBA

1991

1992

1993

1994

1995

1996

1997

1998

1999

2000

390 Définition des services CORBA 1.1 membres 200 membres CORBA 2.0 2.2 CORBA2.3 3.0 ? 8

Lionel Seinturier

2.1 Consortium OMG

2.2 Modèle OMA

Fonctionnement du consortium

Application Objets

Appel d’offre (RFP : Request For Proposal) • quand un besoin apparaît, l’OMG émet une RFP • la RFP définit les objectifs de cette nouvelle spécification • un échéancier est associé à cette RFP Proposition • tous les membres intéressés peuvent soumettre une proposition • une proposition ne peut être acceptée que si un prototype d’implantation est fourni • les propositions soumises sont révisées jusqu’à ce qu’il n’y en ait plus qu’une seule • une fois la proposition acceptée, ces auteurs doivent fournir l’implantantation finale dans l’année Middleware / CORBA

9

Lionel Seinturier

O2

Dist. simul.

Appl. dev.

Info. mgmt.

Task. mgmt

O3

O4

Manuf.

Account.

User interf.

System mgmt

Object Request Broker (ORB) Naming

Event

Lifecycle

Concur.

Transac.

Relation.

Security

Query

External.

Time Licensing

Collect. Trading

Persist. Propert.

Common Object Services Middleware / CORBA

10

Lionel Seinturier

2.2 Modèle OMA Les services communs

• Bus logiciel (ORB : Object Request Broker) infrastructure de communication de l’OMA CORBA: spécifications de l’ORB

• abstractions de fonctionalités système courantes (nommage, transaction, ...) • indépendants du domaine d’applications • 15 services spécifiés actuellement • rassemblés selon leur importance

• Services (COS : Common Object Services ou CORBAServices) «librairies» (classes) de services systèmes de base COSS : spécifications des COS • Facilités (Common Facilities ou CORBAFacilities) «frameworks» logiciels pour des traitements courants • Interfaces de domaines (Domain Interfaces) «frameworks» logiciels spécialisés pour des domaines d’activités • Objets d’application (Application Objects) applications mises en place par les développeurs

11

Common Facilities

O1

2.2 Modèle OMA

Middleware / CORBA

Domain Interfaces

Lionel Seinturier

COS sets 1 & 2

COS sets 3, 4 & 5

- nommage - événement - cycle de vie - persistance - transaction - concurrence - relation - externalisation

- requête - gestion de licence - propriétés - sécurité - temps - courtage - collection

Middleware / CORBA

12

Lionel Seinturier

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 • indépendantes du domaine d’applications • également appelées facilités horizontales • 4 facilités

• «frameworks» logiciels de plus hauts niveaux que les services • spécialisées pour un domaine d’applications particulier • également appelées facilités verticales • 8 interfaces de domaine

Common Facilities - interface utilisateur - gestion de l’information - gestion du système - gestion des tâches

Middleware / CORBA

Info. mgmt.

Task. mgmt

User interf.

System mgmt

13

Lionel Seinturier

Middleware / CORBA

2.3 Vue générale de CORBA

Client

Smalltalk

Cobol

Ada

Java

C++

C

Smalltalk

Appl. dev.

Manuf.

Account.

Lionel Seinturier

2.3 Vue générale de CORBA

Interface IDL Souche

Dist. simul.

14

Serveur Cobol

Ada

Java

C++

C

Client

Domain Interfaces

- imagerie - autoroute de l’information - simulation distribuée - comptabilité - industrie pétrolière - construction - ...

Souche statique

Squelette

param. entrée Int erf. Obj opération IDL ref param. sortie + retour

Souche dynamique

Serveur

Squelette statique Primitives de l’ORB

Noyau de

Squelette dynamique

Adaptateur d’objets

l’ORB

Object Request Broker (ORB) Vocabulaire : souche, squelette, talon sont ici synonymes Ö entités qui préparent et gèrent les appels entre clients et serveurs Middleware / CORBA

15

Lionel Seinturier

Référentiel d’interfaces

Middleware / CORBA

Référentiel d’implantation

16

Lionel Seinturier

2.3 Vue générale de CORBA

2.4 Côté client Souche

Le noyau de l’ORB (ORB core)

Client

• gère la localisation des objets dans l’environnement • implante les protocoles de communication entre objets • accessible au travers d’un ensemble de primitives

• prépare les paramètres d’entrée de l’invocation • décode les paramètres de sortie et le résultat

Le référentiel d’interfaces (Interface Repository)

Souche statique

• base de données des interfaces des objets serveurs • une par environnement (groupement logique de machines) • possibilité de fédérer les référentiels de différents environnements

Le référentiel d’implantation (Implementation Repository) • base de données sur les implantations des objets serveurs • une sur chaque site accueillant des objets serveurs

Middleware / CORBA

17

• une par type d’objet serveur à invoquer • identique aux souches clientes RPC • générée à la compilation à partir de l’interface IDL

Lionel Seinturier

Middleware / CORBA

18

Lionel Seinturier

2.5 Côté serveur Serveur

Squelette Squelette statique dynamique Adaptateur d’objets

Squelette statique

Serveur

• un par type d’objet serveur invoquable • identique aux souches serveurs RPC • généré à la compilation à partir de l’interface IDL

Noyau de l’ORB

Squelette Squelette statique dynamique Adaptateur d’objets Noyau de l’ORB

Squelette dynamique

• réceptacle pour les objets serveurs • interface entre les objets serveurs et l’ORB • gère l’instantiation des objets serveurs • crée les références d’objets • 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 ≠ Middleware / CORBA

Noyau de l’ORB

• 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)

Squelette

Adaptateur d’objets

Souche dynamique

Souche dynamique

2.5 Côté serveur

• symétrique de la souche • décode les paramètres d’entrée des invocations • prépare les paramètres de sortie et le résultat

Souche statique

19

Lionel Seinturier

• squelette générique prenant en compte dynamiquement tout type de requêtes • permet de créer à l’exécution des classes d’objets serveurs (i.e. que l’on ne connaissait pas à la compilation)

Middleware / CORBA

20

Lionel Seinturier

2.6 Référence d’objet

2.7 Adaptateur d’objet

Référence d’objets (IOR: Interoperable Object Reference) information permettant d’identifier de manière unique et non ambiguë tout objet dans un ORB Type de l’objet

Adresse réseau

Clé de l’objet

Type de l’objet : permet de différencier des types d’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 IDL:monObjet:1.0

milo.jussieu.fr:1805

Différents types d’adaptateurs d’objets • les plus courants : BOA (Basic OA) et POA (Portable OA) • se différencient par la façon dont ils - instancient les objets - aiguillent les requêtes - activent les objets

Le BOA • le plus simple • propose 4 modes d’activation des objets

OA7, obj_979

IOR:000000000000001c49444c3a43616c63756c6174726963652f43616c63756c3a312e30000000000300000000000000330001000000 00000e3133322e3232372e36342e3430000b4e00000017383135313337313834312f00114d4d4d4d4d0e4d390d23000000000000000038 000101000000000e3133322e3232372e36342e3430000b4e00000017383135313337313834312f00114d4d4d4d4d0e4d390d2300000000 00000000010000002c0000000000000001000000010000001c00000000050100010000000100010001000101090000000105010001

Middleware / CORBA

21

Lionel Seinturier

2.7 Adaptateur d’objet BOA pour serveur partagé O1

O2

O1

O2

O3

O1

O2

Serveur

1. Synchrone (synchronous)

BOA

BOA avec serveur par méthode

O1

O2

Client

Serveur

2. Asynchrone (asynchronous)

Client

Serveur

3. Semi-synchrone (deferred synchronous)

Rq: 3 n’est pas disponible avec un talon statique

BOA avec serveur persistant

O3

Lionel Seinturier

Modes d’invocation de méthodes Client

BOA

22

2.8 Protocole d’invocation de méthodes

BOA pour serveur non partagé

O3

Middleware / CORBA

O3

Sémantique Ordonnanceur

1 et 3 : «au plus une fois» 2 : «au mieux» (la réception du message n’est pas garantie) BOA

Middleware / CORBA

BOA

23

Lionel Seinturier

Middleware / CORBA

24

Lionel Seinturier

2.8 Protocole d’invocation de méthodes GIOP (General Inter-Orb Protocol)

Commerciaux

Protocole comprenant 7 messages pour assurer les communications entre objets invocation d’une méthode réponse à une invocation annulation d’une invocation localisation d’un objet réponse de localisation fermeture de connexion signalisation de message erronné fragmentation de messages

Request Reply CancelRequest LocateRequest LocateReply CloseConnection MessageError Fragment

(C) (C) (C) (C) (S) (S) (S/C) (S/C)

25

• ORBIX • VisiBroker • ORBacus • DSOM

IONA Inprise OOC IBM

www.iona.com

Univ. Francfort Univ. Berlin AT&T

www.mico.org

www.inprise.com/visibroker/ www.ooc.com www.software.ibm.com/ad/som/

Gratuits • MICO • JacORB • OmniORB 2 • TAO

• GIOP nécessite un protocole de transport fiable, orienté connexion • IIOP (Internet IOP) : implantation de GIOP au-dessus de TCP • Autres implantations de GIOP au-dessus de HTTP, RPC DCE, RPC Sun • Associé à un format de d’encodage des données (CDR) Middleware / CORBA

2.9 Fournisseurs d’ORBs

Lionel Seinturier

www.inf.fu-berlin.de/~brose/jacorb/ www.uk.research.att.com/omniORB/

Univ. Washington www.cs.wustl.edu/~schmidt/TAO.html

De nombreux autres sont disponibles voir www.vex.net/~ben/corba/ ou www.cetus-links.org à la rubrique CORBA

Middleware / CORBA

3. Langage IDL

26

Lionel Seinturier

3.1 Introduction IDL (Interface Definition Language)

3.1 Introduction

• Langage de définition des services proposés par un objet • 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.2 Conventions syntaxiques 3.3 Types de données

• Mapping : correspondance entre IDL et un langage de programmation - 6 mappings normalisés OMG (C, C++, Java, Ada, Cobol, Smalltalk) - d’autres + exotiques existent (Tcl, Perl, CLOS, Eiffel, Python, Modula)

3.4 Constantes 3.5 Exceptions

De nombreux autres IDLs existent : OSI ASN.1, SNMP SMI, Sun ONC XDR, DCE IDL, Microsoft IDL

3.6 Modules 3.7 Interfaces

IDL de CORBA • orienté objet • supporte l’héritage • dedié à la programmation distribuée

3.8 Résumé

Middleware / CORBA

27

Lionel Seinturier

Middleware / CORBA

28

Lionel Seinturier

3.1 Introduction

3.2 Conventions syntaxiques

Structure d’un fichier IDL <exceptions>

typedef string Tadresse; const Tadresse adresseJussieu = «...»; exception jourFerie {};

<modules>

module DESSISI { interface Etudiant { attribute long age; boolean present( in long jour ) raises jourFerie; } }

• Les modules peuvent être emboîtés les uns dans les autres • Les types, constantes, exceptions peuvent être déclarés à ≠ niveaux (globalement, localement à un module, localement à une interface)

Middleware / CORBA

29

Lionel Seinturier

• Proche de la syntaxe C++ • Commentaires /* */ ou // • Identificateurs : séquence de caractères alphabétiques, chiffres ou _ (doivent commencer par un caractère alphabétique) • La casse des identificateurs n’est pas déternimante attribute long age; et attribute long Age; sont considérés comme une redéfinition du même attribut • Néanmoins, toutes les références à un identificateur doivent respecter la casse de sa définition. typedef float CoordX; devra être utilisé CoordX • Mots clés IDL any attribute boolean case char const context default double Middleware / CORBA

3.2 Conventions syntaxiques

Préprocesseur - identique à celui de C/C++ - substitution de macros (#define) - compilation conditionnelle (#ifdef et #ifndef) - inclusion de sources (#include) - directives de compilation (#pragma)

31

Object octet oneway out raises readonly sequence short string

struct switch TRUE typedef union unsigned voif wchar wstring

30

Lionel Seinturier

3.3 Types de données

Différences / à la syntaxe C++ - un identificateur doit être fourni pour chaque paramètre d’une opération - une liste de paramètres avec seulement le toker void ne peut pas être utilisé pour indiquer une liste vide - les types entiers ne peuvent pas être déclarés comme des int ou des unsigned. Il faut préciser short ou long. - les caractères ne peuvent pas être associés aux modificateurs signed ou unsigned.

Middleware / CORBA

enum exception FALSE float in inout interface long module

Types de base et construits • short, unsigned short (2 octets) • long, unsigned long (4 octets) • long long, uns. long long (8) • float (4 octets) • double (8), long double (16) • boolean (TRUE, FALSE) • octet (1 octet, transmis tel quel) • char (1 octet, ISO Latin 1) • wchar (2 octets, Unicode) • void (type vide)

Exemple typedef long age; struct personne { string nom; long age; }; enum couleur {rouge, vert, bleu}; union carre switch(couleur) { case rouge: short num; default: char n; };

• struct (structures) • enum (énumération) • union (type discriminé) • string, wstring (chaînes) • sequence (tableau) • any (type indifférencié) Lionel Seinturier

Middleware / CORBA

string <16> chaine; string nom; sequence vecteur; sequence tableau;

32

Lionel Seinturier

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 = <expr>;

• définies par le programmeur • levées par le système

Types autorisés pour les constantes • long, unsigned long • short, unsigned short • long long, unsigned long long • float, double, long double • boolean • char, wchar • string

Exemple const long max = 255; const long taille = 8; const long segments = 1024/taille; const string usage = «Hello»;

Opérateurs autorisés • unaires + - ~ • binaires + - * / %

Quelques exceptions système

exception { <donnée>* };

OBJECT_NOT_EXIST BAD_PARAM COMM_FAILURE NO_MEMORY INV_OBJREF ...

Exemple exception overflow { float limit; }; long exp( in float x ) raises(overflow);

<< >> & | ^

Middleware / CORBA

Exceptions spécifiées par l’utilisateur

33

Lionel Seinturier

Middleware / CORBA

3.6 Modules

Lionel Seinturier

3.7 Interfaces

Des conteneurs de définitions Peuvent contenir : types, constantes, exceptions, interfaces, modules Ö hiérarchies de modules permettent de structurer les applications module { ... };

Exemple

Les points d’accès aux objets CORBA (identiques aux interfaces Java ou aux classes abstraites C++) • Peuvent contenir : types, constantes, exceptions, attributs, opérations • Peuvent hériter leur structure d’une ou +sieurs autres interfaces • Peuvent être prédéclarées en vue d’une utilisation ultérieure interface : { ... };

module mesAnimaux { ... module alaVille { ... }; module alaCampagne { ... }; ... };

Exemple interface Carre : Parallelepipede { ... }; interface A;

Toutes les définitions d’un module sont «visibles» grace à l’opérateur de résolution de portée :: Ex : mesAnimaux::alaVille::... Middleware / CORBA

34

35

Lionel Seinturier

interface B { ... }; interface A { ... };

Middleware / CORBA

// // // //

prédéclarée (le compilateur «sait» que l’ident. A est associé à une interface utilise A utilise B

36

Lionel Seinturier

3.7 Interfaces

3.7 Interfaces Opérations

Attributs • Les variables publiques des interfaces (i.e. accessibles par tous les clients) • Peuvent être lus ou écrits par les clients (sauf si déclarés readonly) • Chaque attribut est associé à 2 méthodes (appelées setter/getter) permettant de le lire et de l’écrire (seulement setter pour readonly)

• Prennent des paramètres et retournent un résultat • Passage par référence pour les objets, par valeur pour tous les autres • in : entrée inout : entrée/sortie out : sortie • Peuvent lever une ou +sieurs exceptions oneway ( <liste paramètres> ) raises( <exceptions> ) context( );

attribute ; readonly attribute ;

float op1( in short x, out long y ) raises(depassement);

IDL

Langage de programmation

attribute float rayon;

float rayon(); void rayon( float value );

readonly attribute long age;

int age();

• Peuvent être déclarée asynchrone (oneway) pas de paramètres de retour, ni inout, ni out, pas d’exception oneway void op2( in long x );

• Contexte d’exécution (≈ variables d’environnement d’un shell) informations mises à la disposition du serveur par le client Middleware / CORBA

37

Lionel Seinturier

Middleware / CORBA

3.7 Interfaces

38

Lionel Seinturier

3.7 Interfaces

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 • ne peut pas redéfinir les attributs, les opérations Ö éviter qu’un même nom ne soit associé à 2 traitements ≠

Multiple interface ouvrier : employe, personne { ... };

• L’ordre de déclaration des interfaces n’a pas d’importance • Une sous-interface hérite de tous les éléments de sa ou ses super-interfaces • Une sous-interface peut ajouter de nouveaux éléments • Possibilité d’héritage «en losange» ( A←B A←C B,C←D )

interface A { const long L = 3; void f( in sequence s ); }; interface B { const long L = 4; } interface C : B, A {}

Le mécanisme de liaison au plus tôt garantit que la signature de C::f est void f( in sequence s );

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

39

Lionel Seinturier

Middleware / CORBA

40

Lionel Seinturier

3.8 Résumé

4. Développement Java

IDL : langage de définition des interfaces des objets CORBA 4.1 Principe

Interface = attributs + opérations

4.2 Types de base (traduction IDL vers Java) Différences entre IDL et des langages comme C++ ou Java • Pas de code • Pas de pointeur • Pas de constructeur • Pas de destructeur • Pas de surcharge d’opérations • Pas de polymorphisme

Middleware / CORBA

4.3 Types construits (traduction IDL vers Java)

• Modes de passage de paramètres • Sémantique d’appel oneway • Attributs readonly • Type sequence • Unions nécessitent un discriminant

4.4 Interfaces (traduction IDL vers Java) 4.5 Implantation des interfaces 4.6 Programme serveur 4.7 Programme client

41

Lionel Seinturier

Middleware / CORBA

4.1 Principe

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 2. Implanter en Java ces interfaces 3. Ecrire le programme Java qui instancie les objets serveurs 4. Ecrire le programme Java qui réalise les appels des objets serveurs 4

1

2

3

Prog. client

Interface IDL

Implantation

Prog. serveur

Souche statique

générés par le compilateur de langage IDL

Types de base IDL [unsigned] short [unsigned] long [unsigned] long long float double char, wchar string, wstring boolean octet any void long double

Squelette statique Adaptateur d’objets

Middleware / CORBA

l’ORB 43

Lionel Seinturier

4.2 Types de base

Développement d’une application client/serveur CORBA/Java

Noyau de

42

Lionel Seinturier

Middleware / CORBA

Java short int long float double char java.lang.String boolean byte org.omg.CORBA.Any void non supporté 44

Lionel Seinturier

4.3 Types construits

4.3 Types construits

Types construits IDL module interface attribute opération struct, enum, union sequence const exception

Cas spéciaux (struct, enum, union)

Java package interface méthodes setter/getter méthode Java

Ö une classe de nom identique à celui du type déclaré est créée

IDL enum Couleur { rouge, vert, bleu }

classes Java tableau Java static final sous-classe de java.lang.Exception

Java public final class Couleur { public static int _rouge = 0; public static int _vert = 1; public static int _bleu = 2; public Couleur(int); public int value(); }

Rq : les constructions IDL qui n’ont pas d’équivalent en Java sont traduites par des classes Middleware / CORBA

45

Lionel Seinturier

Middleware / CORBA

4.4 Interfaces

Pour chaque interface IDL, le traducteur IDL vers Java génère

IDL

• une interface Java • une classe pour le squelette _ImplBase • une classe pour la souche StubFor

Java package M; interface I { int meth( int arg ) throws e;

interface I { long meth( in long arg ) raises (e);

float a(); void a( float value );

attribute float a; readonly attribute double d;

double b();

}

}

exception e { ... }

class e extends Java.lang.Exception { ... }

}

Middleware / CORBA

Lionel Seinturier

4.4 Interfaces

Exemple de correspondance IDL - Java

module M {

46

47

Lionel Seinturier

• une classe dite Helper Helper • une classe dite Holder Holder

La classe Helper permet de • lire et écrire des objets implantant cette interface dans un flux • convertir un objet CORBA vers le type représenté par cette interface • insérer et extraire un objet implantant cette interface dans un objet de type Any • les classes Helper existent également pour les types simples (IntHelper, ...) Middleware / CORBA

48

Lionel Seinturier

4.4 Interfaces

4.4 Interfaces

Holder gère les modes de passage inout et out

Les classes Holder existent également pour les types simples (IntHolder, ...)

#1 maCl obj = new maCl(); autreCl appel = new autreCl(); appel.uneMeth(obj); System.out.println(obj);

class autreCl { void uneMeth(maCl param) { param = new maCl(); } } #2

en Java : #1 avec la sémantique inout, on voudrait que obj vaille #2 (même pb pour out) Ö Solution : des classes conteneurs (dite holder) class Holder { maCl value; } Holder hold = new Holder(); hold.value = new maCl(); appel.uneMeth(hold);

Middleware / CORBA

class autreCl { void uneMeth(Holder param) { param.value = new maCl(); } }

49

Lionel Seinturier

final public class IntHolder { public int value; public IntHolder() {} public IntHolder ( int initial ) { value = initial; } }

Exemple de traduction IDL - Java IDL

Java

interface I { void meth( inout long arg ); }

interface I { int meth( IntHolder arg ); }

Le programmeur lit et écrit l’entier arg.value Middleware / CORBA

4.5 Implantation des interfaces

50

Lionel Seinturier

4.5 Implantation des interfaces 2

1ère approche : héritage La classe d’implantation hérite du squelette Exemple

Interface IDL généré par le compilateur de langage IDL

Interface IDL

Implantation

Squelette statique

Inconvénient de l’approche précédente l’héritage simple de Java limite les possibilités de réutilisation Solution : une classe (dite tie) délègue l’implantation à une autre classe

module M { interface Interf { void ping(); } }

Exemple

Implantation Java par héritage

51

Interface IDL généré par le compilateur de langage IDL

Implantation Class tie

...

Class impl

Squelette statique

Avantage

Implantation Java par délégation

package M; class InterfImpl extends _InterfImplBase { void ping() { System.out.println(«ping reçu»); } }

Middleware / CORBA

2

2ème approche : délégation

InterfImpl peut hériter d’une autre classe

package M; class InterfImpl implements InterfOperations { void ping() { System.out.println(«ping reçu»); } }

Lionel Seinturier

Middleware / CORBA

52

Lionel Seinturier

4.6 Programme serveur

4.6 Programme serveur 3

Mise en service des objets serveurs Implantation

1. Initialiser l’ORB et le BOA 2. Instancier les objets serveurs 3. Publier leur référence 4. Les lancer

Prog. serveur

1. Initialiser l’ORB et le BOA 2. Instancier les objets serveurs 3. Publier leur référence 4. Les lancer

Prog. serveur

package M; class InterfImpl implements InterfOperations { void ping() { System.out.println(«ping reçu»); } public static void main(String[] args) { 1. ORB orb = ORB.init(args,null); BOA boa = orb.BOA_init(); 2. InterfImpl test = new InterfImpl(); Interf skel = new _tie_Interf(test); 3. ns.bind(skel,«objetTest»); 4. boa.impl_is_ready(); } }

package M; class InterfImpl implements InterfOperations { void ping() { System.out.println(«ping reçu»); } public static void main(String[] args) { 1. ORB orb = ORB.init(args,null); BOA boa = orb.BOA_init(); 2. InterfImpl test = new InterfImpl(); 3. ns.bind(test,«objetTest»); /* ns = name server */ 4. boa.impl_is_ready(); } }

53

Implantation

Cas de l’implantation par délégation

Cas de l’implantation par héritage

Middleware / CORBA

3

Mise en service des objets serveurs

Lionel Seinturier

Middleware / CORBA

4.7 Programme client

54

Lionel Seinturier

5. Développement C++ 4

Appel des objets serveurs

Prog. client

1. Initialiser l’ORB côté client 2. Rechercher les objets serveurs 3. Les invoquer

5.2 Types construits (traduction IDL vers C++) Souche statique

55

5.3 Interfaces (traduction IDL vers C++) 5.4 Implantation des interfaces

class client { public static void main(String[] args) { 1. ORB orb = ORB.init(args,null); 2. CORBA.Object o = ns.resolve(«objetTest»); Interf obj = InterfHelper.narrow(o); 3. obj.ping(); } }

Middleware / CORBA

5.1 Types de base (traduction IDL vers C++)

5.5 Programme serveur 5.6 Programme client 5.7 A propos du développement en C

Lionel Seinturier

Middleware / CORBA

56

Lionel Seinturier

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

Types de base En C++, la taille d’un int, float, ... varie selon les compilateurs Ö les définitions CORBA::... masquent ces ≠

IDL [unsigned] short [unsigned] long [unsigned] long long float double char, wchar string, wstring long double boolean octet any void

Middleware / CORBA

C++ CORBA::Short [UShort] CORBA::Long [ULong] CORBA::LongLong CORBA::Float CORBA::Double CORBA::Char, WChar CORBA::String, WString CORBA::LongDouble CORBA::Boolean CORBA::Octet CORBA::Any void

57

Lionel Seinturier

C++ class (*)

attribute opération

méthodes setter/getter méthode C++

struct, enum, union sequence const exception

struct, enum, union classe C++ static const sous-classe d’une classe Exception

(*) : si disponible, utilisation du mot-clé C++ namespace pour les modules

Middleware / CORBA

5.3 Interfaces

58

Lionel Seinturier

5.4 Implantation des interfaces 2

IDL

C++

module M { interface I { long meth( in long arg ); attribute float a; readonly attribute double d; } }

class M_I { CORBA::Long meth( CORBA::Long arg ); CORBA::Float a(); void a(CORBA::Float value); CORBA::Double b(); }

Pour chaque interface IDL, le traducteur IDL vers C++ génère • une classe C++ • un type _var • un type _ptr

La classe d’implantation hérite du squelette

Interface IDL

Implantation

Exemple généré par le compilateur de langage IDL

Interface IDL

Squelette statique

module M { interface Interf { void ping(); } }

Implantation C++

• _var : objet de type (alloc. mem. automatiques) • _ptr : référence à un objet de type

Middleware / CORBA

IDL module, interface

59

Lionel Seinturier

class M_InterfImpl: M_sk_Interf { void ping() { cout << «ping reçu» << nl; } }

Middleware / CORBA

60

Lionel Seinturier

5.5 Programme serveur

5.6 Programme client 3

Mise en service des objets serveurs

Prog. serveur

Implantation

1. Initialiser l’ORB et le BOA 2. Instancier les objets serveurs 3. Publier leur référence 4. Les lancer

int main( int argc, char *argv[] ) { CORBA::ORB_ptr orb = CORBA::ORB_init(argc,argv); CORBA::BOA_ptr boa = orb->BOA_init(argc,argv); 2. M_InterfImpl test = new M_InterfImpl(); 3. ns->bind(test,«objetTest»); 4. boa->impl_is_ready(); } 1.

Middleware / CORBA

61

4

Appel des objets serveurs

Prog. client

1. Initialiser l’ORB côté client 2. Rechercher les objets serveurs 3. Les invoquer

Souche statique

int main( int argc, char *argv[] ) { CORBA::ORB_ptr orb = CORBA::ORB_init(argc,argv); CORBA::Object o = ns->resolve(«objetTest»); M_Interf obj = M_Interf_narrow(o); 3. obj->ping(); } 1. 2.

Lionel Seinturier

Middleware / CORBA

5.7 Développement C

62

Lionel Seinturier

6. Services

But • permettre d’intégrer de «vieilles» applications C à un environnement CORBA • développer des applications CORBA light et performantes (voir GNOME et ORBit)

6.1 Introduction

Problème : C n’est pas orienté objet Solution : utilisation de conventions de nommage pour tout traduire en fonctions C et simuler un environnement OO

6.3 Courtage

6.2 Nommage

6.4 Evénement 6.5 Transaction

IDL

C

module M { interface I { long meth( in long arg ); } }

Middleware / CORBA

CORBA_Long M_I_meth( CORBA_Long arg );

63

Lionel Seinturier

6.6 Aperçu des autres services

Middleware / CORBA

64

Lionel Seinturier

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 • chaque service est défini par une ou +sieurs interfaces IDL • 15 services actuellement

• ≡ à un annuaire (pages blanches), DNS, ... • organisé de façon hiérarchique ( ≡ hiérarchie de fichiers) • 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

Lifecycle

Transac.

Security

External.

Licensing

Trading

Hawaii

Propert.

Contexte de nommage ....

Common Object Services Middleware / CORBA

65

Ixtapa Lionel Seinturier

Middleware / CORBA

6.2 Nommage

Objet

Cancun Playa Blanca 66

Lionel Seinturier

6.2 Nommage

Deux façons de localiser un objet CORBA

• Interfaces graphiques pour visualiser le contenu des serveurs de noms Exemple

• à partir de son nom • 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 } }

La norme prévoit que l’on puisse (en pratique ??) : • fédérer les services de nommage • les faire intéropérer avec d’autres annuaires (DNS, DCE CDS, OSI X500, NIS+) Middleware / CORBA

Racine

67

Lionel Seinturier

RootContext : la racine du serveur de nom Name Kind Type Host

: le nom de l’objet : une chaîne précisant le «type» de service fournit par l’objet : l’interface IDL implantée par l’objet : l’adresse IP et le port servant des requêtes pour l’objet

Middleware / CORBA

68

Lionel Seinturier

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 • on recherche un objet CORBA à partir de ses fonctions • utilise un courtier 1. le serveur s’enregistre auprès du courtier 2. le client interroge le courtier 3. le client invoque le serveur 2

courtier

client

2 rôles • producteur d’événements ( ≡ d’information) • consommateur d’événements (s’abonne auprès d’1 ou +sieurs producteurs) Notion de canal d’événements • liaison (n-m) entre producteurs et consommateurs par laquelle transitent les évts

1

serveur

Rq : le service de courtage est souvent utilisé conjointement au DII

prod.

push

cons.

prod.

info. Middleware / CORBA

69

Lionel Seinturier

pm

cons.

70

Lionel Seinturier

3 types d’acteurs • client transactionnel • serveur transactionnel : implante l’algorithme de validation à 2 phases • serveur de recouvrement gère les ressources (données) sur lesquelles s’effectue la transaction

Propriétés «habituelles» des transactions (ACID) • atomicité : transac. effectuée complètement ou pas du tout • cohérence : transac. préserve la cohérence des données • isolation : exéc. // équivalentes à exéc. séquentielles • duralibité : résultats de la transac. persistants

Interfaces

Modèle de transactions imbriquées

client

Transac. princ.

commit/ rollback

• serveur transactionnel • Current : interf. entre le client et le serveur transac. • Coordinator : interf. entre le serveur transac. et les serveurs de recouvr. • serveur de recouvrement • Resource : interf. de gestion des ressources transactionnelles

Sous transac.

serveur 1 prepare

pull

....

6.5 Transaction

Permet d’effectuer des transactions sur des objets CORBA

Algorithme de validation à 2 phases

Canal

info.

Middleware / CORBA

6.5 Transaction

....

p1

cn

2 modes de diffusion • «push» : initié par le producteur • «pull» : initié par le consommateur

3

c1

oui/non ...

serveur 2

client

Cur rent

serveur transac.

Coord inator

Resso urces

serveur recouvr.

Optimisation : valid. 1 phase lorsque 1 seul serveur Middleware / CORBA

71

Lionel Seinturier

Middleware / CORBA

72

Lionel Seinturier

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 client

current

coordinator

resource

resource

begin débit get_control register_resource crédit get_control register_res commit

- cycle de vie - persistance - concurrence - relation - externalisation - requête - licence - propriétés - sécurité - temps - collection

gestion de l’évolution des objets (déplacement, copie, ...) sauvegarde de l’état des objets gestion de verrous gestion d’associations (E/A) entre objets mécanisme de «mise en flux» pour des objets envoi de requête «à la SQL» vers des objets contrôle de l’utilisation des objets gestion d’attributs dynamiques pour des objets gestion sécurisée de l’accès aux objets serveur de temps et synchronisation d’horloges gestion de groupes d’objets

prepare commit

Rq : peu d’ORBs offrent tous ces services banque A

Middleware / CORBA

73

banque B Lionel Seinturier

Middleware / CORBA

7. Concepts avancés

74

Lionel Seinturier

7.1 Invocation dynamique DII : Dynamic Interface Invocation • Permet d’invoquer des objets dont on ne connaît pas l’interface au moment de la compilation • L’interface est «découverte» à l’exécution

7.1 Invocation dynamique (DII) 7.2 Squelette dynamique (DSI) 7.3 Intercepteurs

Les interfaces sont stockées dans le référentiel d’interfaces • 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

7.4 Adaptateur d’objet portable (POA)

• 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 Middleware / CORBA

75

Lionel Seinturier

Middleware / CORBA

76

Lionel Seinturier

7.1 Invocation dynamique

7.1 Invocation dynamique

Référentiel d’interfaces Repository |-> ConstantDef |-> TypeDef |-> ExceptionDef |-> InterfaceDef |-> ModuleDef |-> ... |-> InterfaceDef |-> ... |-> AttributeDef |-> OperationDef |-> ParameterDef |-> ExceptionDef

Middleware / CORBA

• Interfaces graphiques pour visualiser le contenu des référentiels d’interfaces • Référentiel d’interface ≡ objet serveur CORBA comme un autre

Exemple

Exemple

module M { interface I { long meth( in long arg ); } }

est stockée Repository |-> M |-> I |-> (meth,long) |-> (in,long,arg)

77

Lionel Seinturier

Middleware / CORBA

7.1 Invocation dynamique

78

7.1 Invocation dynamique classe mère

• Le référentiel fournit des requêtes (interrogation, maj, ...) • Les éléments qu’il contient sont des objets qui ∈ à des classes organisées selon une hiérarchie d’héritage

classe fille

Exemple CORBA.Obj o = ... ; InterfDef i = o._get_interface();

IRObject

Repository

PrimitiveDef Contained

Container

3. on crée une requête

AddArg( req, 12 );

4. on ajoute les paramètres d’appel 5. on spécifie le type du résultat attendu

req.invoke(); int ret = req.return_value();

ExceptionDef ConstantDef

AttributeDef

ParameterDef

79

6. on invoque 7. on récupère le résultat

ModuleDef InterfaceDef

OperationDef

Lionel Seinturier

interroge le référentiel pour retrouver le descr. de l’interface est bloquante tant que le résultat n’est pas disponible

_get_interface invoke

Middleware / CORBA

1. on récupère une réf. d’obj. CORBA 2. on lui demande la descript. de son interf.

Request req = o._request( «meth» ); req.set_return_type( tk_long );

IDLType

TypeDef

Lionel Seinturier

Middleware / CORBA

80

Lionel Seinturier

7.1 Invocation dynamique

7.1 Invocation dynamique

Plusieurs sémantiques d’invocation possibles • invoke • send_oneway • send_deferred • poll_response • get_response

Avantages

appel bloquant appel asynchrone (oneway) appel non bloquant teste la présence de la réponse récupère la réponse envoi +sieurs requêtes oneway envoi non bloquant de +sieurs requêtes teste la présence d’une réponse récupère une réponse

• send_multiple_request_oneway • send_multiple_request_deferred • poll_next_response • get_next_response

Middleware / CORBA

• il n’est pas nécessaire de connaître les interfaces à la compilation • plus flexible que l’invocation statique • sémantiques d’invocations plus riches • permet de manipuler les contextes d’exécutions des clients

81

Lionel Seinturier

Inconvénients • plus difficile à manipuler • pas de vérification de type • plus lent

Middleware / CORBA

7.2 Squelette dynamique

82

Lionel Seinturier

7.3 Intercepteurs

DSI : Dynamic Skeleton Interface

Intercepteurs

• Fournit un squelette générique pour les objets serveurs dont on ne connaît pas l’interface au moment de la compilation • Equivalent côté serveur du DII

• Mécanisme permettant d’intercepter et de modifier les communications • 2 niveaux d’interceptions : requête et message • Permet d’implanter de façon transparente : filtrage, sécurité, audit, ...

Idée du fonctionnement • on implante une classe et une méthode qui aiguille les appels entrants • cette méthode travaille sur des objets request identiques à ceux du DII

Avantages

Inconvénients

• plus flexible • interface langages de script (Perl, ...) • ponts génériques entre ORB et autres systèmes (DCE, DCOM, ...)

• plus difficile à manipuler • pas de vérification de type • plus lent

Middleware / CORBA

83

Lionel Seinturier

Souche statique

Squelette statique

Souche dynamique

Squelette dynamique

Intercepteur requêtes

Intercepteur requêtes

Adaptateur d’objets

Intercepteur messages

Intercepteur messages

Noyau de

Middleware / CORBA

84

l’ORB

Lionel Seinturier

7.3 Intercepteurs

7.3 Intercepteurs

Intercepteurs de requêtes

Intercepteurs de messages

• Permet d’intercepter les requêtes (appels de méthodes) • Les requêtes sont manipulées comme des requêtes DII • On peut ajouter des pré et post actions à la requête • On peut changer le destinataire de la requête • Peuvent s’appliquer aux invocations locales et distantes

• Permet d’intercepter les messages IIOP échangés par l’ORB • Une requête ne correspond pas nécessairement à un seul message • Ne s’appliquent qu’aux invocations distantes

Interface de l’intercepteur de messages interface MessageInterceptor: Interceptor { void send_message( in Message mess, Object target ); void receive_message(in Message mess, Object target ); }

Interface de l’intercepteur de requêtes interface RequestInterceptor: Interceptor { void client_invoke( inout Request req ); void target_invoke( inout Request req ); }

Middleware / CORBA

85

Lionel Seinturier

Middleware / CORBA

7.4 Adaptateur d’objet portable

Lionel Seinturier

8. Le futur de CORBA

POA : Portable Object Adapter

¾ CORBA 3.0 (prévue en 2000 ?)

Adaptateur d’objets • réceptacle pour les objets serveurs • interface entre les objets serveurs et l’ORB • gère l’instantiation des objets serveurs • crée les références d’objets • aiguille les invocations de méthodes vers les objets serveurs • plusieurs adapteurs (≠ ou identiques) peuvent cohabiter sur une même machine Depuis CORBA 2.2, le POA remplace le BOA • référence d’objet persistante • meilleure gestion des threads • +sieurs références possibles pour le même objet • activation implicite des serveurs à partir du référentiel d’implantation • possibilité d’avoir +sieurs POA dans un même espace d’adressage • meilleure intégration avec le service de persistance Middleware / CORBA

86

87

Lionel Seinturier

Communication en mode message (MOM : Message-Oriented Middleware) • communication par boîtes à lettres + souple que le deferred synchronous • 2 modèles : callback et pooling Qualité de service (QoS : Quality of Service) • permet d’indiquer la QoS voulue en terme de priorité des messages Passage d’objet par valeur • permettre le passage d’objets par valeur plutôt que par référence

¾ RFP Tolérance aux fautes ¾ RFP Temps réel

Middleware / CORBA

88

Lionel Seinturier

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