Vous êtes sur la page 1sur 63

Architecture des Systmes

Distribus
Yves LALOUM

Page 1

Yves LALOUM

1.Objectifs du cours

Page 2

Yves LALOUM

Faire un tour dhorizon des systmes


distribus et de leurs implmentations
actuelles :

Historique
Quest-ce quune Architecture Distribue ?
Le Client/Serveur
Les architectures Multi-tiers
Les Systmes dObjets distribus
Les implmentations : CORBA et COM

Page 3

Yves LALOUM

2. Historique
Lvolution des systmes dinformation :
Le systme centralis (mainframe) : annes 6070
Le Systme rparti : annes 80
Le Client/serveur : annes 80-90
Le Web (95)
Les objets distribus (95-2000)

Page 4

Yves LALOUM

Caractrisation des systmes centraliss :


Tous les traitements s effectuent sur un seul
systme
Operating system gnralement propritaire
Terminaux en mode caractre (dumb terminal)
Exemples : IBM MVS, GCOS BULL, VMS
DEC, Unix avec mulation de terminal
Page 5

Yves LALOUM

Avantages/inconvnients des
Systmes Centraliss
Avantages :
Scurit plus facile
grer
Cots d administration
faible par utilisateur
Centralisation des choix:
Installation
Mise jour
Utilisation des
applications

Inconvnients :
Interface utilisateur
difficile utiliser
Faible autonomie de
l utilisateur
Systmes propritaires
Difficile de migrer vers
un autre Systme

Page 6

Yves LALOUM

Caractrisation des systmes dcentraliss :


Les applications sont dcoupes en composants
s excutant sur des machines diffrentes
En gnral, une partie cliente et une partie
serveur. Modle Requte/rponse.
Downsizing : Dcentralisation des traitements
Data Distribution : Rpartition des donnes
Revamping : habillage d ancienne application
et relookage graphique
Apparition du MiddleWare

Exemples : RPC Microsoft, CTOS,


Requtes SQL
Page 7

Yves LALOUM

Avantages/inconvnients des
Systmes Dcentraliss
Avantages :
Rpartition des
traitements
Interface utilisateur plus
conviviale (graphique)
Trs grande autonomie
de l utilisateur
Meilleur performance
globale.
Donnes plus accessibles
en cas de pbs rseaux

Inconvnients :
Cot d administration
plus lev par utilisateur
Faible matrise des effets
d chelle
Dploiement des
applications plus
complique
fat client et gestion
des configurations
clients plus
problmatique

Page 8

Yves LALOUM

3. Quest ce quune architecture


distribue?
Une plate-forme pour construire des
applications
Dfinit les composants d un systme et leur
interaction
Permet de construire un systme complexe
partir dlments simples
Permet de construire un systme multiparties qui se comporte comme un tout
Page 9

Yves LALOUM

Les 5 composants logiques d une


application

La stratgie daffectation d un composant de


l application un systme dtermine son niveau
de distribution

Page 10

Yves LALOUM

Problmes lis la distribution


La complexit du fait de la multiplicit des
composants
L htrognit
Multiplicit des langages
Multiplicit des plates-formes

La distribution
Multiplicit des protocoles
Multiplicit des localisations possibles
La gestion du paralllisme et de la concurrence

L intgration
Multiplicit des technologies
Multiplicits des interfaces
Page 11

Yves LALOUM

4.Le Client/Serveur
Une architecture est dite client/serveur lorsque
lensemble des composants d une application est
rparti sur plusieurs entits systmes.
Les Architectures Clients/serveurs introduisent des
mcanismes permettant d effectuer des requtes
et des rponses travers le rseau.
Selon la dcomposition faite au niveau des
composants, la rpartition de charge peut tre plus
ou moins quilibre (voir schma suivant)

Page 12

Yves LALOUM

LALOUM:

Client

Serveur

Page 13

Yves LALOUM

Les Familles de Client/serveur


Le Client/Serveur de Prsentation distribue
et dporte :
Gestion de la prsentation sur le Client parfois
de manire simple (Telnet) parfois de manire
volue exemple (X-WINDOWS)

Le Client/Serveur de traitement
Gestion de la prsentation et du traitement sur
le Client (notion de fat client ) l accs aux
donnes s effectuant sur le serveur

Page 14

Yves LALOUM

Les services rseaux


("Middleware")
Rle : Assurer les changes de donnes entre un client
et un serveur en masquant les diffrents problmes
potentiels lis :
la rpartition des donnes et traitements
(accs distant, baisse de performance)
l'htrognit des matriels et des logiciels en
opration.

Page 15

Yves LALOUM

Les services rseaux


("Middleware")
Exemple de travail le plus frquent en client/serveur :
envoyer des requtes d'accs des donnes (type SQL)
d'un client vers un serveur et recevoir les rsultats :
Ouvrir une connexion entre entits
Envoi de requtes SQL vers le serveur
Conversion des formats de requtes
Excution des requtes
Envoi des rsultats
Conversion des rsultats
(Gestion des erreurs)
Fermeture de connexion.
Page 16

Yves LALOUM

Client/serveur : Schma de
principe
Poste client
Rponse
Requte

Poste client

Architecture Rponse
de communication

Requte

Rseau
"Middleware"

Requte
Rponse

Poste serveur
Page 17

Yves LALOUM

