2A-SI – Réseaux : Programmation en...

1

1

2A-SI – Réseaux :Programmation en CORBA

Stéphane Vialle

[email protected]://www.metz.supelec.fr/~vialle

Avec l’aide de l’équipe pédagogique du cours “Systèmes d’Information”

2

Programmation en Corba1 – Introduction2 – Architecture du bus Corba3 – Interopérabilité du bus Corba4 – L’architecture objet globale5 – Le langage IDL6 – Principes de programmation Corba7 – Exemple de déploiement

2

3

Corba : Un mécanisme de RPC (RMI) dehaut niveau en environnement hétérogène

Programmation en Corba

Introduction

CORBA bus

stubC

stubC++

stubJava

stubEiffel

stubSmallTalk

…Y.f(…);…

ObjectX

Processus P1MachineWindows

MachineUnix

f(…) {…}

ObjectY

Processus P2

Comm. network

• Communication entre objets distants :

• Coopération entre différentsenvironnements :

4


Introduction

Description officielle : CORBA = Common Object Request Broker Architecture

• “Bus logique” pour la gestion d’objets distribués- Première version en 1991- Pour construire des applications distribuées de grande taille

• Masque l’hétérogénéité des environnements- différents langages- différents OS- différentes architectures

• Basé sur le “Remote Method Invocation” (RMI)- du RPC entre objets

• Fruit d’un consortium international (un standard)

3

5


Introduction

Composition officielle de CORBA

Un modèle objet :OMG object model

Une architecture objet “globale” :Object Management Architecture (OMA)

Un bus logique d’objets distribués :Object Request Broker architecture (ORB)

Un langage de description d’interface :Interface Description Language (IDL)

Des implantations variéesNon spécifiées

6


4

7


Architecture du bus Corba (ORB)CORBA est “juste” un ensemble de spécifications :

• Un schéma de 9 blocs fonctionnels• Pas de spécifications d’implantation

+IDL compiler

Client

IDL stubs:Static

InvocationInterface

ORBI:ORB

Interface

InterfaceRepository

IDL Object

Skeleton

DSI: DynamicSkeletonInterface

ORB Core

Objects Implem-entation

Repository

DII:Dynamic

InvocationInterface

ObjectAdapter Interface

Object Adapter

1

2 3

4

56 7

8

9

8


Architecture du bus Corba (ORB)

1 – ORB core:

- Route les RPC/RMI entre les objets

- Optimisation du mécanisme de routage :- entre machines : par le réseau, - entre processus de la même machine : par la mémoire partagée, - entre parties du même processus : par appels de fonctions

Mais Corba reste « lent » !

- “ORB core” est inaccessible aux applications (couche cachée)

5

9



2 – IDL stubs / Static Interface Invocation:

- Pour les RMI sur des objets et méthodes connues à la compilation

- Permettent aux clients de faire des appels locaux (à des “stubs”)

- Les “stubs” empaquètent et dépaquètent les RMI et se chargent des vrais appels distants

3 – Dynamic Invocation Interface:

- Utile quand l’interface des objets à appeler est inconnue àla compilation (ex : pour implanter des interpréteurs de cmd)

- Doit rassembler beaucoup d’info sur l’objet à appeler

→ Beaucoup plus complexe que les RMI statiques

Les « talons » coté client :

10



4 – Interface Repository:

- Une BdD d’interfaces d’objets en IDL(modules, interfaces, operations, attributes, exceptions,

constants and data-type)

- Utilisée par les “Static Interface Invocation” et par les “Dynamic Interface Invocation” pour obtenir des informations sur l’objet distant à appeler

5 – ORB Interface:

- Fonctions d’initialisation et de paramétrage de Corba

- Utilisée par les applications et les serveurs (d’objets Corba)

6

11



6 – Static Skeleton Interface

- Dépaquètent les appels des clients - Transmettent aux objets appelés et connus à la compilation- Empaquètent les résultats destinés aux clients- Les “skeletons” sont générés par IDL (comme les “stubs”)

7 – Dynamic Skeleton Interface

- Permet d’accepter des appels sans connaître les règles de dépaquetage à la compilation (sans connaître les “skeleton”)

- Utile pour s’interfacer avec des langages interprétés

Les « talons » coté serveur :

12



8 – Object Adapter

- “ORB core” délègue le traitement des appels à “l’Object Adapter”

- Les objets peuvent avoir différents supports : processus, BdD, …- “L’Object Adapter” masque ces différences: activation de processus,accès à une BdD, …

- “L’Object Adapter” lit les données de “l’implementation repository”

9 – Implementation Repository

- Stocke les données relatives à l’implantation des objets- Ex : noms des exécutables, droit d’accès, politique d’activation des

exécutables, …

7

13


14


Intéropérabilité du bus Corba

CORBA = • Des specifications d’architecture (et un modèle objet)• Pas de spécifications d’implantation …

• Mais des spécifications d’intéropérabilité entre implantations …… pour relier des bus Corba distants.

Utilisation depasserelles

Utilisation d’unprotocole commun

2 stratégiesd’intéropérabilité

8

15



• Communication using full gateways:

gateway

Client

ORB Arequest A

IDLORB Brequest B

IDLObject

- Gateway intercepts and translates the requests, and can make security controls (→ firewall).

- Gateway allows to interconnect a CORBA bus with:- different CORBA buses, - non-CORBA buses (ex: CORBA ↔ DCOM (Microsoft))

- The gateway must know protocols of all interconnected buses→ n buses, with n protocol ⇒ (n.(n-1)/2) translations !!

16


Intéropérabilité du bus Corba• Communication using half-gateways:

- The full-gateway solution leads to too many translations- An economic solution is to use an intermediate and common protocol, and to use “half-gateways”- But each bus needs a generic half-gateway with DSI/DII interfaces (still complex mechanism)

Halfgate-

way A

Halfgate-

way B

ORB Arequest A

IDLClient

DSIORB B

request B

IDLObject

DII

commonprotocol

Dynamic Skeleton InterfaceDSI Dynamic Invocation InterfaceDII

9

17



• Communication using common protocols:

OMG defines 2 families of Common Protocols:- for generic usage: GIOP (General Inter ORB Protocol)→ protocol for general usage are derived of GIOP→ ex across Internet: IIOP (Internet Inter ORB Protocol)

- for specific usage in specific distributed environment: ESIOP(Environment Specific Inter ORB Protocols)

Client

ORB AIDL

ORB BIDL

Object

request

18


10

19

programmation en Corba

L’architecture objet globale (OMA)

Applicationinterfaces

Domaininterfaces

Commonfacilities

Objectservices

Object Request Broker

Object ManagementArchitecture (OMA) :une description, deuxsyntaxes …

Usuel

20



• Object services: - basic services, used by many applications- fixed interfaces → standard services- at less 16 basic services standardized:

naming, integrity, security, versions, transactions, …

• Object Request Broker (ORB):- distributed object bus (software bus)- realizes the request transport- hides (totally) the system heterogeneousness- allows easy access to distributed objects ……

11

21


L’architecture objet globale (OMA)• Common facilities:

- Or “CORBA facilities” or “Horizontal CORBA facilities”

- High level services common to many applications:- user interface components - printing and spooling- …

- Standardized

• Domain interfaces:- Or “Vertical CORBA facilities”

- Objects modeling domain activities: health, telecom, …- Also named business objects

- Standardized

22



• Application interfaces: - Or “Application objects”

- Business objects specific to an application- NOT standardized

- When stables and used by many applications:→ migrate to “Domain interface” (standard business objects)

12

23


24

• IDL n’est pas un language de programmation, seulement unlangage de description

• IDL permet de :- décrire des coopérations entre clients et serveurs- établir un “contrat” (agreement) entre clients et serveurs


Le langage IDL

IDLagreement

Clientstub

Objectskeleton

CORBA bus

13

25


Le langage IDLIDLagreement

Clientstub

Objectskeleton

CORBA busprojections

Les contrats IDL sont :• indépendants de l’environnement de développement• projetés dans des environnements de développement :

→ stubs coté clients→ skeleton coté serveurs

suivant des “règles de projection” (IDL → C++, IDL → Java, …)par le pré-compilateur IDL

• réalisés par : les stubs + le bus Corba (ORB) + les skeletons

26


Le langage IDLExemple de syntaxe IDL : définition d’un service de date (1)Module ServiceDate {

// Data type definitions// - basic type definitionstypedef unsigned short Day;

enum Month {January, February, March, April, May, June, JulyAugust, September, October, November, December};

typedef unsigned short Year;

// - One date (structure)struct Date {

Day the_day;Month the_month;Year the_year;

};