API ("Application Programming


Interface")
Programme
client
Interprteur de
requtes

IPA API
Communications

SGBD
Serveur de
requtes

IPA API
Communications

Page 18

Yves LALOUM

Appel de procdure distante :


Remote Procdure CALL RPC
C'est une ralisation du mode client-serveur.
L'opration raliser est prsente sous la forme d'une
procdure que le client peut faire excuter distance par
un autre site : le serveur
Exemple de service RPC:

Page 19

TYPE COM_APPEL_PROCEDURE_DISTANTE;
/* Transforme un appel local en appel distant */
METHOD genere_appel (id_emet, id_recept
nom_procedure, paramtres);
/* Recoit un appel distant et l'excute localement */
METHOD traite_appel (id_emet, id_recept
nom_procedure, paramtres);
METHOD ...;
END COM_MESSAGE_ASYNCHRONE.
Yves LALOUM

RPC par change de messages


Le premier message correspondant la requte est celui
de l'appel de procdure, porteur des paramtres d'appel.
Le second message correspondant la rponse est celui du
retour de procdure porteur des paramtres rsultats.

Appel(p_in)
n_proc(p_in,
p_out);
Retour(p_out)

CLIENT

procedure n_proc
(p_in,p_out)
Debut
Fin

SERVEUR

Page 20

Yves LALOUM

10

Client/serveur : Les souches ou "Stubs"


Souche Client : Cest la procdure dinterface du
site client :
qui reoit lappel en mode local
le transforme en appel distant en envoyant un message.
reoit les rsultats aprs l'excution
retourne les paramtres rsultats

Souche Serveur : Cest la procdure sur le


site serveur qui:
reoit lappel sous forme de message,
fait raliser lexcution sur le site serveur par la procdure serveur
retransmet les rsultats par message.
Page 21

Yves LALOUM

Les dix tapes de traitement


client
1

serveur
6

10

souche client
2

souche serveur
7

3
transport client

transport serveur
8

Page 22

Yves LALOUM

11

Etape 1 :

Dtail des tapes

Le client ralise un appel procdural vers la procdure


souche client.
La souche client collecte les paramtres , les assemble
dans un message (parameter marshalling).

Etape 2
La souche client dtermine ladresse du serveur.
La souche client demande une entit de transport
locale la transmission du message d'appel.

Etape 3
Le message est transmis sur un rseau au site serveur.
Page 23

Yves LALOUM

Dtail des tapes


tape 4 : Le message est dlivr la souche du serveur.
tape 5 : La souche serveur:dsassemble les paramtres, et
ralise lappel effectif de la procdure serveur.

tape 6 : La procdure serveur ayant termin son excution


transmet la souche serveur dans son retour de procdure les
paramtres rsultats.
La souche serveur collecte les paramtres retour, les assemble
dans un message (parameter marshalling).

Page 24

Yves LALOUM

12

Dtail des tapes


tape 7 : La procdure souche serveur demande lentit de
transport locale la transmission du message.

tape 8 : Le message est transmis sur un

rseau au site

client.

tape 9 : Le message est dlivr la souche du client.


La souche client dsassemble les paramtres retour.

tape 10 :- La procdure souche client transmet les rsultats


au client en effectuant le retour final de procdure.

Page 25

Yves LALOUM

Appel de procdure distante et gestion


squentielle ct serveur
Cot serveur
Serveur unique

souche serveur

Liste
des
appels
en
attente

Exemple :
RPC SUN : requtes non ordonnes, traitement squentiel.
Page 26

Yves LALOUM

13

Appel de procdure distante et gestion


du paralllisme cot serveur
Serveur client 1

Serveur client 2

Serveur client 3

souche serveur

transport serveur

Dans ce mode le serveur cr une activit (un processus lger ou


thread) par appel. Les appels sont excuts concurremment.
Page 27

Yves LALOUM

Le traitement ct le client : appel


synchrone
L'excution du client est suspendue tant que la
rponse du serveur n'est pas revenue ou qu'une
condition d'exception n'a pas entran un traitement
spcifique.
Appel
lire(...)
client bloqu

CLIENT

Retour

procedure lire
Debut
serveur actif
Fin

SERVEUR

Remarque :le client pourrait faire quelque chose


pendant l'excution du serveur reste inactif.
Page 28

Yves LALOUM

14

Le traitement ct client : appel


asynchrone
Le client poursuit son excution aprs l'mission du message
porteur de l'appel.
La procdure distante s'excute en parallle avec la poursuite
du client et retourne ses paramtres rsultats en fin.
Le client rcupre les rsultats en retour quand il en a besoin.

Appel
lire(...)
client
actif

Retour

procedure lire
Debut
serveur actif
Fin

rcupration
des rsultats
Page 29

CLIENT

SERVEUR

Yves LALOUM

Client/serveur:Applications
types.
Transactionnel
OLTP "On Line Transaction Processing"Les
applications comportent :
des oprations d'accs en lecture criture des
bases de donnes,
des traitements
des affichages en mode graphique sur des postes
de travail.

Page 30

Yves LALOUM

15

Client/serveur:Applications
types.
Aide la dcision :
EIS/DS "Executive Information
System/Decision Support")
Les applications comportent:
des accs complexes bases de donnes,
des traitements de synthse/valorisation
des affichages (tableaux, histogrammes etc)

Page 31

Yves LALOUM

Inconvnients du Client/serveur
Cot dadministration lev :
Les applications doivent tre redployes
chaque modification
Augmentation des cots de support au niveau
client cause de la logique du fat client
Systmes dexploitation clients multiples et
incompatibles
Engorgement du rseau d aux accs bases de
donnes
Les applications client-serveur montre des
faiblesses quand lchelle monte : engorgement
du serveur
Page 32

Yves LALOUM

16

5. Les Architectures Multi-tiers


Tier= niveau
Le client serveur 3 niveaux 3-tiers
On parle de Multi-tiers lorsque les entits
applicatives sont rparties sur plusieurs
serveurs avec un middleware permettant la
coopration des composants.
Exemple :
client web

Serveur HTTP

Serveur de
base de donnes

HTTP
Page 33

Yves LALOUM

Architecture Multi-Tiers
Permet une distribution gnralise des
composants.
Permet une prise en compte des effets
d chelle par multiplication des plateformes de traitements
Permet de minimiser les ressources au
niveau client d o :
Un cot d administration moins lev
L utilisation de clients lgers (Navigateur+applets
Java)
Page 34

Yves LALOUM

17

Architecture par composants

Page 35

Yves LALOUM

Problmes poss par le multitiers


Problme de la localisation :
Lorsquon rpartit les traitements sur plusieurs
serveurs, se pose le problme de l adressage et
de la localisation des composants

Problme de lhtrognit des platesformes et des services


Ncessit de dfinir des normes et des
standards de coopration (CORBA, COM)

Page 36

Yves LALOUM

18

6. Les systmes dobjets


distribus
Une structuration des applications qui place la notion
d'objet au centre de la conception: performante et de plus
en plus utilise
Objet: associe les traitements et les donnes en rendant
les codes moins coteux dvelopper, maintenir,
rutiliser.
Abstraction : Comportements communs => Typage.
Encapsulation : Association des actions aux donnes.
Hritage : Rutilisation du code.
Polymorphisme : Rutilisation des rfrences.

Page 37

Yves LALOUM

Intgration de la notion d'objet au systme


rparti :La distribution
Les communications rseau offrent la possibilit d'implanter les
objets de faon homogne sur les sites d'un systme rparti.
L'interface du systme d'objets rpartis est un ensemble de
primitives ou un langage objet concurrent et rparti
=> offrant la possibilit d'implanter et d'excuter la
demande des objets (donne,traitement) sur des sites
quelconques.

Cration distance d'instances


Excution distance des mthodes.
Concurrence/synchronisation .
Autres fonctions: transactionnel, scurit, optimisation du placement ...

Page 38

Yves LALOUM

19

Qu'est-ce qu'un objet?


C'est l'encapsulation au sein d'une mme entit des
donnes et des traitements.
L'objet est manipulable, dans son contexte, au travers de
son interface.
Donnes

Interface

Methode M1

Methode M2

Objet O

Page 39

Yves LALOUM

Quest ce quun objet rparti ?


Les services offerts par l'objet sont
accessibles indpendamment de sa
localisation.
Donnes
Mthode M1

Donnes

Mthode M2

Mthode M3

M3
Objet O2

Objet O1
Site S1

Site S2

Page 40

Yves LALOUM

20

Pour faire quoi?


L'objectif : Dcomposer une application complexe en
un ensemble de processus cooprant les uns avec les
autres, ces processus pouvant tre situs sur des machines
diffrentes
Avoir une structure ouverte, o des machines peuvent
se connecter pendant l'excution d'une application.

Solution : Face la complexit du dveloppement de


tels systmes et afin de les structurer deux approches
ont t gnralement retenues.

Page 41

Yves LALOUM

Comment le faire ?
Approche applique :

Appliquer les concept de la programmation par objets


(encapsulation, hritage..)

Dcomposer le systme rparti en bibliothque de


classes Ex :Services CORBA, COM+
Approche intgration :
Intgrer les notions de rpartition lobjet
Objets distances : Invocation dobjets distance
(bus Corba, bus Com+)
Objets mobiles : Copies de lobjet serveur chez le
client (ActiveX, Java)
Objets synchroniss
Page 42

Yves LALOUM

21

Les systmes dobjets


distribus : Schma de principe
Interface
OBJET

ORB
ORB : Object Request Broker

Page 43

Yves LALOUM

Un enjeu technologique majeur


Situation actuelle: l'htrognit
de dsignation, de protection, d'interface
complexit de la programmation des applications
particulirement en univers rparti (htrogne).
Projet : simplifier et uniformiser les accs et les
communications offerts par les interfaces systmes et
les codes utilisateurs
Uniformisation des abstractions utilises sous le
concept objet
Dsignation universelle
Interactions de communication simplifies
protection et scurit universelle
Page 44

Yves LALOUM

22

Un enjeu pour la normalisation


Standardiser l'offre systmes d'objets rpartis pour intgrer
des systmes d'origine diffrentes dans une application:
La normalisation minimum habituelle par les protocoles
(standardiser les interactions):
=> interoprabilit entre des implantations
unifier les techniques d'appel distant
accder des annuaires communs d'objets.

Puis standardiser les langages et techniques de dveloppement


...=> portabilit des applications

OMG "Object Management Group"


CORBA "Common Object Request Broker Architecture
Microsoft OLE/DCOM "Object Link /Embedding /"Distributed
Component Object Model"

Page 45

Yves LALOUM

Middleware OBJET
Prsentation de larchitecture
CORBA
Common Object Request Broker Architecture
Yves LALOUM

Page 46

Yves LALOUM

23

1.Introduction
Depuis 1989, une association internationale l OMG (Object
Management Group) dfinit la spcification de l'architecture d'un
systme objets rpartis, appele CORBA (Common Object
Request Broker Architecture /Architecture darbitrage de
demande d'objets commun).
CORBA est n du besoin de faire communiquer ensemble des
applications en environnement htrogne (plusieurs systmes et
plusieurs langages).
CORBA associe les concepts d'objet et de rpartition dans une
approche la fois intgre et applique.

Page 47

Yves LALOUM

Introduction

L'intgration se fait travers la notion d'invocation distance d'objet (


l'objet est l'unit de rpartition), et l'application se fait travers les
services de rpartition qui sont organiss sous forme de bibliothques
de classes.

Dates importantes :
1991 CORBA 1.1 Dfinition de lInterface Definition
Language (IDL)
et Application Programming Interfaces (API) interaction avec
limplmentation de l Object Request Broker (ORB).
1995 CORBA 2.0 Interoprabilit entre ORB et le protocole
IIOP

Page 48

Yves LALOUM

24

2. L OMG (Object Management


Group)
Un consortium international but non lucratif fond en
Avril 1989
Plus de 900 membres (diteurs de logiciels,
constructeurs, utilisateurs)
Bas aux Etats-Unis avec des reprsentants dans le
monde entier
Est financ 95 % par ses membres et 5% par
l dition douvrages

Un site : HTTP://www.omg.org
Page 49

Yves LALOUM

OMG: Les objectifs


Fixer une dfinition du paradigme objet
vise promouvoir les technologies orientes objets pour la
conception d'applications informatiques distribues,
interoprables et ouvertes.
Spcifier seulement les interfaces : laisser la concurrence
ouverte pour les implmentations
Supporter de multiples langages (pas seulement Java et
C++)
Promouvoir ses choix technologiques (publications,
forums, confrences, sminaires,formation.)
Dfinir lObject Management Architecture Guide (OMA)
son modle d'objets distribus et interoprables.

Page 50

Yves LALOUM

25

OMA Object Management


Architecture
Il dfinit larchitecture de gestion des objets et contient le
fondement des standards :
Le modle objet abstrait
le modle de rfrence
Un glossaire des termes utiliss

Il regroupe essentiellement 4 composants :

Le modle objet
Corba Facilities
Corba Domains
Corba Services

Page 51

Yves LALOUM

OMA Object Management


Architecture Les composants
CORBA Services :
Services dobjet commun
CORBA Facilities :
Utilitaires Communs
CORBA Domains :
Interfaces de domaine.
Application Objects :
Objets applicatifs

Page 52

Yves LALOUM

26

CORBA Services :
les services objet communs (Common Object Services)
proposent des services horizontaux pour faciliter
l'utilisation courante des objets CORBA.
Naming Service : Le service Nommage est lquivalent
des pages blanches
les objets sont dsigns par des noms symboliques.
Cet annuaire est matrialis par un graphe de
rpertoires de dsignation.
Trader Service : Le service Vendeur est lquivalent des
pages jaunes les objets peuvent tre recherchs en
fonction de leurs caractristiques.

Page 53

Yves LALOUM

CORBA Services
Life Cycle Service : Le service Cycle de Vie dcrit des
interfaces pour la cration, la copie, le dplacement et la
destruction des objets sur le bus. Il dfinit pour cela la
notion de fabriques dobjets (Object Factory).
Properties Service : Le service Proprits permet aux
utilisateurs dassocier dynamiquement des valeurs
nommes des objets. Ces proprits ne modifient pas
linterface IDL, mais reprsentent des besoins spcifiques
du client comme par exemple des annotations.
Relationship Service : Le service Relations sert grer
des associations dynamiques (appartenance, inclusion,
rfrence, auteur, emploi,...) reliant des objets sur le bus. Il
permet aussi de manipuler des graphes dobjets.

Page 54

Yves LALOUM

27

CORBA Services
Externalization Service : Le service Externalisation
apporte un mcanisme standard pour fixer ou extraire des
objets du bus. La migration, le passage par valeur, et la
sauvegarde des objets doivent reposer sur ce service.
Persistent Object Service : Le service Persistance offre
des interfaces communes un mcanisme permettant de
stocker des objets sur un support persistant. Un objet
persistant doit hriter de linterface Persistent Object et
dun mcanisme dexternalisation.
Object Query Service : Le service Interrogations permet
dinterroger les attributs des objets. Il repose sur les
langages standards dinterrogation comme SQL3 ou OQL.

Page 55

Yves LALOUM

Corba Services
Collection Service : Le service Collections permet de
manipuler dune manire uniforme des objets sous la
forme de collections et ditrateurs.
Versionning Service : Le service Changements permet de
grer et de suivre lvolution des diffrentes versions des
objets. Ce service maintient des informations sur les
volutions des interfaces et des implantations.
Security Service : Le service Scurit permet didentifier
et dauthentifier les clients, de chiffrer et de certifier les
communications et de contrler les autorisations daccs.
Ce service utilise les notions de serveurs
dauthentification, de clients/rles/droits (et dlgation de
droits), dIIOP scuris (utilisant Kerberos ou SSL).

Page 56

Yves LALOUM

28

CORBA Services
Object Transaction Service : Le service Transactions assure
lexcution de traitements transactionnels impliquant des objets
distribus et des bases de donnes en fournissant les proprits
Atomicit, Cohrence, Isolation, Durabilit.
Concurrency Service : Le service Concurrence fournit les
mcanismes pour contrler et ordonnancer les invocations
concurrentes sur les objets. Le mcanisme propos est le verrou.
Ce service est conu pour tre utilis conjointement avec le
service Transactions.
Event Service : Le service Evnements permet aux objets de
produire des vnements asynchrones destination dobjets
consommateurs travers des canaux dvnements.

Page 57

Yves LALOUM

CORBA Services
Notification Service : Dans Le service Notification les
consommateurs sont uniquement notifis des vnements
les intressant.
CORBA Messaging [OMG-CM] :Le service Messagerie
dfinit un nouveau modle de communication asynchrone
permettant de grer des requtes persistantes lorsque
lobjet appelant et lobjet appel ne sont pas prsents
simultanment sur le bus.
Time Service : Le service Temps fournit des interfaces
permettant dobtenir une horloge globale sur le bus
(Universal Time Object), de mesurer le temps et de
synchroniser les objets.
.
Page 58

Yves LALOUM

29

CORBA Services
Licensing Service : Le service Licences permet de
mesurer et de contrler lutilisation des objets, et cela en
vue de facturer les clients et de rmunrer les fournisseurs

Page 59

Yves LALOUM

CORBA Facilities
les utilitaires communs dfinissent un cadre de haut niveau
pour la cration de logiciels l'aide de composants
rutilisables.
la gestion des tches
flux d activits (workflow)
gestions des transactions

l'interface utilisateur
gestion du rendu . Gestion du bureau
affichage & dialogue utilisateur - prsentation de l environnement
gestion des documents composites .
Scripts support de l utilisateur

Page 60

Yves LALOUM

30

CORBA Facilities
la gestion de l'information
modlisation . change
rgles de structuration, manipulation - GIF, JPEG, HTML,
stockage structur . Codage et reprsentation
archivage de l information - physique de l information

l'administration systme
instrumentation . Ordonnancement
collecte d informations - traitement rptitif + vnements
collecte des donnes . scurit
journal d utilisation - politique de scurit
qualit du service . gestions des vnements
suivi d instance

Page 61

Yves LALOUM

Les interfaces de domaines


CORBA
les interfaces de domaines concernent des marchs
verticaux
ils dfinissent des interfaces spcialises
rpondant aux besoins spcifiques dun march . Il
sont dtermins au sein de groupes de travail
nomms selon les cas :
Working Groups
Domain Task Forces
Special Interest Groups
..
Page 62

Yves LALOUM

31

Les interfaces de domaines


CORBA
Quelques exemples :

Page 63

Business Objects DTF pour la conception


dapplications mtier au dessus de CORBA.
CORBAmed dfinit les standards OMG pour le
domaine de la mdecine. Ces standards permettront
linteroprabilit entre les acteurs de la sant en
dfinissant par exemple la notion dobjets patient.
Telecom DTF fait la liaison entre le monde CORBA et
le monde des tlcommunications.
Internet Platform SIG travaille sur les rapprochements
des technologies CORBA avec les technologies
dInternet. Il tudie principalement les relations avec le
World Wide Web.
Yves LALOUM

OBJETS Applicatifs :
Les objets applicatifs sont ceux qui sont
spcifiques une application rpartie et ne
sont donc pas standardiss.
Toutefois, ds que le rle de ces objets
apparat dans plus dune application ils
peuvent alors rentrer dans une des
catgories prcdentes et donc tre
standardiss par lOMG.

Page 64

Yves LALOUM

32

BUS DOBJETS DISTRIBUES

Page 65

Yves LALOUM

BUS DOBJETS DISTRIBUES


Cest le cadre visible que doivent respecter les
dveloppeurs de bus CORBA.
Il correspond lapproche intgre du modle
Il assure le transport des requtes entre tous les
objets CORBA.
Il offre un environnement dexcution aux objets
masquant lhtrognit lie
Aux langages de programmation,
Aux systmes dexploitation,
Aux processeurs et aux rseaux.

Page 66

Yves LALOUM

33

BUS DOBJETS DISTRIBUES


Le bus CORBA est donc
lintermdiaire/ngociateur travers lequel les
objets vont pouvoir dialoguer.
Il fournit les caractristiques suivantes :
La liaison avec tous les langages de programmation :
cependant, actuellement lOMG a seulement dfini officiellement
cette liaison pour les langages C, C++, SmallTalk, Ada, COBOL et
Java
La transparence des invocations : les requtes aux objets semblent
toujours tre locales, le bus CORBA se chargeant de les acheminer
en utilisant le canal de communication le plus appropri.

Page 67

Yves LALOUM

BUS DOBJETS DISTRIBUES


Niveau du processus : les objets sont dans le mme
espace mmoire que les clients. Cest le cas typique des
applications embarques.
Ici, le langage OMG-IDL sert spcifier les objets.

Niveau de lOS : les clients et les fournisseurs sont des


processus diffrents sur la mme machine.

Le bus CORBA peut alors tre tout ou partie du


systme dexploitation
Niveau du rseau : les processus sont sur des sites
diffrents et les requtes sont vhicules travers le
rseau.
Cest le cas sur Internet avec IIOP

Page 68

Yves LALOUM

34

Linvocation statique et
dynamique
Ces deux mcanismes complmentaires permettent de
soumettre les requtes aux objets.
En statique, les invocations sont contrles la
compilation.
En dynamique, les invocations doivent tre contrles
lexcution.

Page 69

Yves LALOUM

Linvocation statique et
dynamique
Un systme auto-descriptif : les interfaces des objets sont connues
du bus et sont aussi accessibles par les programmes par
lintermdiaire du rfrentiel des interfaces.
Activation automatique et transparente des objets : les objets sont
en mmoire uniquement sils sont utiliss par des applications
clientes.
Linteroprabilit entre bus : partir de la norme CORBA 2.0, un
protocole gnrique de transport des requtes (GIOP pour General
Inter-ORB Protocol) a t dfini permettant linterconnexion de bus
CORBA provenant de fournisseurs distincts
une de ses instanciations est lInternet Inter-ORB Protocol (IIOP)
fonctionnant au dessus de TCP/IP.

Page 70

Yves LALOUM

35

OMG Interface Definition Language


(OMG IDL)
Il est utilis pour dcrire les interfaces des objets
distribus.
Sparation de l'interface d'un objet de son
implmentation.
Il permet de dfinir dans un langage commun l'ensemble
des compilateurs, les partie visible d'un objet (mthodes ,
proprits).
langage de description d'interfaces totalement indpendant
de tout langage de programmation :
Quelque soit limplmentation (Java ou C++) le fichier
IDL correspondant aux interfaces crites dans les deux
langages sera identique.

Page 71

Yves LALOUM

OMG Interface Definition Language


(OMG IDL)
Les clients interagissent avec les objets locaux et
distants en invoquant les mthodes dfinies dans le
fichier IDL
IDL est un langage de description (ressemblant au C).
Exemple dinterface IDL :
// CompteClient.idl
interface Compte client {
void credit ( in unsigned long montantFRF );
void debit ( in unsigned long montantFRF );
long solde ( );
};

Page 72

Yves LALOUM

36

IDL: PROJECTION
La projection (ou mapping) : La projection permet de
gnrer du code pour exploiter le type d'objet partir d'un
langage de programmation. Ce mcanisme est dpendant
du langage cible.

Ralise par un pr-compilateur IDL dpendant du


langage cible et du bus CORBA cible.

Page 73

Yves LALOUM

IDL:STUB / SKELETON:
Avec l'aide d'un compilateur IDL (IDL
COMPILER) et de vos fichiers idl on gnre :
une souche (stub) pour le client un squelette
(skeleton) pour le serveur.
On programme l'implmentation de la classe
serveur qui doit hriter du squelette gnr par idl.
Une fois les programmes clients et serveurs
compils, l'ORB prendra en charge le
pliage/dpliage des requtes des clients sur les
objets locaux et distants.

Page 74