// - sequence: unlimited set of datestypedef sequence<Date> SomeDates;

14

27


Le langage IDL

// a first interface in the moduleinterface Calendar {

// attribute: object variables accessible from other// objects (possibility to be more accurate)attribute Year current_year;

// operations: object methods with input and output// parameters (possibility to be more accurate)boolean Check_one_date(in Date d);void the_day_after(inout Date d);

// definitions of specific exception(s)exception IrrelevantDate{String reason;};

// operations using exception(s)Date translate_string(in string one_string)

raises(IrrelevantDate);

string translate_date(in Date one_date)raises(IrrelevantDate);

};

Exemple de syntaxe IDL : définition d’un service de date (2)

28


Le langage IDL

// a second interface that inherits of the firstinterface CalendarWithOfficialHolydays : Calendar {

// one more operationvoid official_holydays(in Year the_year,

out SomeDates dates);

};

}; //end of the module

Exemple de syntaxe IDL : définition d’un service de date (3)

héritage

IDL : comme un langage structuré, avec des concepts « objet »

15

29


Le langage IDL

IDLagreement

C++ Client

C++ & IDL stub

Java Object

Java & IDL skeleton

CORBA bus

Règles de projection :

methodclasspackage

Java

…virtual methodoperation…structurestructure…namespacemodule

autre …C++IDL

Exemple de projection en C++ et Java

30


Le langage IDL

…

// Using namespace generated by IDL precompiler// to access IDL agreement datatype:ServiceDate::Date date;date.the_day = 01;date.the_month = ServiceDate::January;date.the_year = 2001;

// IDL precompiler generates pointer type on // module objects (corresponding to interfaces):ServiceDate::Calendar_var my_calendar = …;…

Exemple de client C++ exploitant un stub généré pour du C++

16

31


Le langage IDL

// import package generated by IDL precompiler:Import ServiceDate.*;

// usage of the CalendarWithOfficialHolydays IDL // interface:class MyCalendar

extends CalendarWithOfficialHolydaysImplBase {…

Date translate_string(String s) throws IrrelevantDate {ServiceDate.Date result = new ServiceDate.Date;

result.the_day = …;if (error in the string parsing) throw new IrrelevantDate(…);

return(result);};

…};

Exemple de client Java exploitant un stub généré pour du Java

32


17

33


34

• Utilisateurs et ressources distribués

• Utilisateurs variés• Ressources variées→ Services distribués

et variés


Exemple de déploiementLes besoins :

Mr. SmithInternet

(travel in Paris)

Central bankadministration

(Zurich)

Bank agencyAdministration

(London)

Bank agencyoffice

(London)

CORBA bus

Londonagency

Agence

Client xClient y

Std accountBankbook

Agencyserver

Centralbank

admin.

Bank

Bank server

18

35


Exemple de déploiementEtapes du développement

1 – Choix de la distribution et localisation des objets• Raisons techniques• Stratégie de sécurité• Raisons “politiques”

2 – Etapes de développement en Corba1 – Analyse et définition des contrats IDL2 – Pré-compilation des interfaces IDL3 – Projection dans des langages de programmation4 – Implantation des interfaces IDL5 – Implantation des serveurs (objets)6 – Implantation des clients7 – Installation et configuration des serveurs8 – Diffusion et configuration des exécutables clients9 – Exécution distribuée des services

36


Exemple de déploiementSolution overview Requirements

IDL agreements

Interfacerepository

Servercodes

Clientcodes

IDLstubs

Clientimplementation

IDLstubs

Objectcodes

IDL interfaceimplementation

IDL pre-compilation

Analyze and definition of IDL agreements

Projections

Various clientapplications

+ ++

Server implementation

1

2

3

4

5

6

Agencyserver

BankserverDescription of

install & config

Implementationrepository

7Server config& install

Directoroffice

Agencycounter

C.Cardcounter

Client executableconfig. & diffusion 8 CORBA

Bus

9Distributed exec. of the bank service

19

37


FINFIN

2A-SI – Réseaux : Programmation en...

Documents

Transcript of 2A-SI – Réseaux : Programmation en...