Yves LALOUM

37

IDL:STUB / SKELETON:

Page 75

Yves LALOUM

Les Objets du Bus dobjets Distribus :


ARCHITECTURE GENERALE

Page 76

Yves LALOUM

38

Les Objets du Bus dobjets Distribus :


Les diffrents objets
Interface Repository ou IR :cest le rfrentiel des
interfaces contenant une reprsentation des interfaces
OMG-IDL accessible par les applications durant
lexcution.
L ORB doit avoir accs la dfinition de l'objet qu'il gre;
cela peut se faire de deux faons:
l'information est contenue dans la requte
l'ORB prend cette information dans l' interface Repository

Permet galement, en utilisant les informations de l'


interface Repository, dterminer l'excution les
oprations ralisable sur un objet dont l'interface n'tait pas
connue la compilation.

Page 77

Yves LALOUM

Les Objets du Bus dobjets Distribus :


Les diffrents objets
Implementation Repository :Rfrentiel des
implantations
 Il contient linformation ncessaire lactivation.
 Ce rfrentiel est spcifique chaque produit CORBA.

II contient aussi des informations


supplmentaires comme par exemple des
informations sur le debugging, la scurit,...

Page 78

Yves LALOUM

39

Les Objets du Bus dobjets Distribus :


Les diffrents objets

Page 79

Yves LALOUM

Les Objets du Bus dobjets Distribus :


Les diffrents objets

OBJ REF :La rfrence de l'objet est l'information


ncessaire pour dsigner sans ambigut cet objet dans un
ORB.
Le client et l'implmentation de l'objet ont une notion
opaque de la rfrence de l'objet au travers de leur langage.
La reprsentation d'une rfrence d'objet fournie un client
n'est plus valable la mort du client.
Un objet peut avoir plusieurs rfrences d'objet. Deux
ORB diffrents peuvent avoir des reprsentations de
rfrence d'objet diffrentes :
LIOR (Interoperable Object Reference) resoud cette
ambigut. Il contient notamment l adresse machine

Page 80

Yves LALOUM

40

Les Objets du Bus dobjets Distribus :


Les diffrents objets
IDL STUBS : SII (Static Invocation Interface) :
Interface dinvocations statiques
permet de soumettre des requtes contrles la
compilation des programmes. Cette interface est
gnre partir de dfinitions OMG-IDL.

IDL SKELETON : SSI (Skeleton Static


Interface) Interface de squelettes statiques
il permet limplantation des objets de recevoir les
requtes leur tant destines. Cette interface est gnre
partir de dfinitions OMG-IDL

Page 81

Yves LALOUM

Les Objets du Bus dobjets Distribus :


Les diffrents objets
DII (Dynamic Invocation Interface) : Interface
dinvocations dynamiques
permet de construire dynamiquement des requtes vers
nimporte quel objet CORBA sans gnrer/utiliser une
interface SII.

DSI (Dynamic Skeleton Interface) : Interface de


squelettes dynamiques
Il qui permet dintercepter dynamiquement toute
requte sans gnrer une interface SSI.
Cest le pendant de DII pour un serveur.

Page 82

Yves LALOUM

41

Les Objets du Bus dobjets Distribus :


Les diffrents objets
Object Adapter : Ladaptateur dobjets
" Canal " par lequel l'ORB est connecte
l'implmentation de l'objet.
Il soccupe de crer les objets CORBA,
de maintenir les associations entre objets CORBA
et implantations
de raliser lactivation automatique si ncessaire.

Page 83

Yves LALOUM

Les Objets du Bus dobjets Distribus :


Les diffrents objets

les services de l Object Adapter :


 gnration et interprtation de rfrences d'objet
 invocation des mthodes
 scurit de l'interaction
 activation et dsactivation des objets
 correspondance des rfrences d'objet aux implmentations
 liste des implmentations
 etc...

la norme CORBA 2.0 introduit le BOA ou Basic Object Adapter dpendant du


type d ORB. Pour rsoudre les problmes dinteroprabilit le POA ou
Portable Object Adapter a t introduit .

Page 84

Yves LALOUM

42

Les Objets du Bus dobjets Distribus :


Les diffrents objets
ORB INTERFACE : Linterface au bus fournit
les primitives de base comme linitialisation de
lORB.
permet de contrler le comportement du bus,
de crer les autres objets reprsentant les composantes
du bus,
de convertir les rfrence dobjet fournit par le bus en
chane de caractres et vice-versa
et dobtenir les rfrences des objets notoires

Page 85

Yves LALOUM

Les Objets du Bus dobjets Distribus :


Les diffrents objets
Object Request Broker (ORB). Le cur de
CORBA est constitu par l'ORB qui est le
conduit/bus par lequel les requtes sur les objets
transitent.
Noyau de transport des requtes aux objets.
Il intgre au minimum les protocoles GIOP et
IIOP.
LORB n'est pas directement accessible au
programmeur d'applications CORBA qui n'utilise
qu'une rfrence.

Page 86

Yves LALOUM

43

Les Objets du Bus dobjets Distribus :


Les diffrents objets
Le protocole GIOP (General Inter-ORB
Protocol ) dfinit :
une reprsentation commune des donnes CDR ou
Common Data Representation
un format de rfrences dobjet interoprables (IOR ou
Interoperable Object Reference)
un ensemble de messages de transport des requtes aux
objets (Request, Reply, ).
Cependant, GIOP est seulement un protocole gnrique

Page 87

Yves LALOUM

Les Objets du Bus dobjets Distribus :


Les diffrents objets
IIOP (Internet Inter-ORB Protocol) :
IIOP fournit une implantation de GIOP au dessus de
TCP/IP et donc dInternet.
Les IORs (dans le contexte dIIOP) doivent contenir :
le nom complet de linterface OMG-IDL de lobjet
ladresse IP de la machine Internet o est localis lobjet ;
un port TCP pour se connecter au serveur de lobjet ;
une cl pour dsigner lobjet dans le serveur.

Son format est libre et il est donc diffrent pour chaque


implantation du bus CORBA.

Page 88

Yves LALOUM

44

Les diffrents produits la norme


CORBA
VISIBROKER Commercial(BORLAND)
MICO Gratuit suite CORBA
c'est un produit de trs bonne qualit qui peut rivaliser avec des bus commerciaux.
ROBIN
Java.

gratuit

CORBA 2 / freeware de bonne qualit implment en

ORBACUS

gratuit pour une utilisation non commerciale.

CORBA 2

XEROX ILU gratuit Outil trs puissant mais plus complexe utiliser que les
prcdents et qui fait partie du projet Inter-Language Unification de Xerox.
CORBAScript gratuit Ce langage interprt permet l'utilisation d'objets
CORBA par simples scripts

Page 89

Yves LALOUM

EN CONCLUSION
CORBA est une solution ouverte et volutive avec
architecture est modulaire :
Attention ne pas tomber dans le piges tendus par les
fournisseurs de bus : il faut viter dutiliser les mcanismes
propritaires d un fournisseur particulier.
Ces spcifications sont implantes dans des produits
Corba ready .
Toujours choisir le produit CORBA le plus appropri
chaque partie dune application : un produit offrant le POA
pour crire des serveurs C++ portables et un produit
offrant la projection IDL/Java pour les applications clientes
utilises travers le WWW.

Page 90

Yves LALOUM

45

Bibliographie CORBA
Common Object Services Specification :
OMG, 1997

CORBA 3 - Fundamentals and


Programming De Jon Siegel - Wiley

Page 91

Yves LALOUM

Middleware OBJET
Prsentation de larchitecture COM
Component Object Model
DCOM/ACTIVEX
Yves LALOUM

Page 92

Yves LALOUM

46

1.Introduction

Les services de composant COM+ constituent un cadre gnral


logiciel de COM conues pour grer des composants logiciels
Ces services sont intgrs partir de Windows 2000 ( NT5)
COM+ est le rsultat dune lente volution qui dbuta en 1990
1990 OLE/OLE 2 (Object Linking & embedding): Architecture
de base de Windows. Permet la coopration Multi-Utilisateurs
(documents composites)
1992 COM (Component Object Model) est livr avec
Windows98 et Windows NT 4.0. Cur de OLE2. Base de
l'Internet aussi.
1996 DCOM est la version pour les objets Distribus. Il Permet
un composant de se "dplacer" et de s'excuter sur une autre
machine.
Page 93

Yves LALOUM

Introduction
1996: ActiveX version Internet d'accs aux objets
COM/DCOM. Les contrles ActiveX permettent de
faciliter la distribution des composants travers l'Internet,
et d'intgrer DCOM sur le navigateur Web.
1997 MTS (Microsoft Transaction Server):
C'est le modle de serveurs d'objets COM ddi aux applications
transactionnelles.
C'est en fait un environnement o tournent les composants
(Runtime environment)
Il regarde les requtes arriver aux composants et participe leur
excution.
Il fournit : la scurit, la gestion des transactions et celle de la
rpartition des charges.

1998 Dbut de COM+

Page 94

Yves LALOUM

47

2. Modle COM
Le Component Object Model est un standard
publi est conu par Microsoft pour Microsoft
Il implmente des connexions entre les
diffrents composant logiciels : cest un bus
logiciel
Il est indpendant du langage de
programmation, du systme dexploitation et de
la plate-forme

Page 95

Yves LALOUM

Caractristiques des objets COM


Pour utiliser COM dans un programme, il faut
implmenter des objets COM Qui ont les
caractristiques suivantes :
Encapsulation :
un objet COM est un paramtrage de donnes et /ou de
fonctions enveloppes dans une entit identifiable
unique.
Tout ce qui se trouve dans un objet COM est cach de
lextrieur de lobjet a lexception des interfaces

Page 96

Yves LALOUM

48

Caractristiques des objets COM


Les interfaces :
IID (Interface Identifier) : IID est un type de GUID (Globally
Unique Identifier) entier de 16 octets qui permet didentifi
 Le nombre de fonctions dans la table
 leur ordre
 leurs signatures
Les trois premires mthodes dune interface sont prdfinies, en
signature comme en signification
 QueryInterface(): Ngociation dinterface pour la
dcouverte dynamique
 Addref() et Release(): Comptage de rfrence pour la
gestion de la dure de vie de lobjet

Page 97

Yves LALOUM

Support de COM par le systme


dexploitation
COM implique l'existence de code au niveau de l'OS de
la machine.
Ce code forme le middleware , structur sous la
forme d'une bibliothque (ralise par des DLLs ou
EXE).
Cette bibliothque comporte entre autres :
L'API de COM, form par un petit nombre de
fonctions accessibles par le client et le serveur.
Le Service Control Manager (ou SCM) : qui localise
les serveurs des classes a l'aide des CLassId de la
base registre.
L'appel de procdure distante par RPC: lorsque
l'objet et le client ne sont pas au mme endroit
Page 98

Yves LALOUM

49

Support de COM par le systme


dexploitation
Ces bibliothques fournissent un support pour :
Identification : identifier les programmes qui veulent
implmenter un type dobjet (ClassId dans la base de
registre)
Instanciations : Instancier lobjet voulu dans un module
diffrent de celui du client
Marshalling : accder indirectement aux interfaces dun
objet COM

Les fonctions et les objets COM qui communiquent avec le systme


dexploitation utilise des chanes UNICODE

Page 99

Yves LALOUM

Hirarchie de COM

Remarque : le rle des Apartments (Appartement) est


dimplmenter la scurit des threads
Page 100

Yves LALOUM

50

Caractristiques des objets COM


Polymorphisme : Cest la possibilit pour un objet de
rpondre correctement aux mmes demandes en entre que
dautre objets diffrents

Rutilisation ou hritage : Uniquement au niveau de


leurs interfaces
Mode inclusion : un objet COM peut en rutiliser un autre
uniquement en tant que client travers ses interfaces. Lobjet
rutilis effectue une partie du travail
Mode agrgation : Un objet COM peut demander un autre objet
COM quil devienne une partie de lui-mme.

Page 101

Yves LALOUM

Quelques dfinitions
Un client est une squence de code, faisant appel
au service d'un objet.
Un serveur est un code associ une classe
d'objets identifie par son CLSID unique.
Il doit implmenter un objet de class COM qui
permet de crer des objets dynamiquement
(Class Factory)
MARSHALLING : Extensibilit de COM
Dfinition : Assemblage (Marshalling) : Procd
consistant prendre une collection de paramtres,
les arranger et les coder en format externe pour
constituer un message mettre

Page 102

Yves LALOUM

51

Schmas de principe

Page 103

Yves LALOUM

Schmas de principe :
commentaires
Un objet peut tre dans un process diffrent (en local ou
sur une machine distante) .
Dans ce cas :
le marshalling utilise un interface-spcifique
proxy/stub (sous forme dune DLL gnrer a
partir dun fichier IDL) et un mcanisme RPC.
le Microsoft Interface Definition Language (MIDL) est
un compilateur qui peut tre utilis a partir dun fichier
IDL pour gnrer automatiquement le code ncessaire aux
invocations distance.
La DLL doit tre implmente ct serveur et
ct client.

Page 104

Yves LALOUM

52

Proxy :

Stub et Proxy

Il reprsente lobjet ct client


Il expose les interfaces de lobjet
Il sait comment communiquer avec le Stub

Stub:
Il reprsente le client ct objet
Il expose les interfaces que le client utilise
Il sait comment communiquer avec le proxy

RPC: Remote Procedure Call (appel de procdure distance) ou


LRPC :Lightweight RPC (principe de RPC mais entre processus
locaux )

Page 105

Yves LALOUM

DCOM
Distributed Component Object Model
Cest COM avec un support par le systme
dexploitation pour :
Identification distante
Chargement distant des composants
Marshaling ou extensibilit distante

Il est support par Windows NT4.0 et a partir de


Windows 95 patch
Il introduit une cl AppID pour les serveurs
DCOM permettant didentifier un module dans la
base de registres de Windows.

Page 106

Yves LALOUM

53

La Scurit DCOM
La Scurit :

Authentification
Autorisation
Protection contre lusurpation didentit
La scurit dactivation :

Gre ct serveur, elle spcifie :


les utilisateurs ou groupes qui peuvent lancer le serveur
Le compte sous lequel tournera le serveur
La scurit dappel : Automatique ou
Personnalisable pour chaque interface

Page 107

Yves LALOUM

Communications COM : ORPC


Object Remote Procedure Call
bas sur Open Software Foundation (OSF)
Distributed Computing Environement (DCE)
/RPC
il rajoute aux paquets standard RPC une
identification de lobjet appel OBJREF
OBJREF est constitu de :
Interface Pointer Identifier (IPID): Utilis cot serveur
pour identifier une interface spcifique dun objet.
Un Object Exporter Indentifier OXID : utilis pour
trouver une connexion au serveur qui abrite lobjet
appel .

Page 108

Yves LALOUM

54

ORPC : Architecture

Page 109

Yves LALOUM

Les contrles ACTIVEX


Les contrles ACTIVEX :
cest lapplication la plus sophistique de
COM
Dveloppe dans une optique Internet
cest lquivalent Microsoft aux
applets Java et aux Java beans
dans le monde du Web.

Page 110

Yves LALOUM

55

Evolutions COM+
Com+ est constitu de 3 parties :
COM Runtime
COM Services
DCOM

Page 111

Yves LALOUM

Architecture dimplmentation COM+

Page 112

Yves LALOUM

56

COM+ Runtime :
COM+ implmente automatiquement la grande
majorit des tches ncessaires pour construire des
objets COM au travers des Meta data codes
par le programmeur rduisant de 30% leffort de
programmation
Cest le concept de programmation base
attribut
Principal innovation : Les Interceptors (les
Intercepteurs) permettent de rerouter les accs des
clients aux objets via les bibliothques COM
affectant ainsi la manire dont les objets
interagissent entre eux.
Page 113

Yves LALOUM

Comparaison effort de
programmation COM et COM+

Page 114

Yves LALOUM

57

COM+ Services : Services de composants


Les services de composants sont en fait des
intercepteurs particuliers permettant dintercepter
et de rerouter les accs aux objets. Parmi les
principaux :
MTS : Microsoft Transaction Server (moniteur
transactionnel)
Scurit tendue
Load balancing : Repartition de charges sur plusieurs
serveurs

Page 115

Yves LALOUM

COM+ Services : Services de composants


DTC (Distributed Transaction Coordinator)
ou MTS : Microsoft Transaction Server
Client

Transaction

Serveur

DTC

MTS gre la Concurrence et la


Scurit des transactions sur bases de
donnes:
Page 116

Yves LALOUM

58

COM+ Services : Services de composants


Support d'environnements transactionnels htrognes
: Les composants COM peuvent participer des
transactions gres par un environnement transactionnel
(TP) autre que celui de COM+ par le support du protocole
TIP (Transaction Internet Protocol).
Scurit tendue : La prise en charge de la scurit est
base sur la notion de rle ainsi que les permissions d'accs
des processus. Dans le modle de scurit bas sur le rle,
l'accs aux diffrentes parties d'une application est accord
ou refus en fonction du groupe logique auquel l'utilisateur
appartient ou du rle qui lui a t attribu (par exemple,
administrateur, employ temps complet, employ temps
partiel). COM+ implmente en plus de la scurit base sur
le rle, la scurit au niveau des mthodes des interfaces.
Page 117

Yves LALOUM

COM+ Services : Services de composants


Administration centralise :L'Explorateur des
services de composants, prsente un modle
d'administration unifie, qui facilite :
le dploiement,
la maintenance,
la surveillance d'applications n niveaux, en
liminant le besoin d'utiliser de nombreux
outils d'administration distincts.

Page 118

Yves LALOUM

59

COM+ Services : Services de composants


IMDB - In-Memory DataBase (base de donnes
en mmoire) :
Permet de grer des informations permanentes et des
informations temporaires de faon cohrente. InMemory DataBase est un systme de base de donnes
entirement transactionnel gr en mmoire et conu
pour fournir un accs extrmement rapides aux
donnes.

Object pooling : Regroupement dobjets


Fournit aux applications des mthodes rapides et
efficaces pour pouvoir r-utiliser des objets COM dans
le but damliorer les performances.

Page 119

Yves LALOUM

COM+ Services : Services de composants


Load balancing : Rpartition de charges
Permet aux applications bases sur le
composant de rpartir leur charge de travail sur
un cluster d'applications et en toute
transparence vis--vis du client.
Serveur

Client

Aiguilleur
(Router)
Response time
Tracker

Serveur

Serveur

Page 120

Yves LALOUM

60

COM+ Services : Services de composants


Asynchronous(Appels de Mthodes asynchrone) et
Queued Components (composants en file d'attente) : bas
sur MSMQ Microsoft Message Queuing Services
Assurent une excution diffre en mode asynchrone
lorsque les composants travaillant en coopration sont
dconnects. Cette fonctionnalit vient s'ajouter au
modle de programmation client-serveur synchrone
bas sur la session.

Client

Recorder

MSMQ

Player

Serveur

Page 121

Yves LALOUM

COM+ Services : Services de composants


COM+ Events :
Notification d' vnements : A utiliser lorsqu'un
mcanisme de notification d'vnements est souhait.
Le systme d'vnements de COM+ est un mcanisme
de publication/abonnement qui permet des clients
de " s'abonner " des vnements " publis " par
plusieurs serveurs.
Suscriber
Publisher

Administration

Event Service
Event
Data base

Suscriber
Suscriber

Page 122

Yves LALOUM

61

Produits supportant COM


Sun Solaris (sparc)2.5
Digital Unix 4.0 (Alpha)
IBM MVS 5.2.2 (OS390)
IBM OS/400
IBM AIX
HP/UX
Digital Open VMS (sur Alpha)
Siemens Nixdorf SINIX
Linux 2.0 (Intel)
SCO UnixWare

Page 123

Yves LALOUM

Ce quil faut retenir


Comme pour Corba, les couches COM+ se
situent au niveau 5,6,7 du modle OSI au
dessus donc de la couche 4 (TCP/UDP)
Association COM+/ACTIVEX (comme
CORBA/JAVA)
Des passerelles permettant de faire
cohabiter les deux modles existent.

Page 124

Yves LALOUM

62

BIBLIOGRAPHIE
CORBA : Christophe Gransart, Jean-Marc
Geib et Philippe Merle
Editeur : Dunod
A Study of Technologies for Client/Server
Applications (pdf)
COM/DCOM
- Analyzing and Understanding
Architectural Characteristics of COM+
Page 125

Yves LALOUM

63