Vous êtes sur la page 1sur 14

Middleware

Plan

Client/Serveur Middleware
Introduction
1. Modle de programmation client/serveur
1.1 Ct serveur

Lionel Seinturier

1.2 Communications

Universit Pierre & Marie Curie

2. Client/serveur orient objet


Lionel.Seinturier@lip6.fr

3. Bibliographie

12/9/02
C/S Middleware

Lionel Seinturier

C/S Middleware

Introduction

Introduction
Problmatique du middleware

Middleware
dsigne dans le cadre de linformatique rpartie, toutes les couches
logicielles qui permettent des applications de communiquer distance

Software
Middleware
Operating system
Hardware

C/S Middleware

Lionel Seinturier

Middleware
unifie l'accs des machines htrognes
en terme de
CPU
OS
langage de programmation
reprsentation des donnes en mmoire

Lionel Seinturier

.....

Permettre un programme de sexcuter sur plusieurs machines


relies par un rseau
- large chelle (Internet)
- local (intranet)
Middleware : de plusieurs domaines de linformatique
- systme dexploitation
- rseau
- langage de programmation
C/S Middleware

- systme dexploitation rpartis


- librairies de programmation rseau
- langages de programmation tendus
4

Lionel Seinturier

Introduction

Introduction

Problmatique du middleware

Problmatique du middleware

Les environnements middleware permettent


types de matriels (PC, mainframes, laptop, PDA, ...)
de communiquer distance

Nombreux paradigmes de communication associs


! le principal : interaction requte/rponse ou client/serveur

prog.
client

requte

rs
eau

rponse

prog.
serveur

Interaction client/serveur

Middleware

= 1 requte + 1 rponse
= demande d'excution d'un traitement distance et rponse
appel procdural tendu au cas o appelant et appel
ne sont pas situs sur la mme machine
C/S Middleware

Lionel Seinturier

C/S Middleware

Introduction

Introduction

Problmatique du middleware

Problmatique du middleware

Deuxime paradigme

En gnral, le middleware

! interaction par messagerie (MOM : Message-Oriented Middleware)

n'est pas visible par l'utilisateur final


est un outil pour le dveloppeur d'applications
se retrouve enfoui dans les applications

prog.
client

dpose
message

retrait
Bote
lettres

message

Lionel Seinturier

prog.
serveur
Middleware permet de mettre en oeuvre des serveurs

Attention envoi message sur socket


Protocoles de niveau applicatif (pas transport) + proprits (ex transactionnelles)

finalit fixe : serveur Web, serveur de fichiers, serveur de BD, ...


effectuant des traitements quelconque : CORBA, EJB, .Net, ...

MOM : comm. asynchrone (fonctionnement client et serveur dcoupls)


Interaction client/serveur comm. synchrone

C/S Middleware

Lionel Seinturier

C/S Middleware

Lionel Seinturier

Introduction

Introduction
Client/Serveur 2 tiers

Client/serveur

Caractristiques
1 gros serveur (mainframes)
n terminaux lgers connects au serveur

Notion d'application client/serveur 2 tiers ou 3 tiers


Dcoupage d'une application
prsentation
traitements
donnes

client
prsentation

Avantages
pas de duplication de donnes (tat global observable)
gestion simple de la cohrence et de lintgrit des donnes
matrise globale des traitements

Problmatique
Par rapport 1 client et 1 (ou +sieurs) serveurs
qui assure ces fonctionnalits ?
serveur
donnes
+ traitement
C/S Middleware

Lionel Seinturier

Inconvnients
modle trop rigide qui nassure pas lvolutivit
souvent solutions propritaires ferms
conomiquement trop coteux

C/S Middleware

10

Introduction

Introduction

Client/Serveur 3 tiers
client
prsentation

serveur
traitement

serveur
donnes

C/S Middleware

Lionel Seinturier

Client/Serveur 3 tiers
Caractristiques
1 serveur de donnes et 1 serveur de traitement
n PC avec IHM "volues"
Avantages
meilleure rpartition de charge
conomiquement moins cher
+ volutif

Evolution historique du terme client/serveur 3 tiers


tiers 1 (PC)
tiers 1 (client)

tiers 2 (serveurs dpartementaux)


tiers 2 (BD locale)

tiers 3 (serveur central)


tiers 3 (BD globale)

tiers 2 (serveur de traitement)

tiers 3 (serveur de donnes)

Actuellement
tiers 1 (client)

Inconvnients
administration + complique
mise en oeuvre + complique

11

Lionel Seinturier

C/S Middleware

12

Lionel Seinturier

1. Modle c/s

1. Modle c/s
Modle de programmation client/serveur

Modle de programmation client/serveur

2 programmes

1.1 Problmatique ct serveur

1 programme client
1 programme serveur

Processus
Gestion d'tats
Persistance des donnes

! processus distincts
! mmoires distinctes
! machines distinctes (sauf si rpartition logique)

1.2 Communications client/serveur


Modes
Concepts
Notion de connexion
Reprsentation des donnes
Passage de paramtres
Traitement des pannes

C/S Middleware

Selon le contexte 1 programme peut tre client et serveur (ex. Napster, ...)
1 programme client
1 programme serveur qui pour rendre le service est client d'un 3 programme
1 programme serveur
! tre client, tre serveur, n'est pas immuable
mais dpend de l'interaction considre

13

Lionel Seinturier

C/S Middleware

1. Modle c/s

Lionel Seinturier

1.1 Ct serveur

Modle de programmation client/serveur

+sieurs clients simultanment

Point de vue du client


prog.
client

1. envoie une requte


2. attend une rponse

14

requte

rs
eau

1 bis. slection de la requte traiter


(FIFO ou avec priorit)

prog.
serveur

rponse
+sieurs mises en oeuvre possibles pour le traitement de la requte

Point de vue du serveur


1. attend une requte
2. effectue un traitement et
produit une rponse
3. envoie la rponse au client

requte

rs
eau

rponse

1 processus unique
1 processus par requte
1 pool de processus

prog.
serveur

rq : processus thread

mais le serveur doit aussi pouvoir traiter simultanment


les requtes de +sieurs clients
C/S Middleware

15

Lionel Seinturier

C/S Middleware

16

Lionel Seinturier

1.1 Ct serveur

1.1 Ct serveur

+sieurs clients simultanment - 1 processus unique

+sieurs clients simultanment - 1 processus par requte


Chaque arrive de requte
dclenche la cration d'un processus

prog.
serveur

while (true) { 1 1bis 2 3 }

while (true) { 1 1bis fork() }


p1
p2
p3
...
2 3
2 3
2 3
...

+sieurs clients envoient des requtes simultanment


mais le serveur n'en traite qu'une la fois

les clients sont servis + rapidement


conflits ventuels en cas d'accs simultans une ressource partage (ex. fichier)

simple
pas de risque de conflit de concurrence
suffisant dans certains cas
(ex. 1 requte toutes les 10s qui demande 2s de traitement)

C/S Middleware

pb : une concurrence "dbride" peut crouler la machine


restreindre le nombre de processus traitants

17

Lionel Seinturier

C/S Middleware

1.1 Ct serveur
Pool dynamique

prog.
serveur

Tjrs avoir des processus prt sans surcharger


inutilement la machine

prog.
serveur

le nb de processus varie
mais le nb de processus prts est tjrs compris entre 2 bornes
mlange des politiques 1 proc/req et pool fixe

1 nb constant de processus
+ 1 processus qui reoit les requtes
et les dispatche aux processus du pool
si aucun processus n'est libre, les requtes sont mises en attente

nb max de proc (ex. 150)


nb max de proc inactifs (ex. 20) : au del on dtruit les proc
nb min de proc inactifs (ex. 5) : en dea on cre de nouveaux proc
+ proc crs au dpart (ex. 15)

Avantage : pas de risque d'croulement


(pour peu que le nb de processus soit correctement dimensionn)
Inconvnients
- un pool de processus inactifs consomme des ressources inutilement
- les pointes de traffic sont mal gres
19

Lionel Seinturier

+sieurs clients simultanment - pool de processus

Pool fixe

C/S Middleware

18

1.1 Ct serveur

+sieurs clients simultanment - pool de processus


pool fixe
pool dynamique

prog.
serveur

rq : solution retenue par Apache

Lionel Seinturier

C/S Middleware

20

Lionel Seinturier

1.1 Ct serveur

1.1 Ct serveur

Gestion d'tats

Gestion d'tats

Problmatique

Mode avec tat

2 requtes successives d'un mme client sont-elles indpendantes ?


faut-il sauvegarder des infos entre 2 requtes successives d'un mme client ?

les requtes successives s'excutent


en fonction de l'tat laiss par les appels prcdents
sauvegarde de l'tat

Mode sans tat (le + simple)


Notion proche : session cliente dans un serveur Web
Suivi de l'activit d'un client entre le moment o il arrive et celui o il quitte le site

pas d'info sauvegarde


les requtes successives d'un mme client sont indpendantes

Pb : y a-t-il un mcanisme explicite qui indique au serveur que le client part ?


- si oui (ex. dconnexion notifie au serveur) alors ok
- si non
pb
: aucun sens de conserver ad vitam les donnes de la session
heuristique : la session expire au bout d'un dlai fix
inconv.
: un client trs lent peut revenir aprs expiration
(re)commencement d'une nouvelle session

ex : NFS, HTTP
Types de requtes envisageables
- demande d'criture du k-ime bloc de donnes d'un fichier
Types de requtes non envisageables
- demande d'criture du bloc suivant
C/S Middleware

21

Lionel Seinturier

C/S Middleware

1.1 Ct serveur

22

Lionel Seinturier

1.2 Communications

Persistance des donnes

Modle de programmation client/serveur

Problmatique

1.1 Problmatique ct serveur

le serveur gre-t-il des donnes globales partageables par tous les clients ?
rq : mode tat
Mode sans persistance (le + simple)

Mode avec persistance

le service s'excute uniquement en


fonction des paramtres

ex : serveur de fichiers,
serveur de BD

ex : calcul d'une fonction mathmatique

1.2 Communications client/serveur


Modes
Concepts
Notion de connexion
Reprsentation des donnes
Passage de paramtres
Traitement des pannes

Pb en cas d'accs simultans


par clients
contrle de concurrence

Situation favorable pour de nbreux pbs


de systme rparti (tolrance aux pannes,
quilibrage de charge, reprise aprs panne)

C/S Middleware

Processus
Gestion d'tats
Persistance des donnes

23

Lionel Seinturier

C/S Middleware

24

Lionel Seinturier

1.2 Communications

1.2 Communications

Modes de communication client/serveur


Client

Serveur

Client

Synchrone

Concepts
Serveur

Client

Asynchrone

Serveur

bote lettres
interface d'accs
modle de programmation

Semi-synchrone

enveloppe
message

Synchrone
le client attend la rponse pour continuer son excution
Asynchrone le client nattend pas de rponse et continue tout de suite
Semi-synchrone
le client continue son excution aprs lenvoi et
rcupre le rsultat ultrieurement
- futur explicite

le rsultat est stock dans une bote lettres (BAL)


le client consulte cette BAL pour rcuprer le res.

- futur implicite

le rsultat est fourni automatiquement au client


par ex. via une variable du prog. client

C/S Middleware

25

Lionel Seinturier

UFR 922
Jussieu

service de
messagerie
protocole

faon d'crire
les donnes
encodage

C/S Middleware

1.2 Communications

ressources
buffer, threads,
cx rsx

adresse

26

Lionel Seinturier

1.2 Communications
Connexion

Mise en oeuvre des concepts

Problmatique
opration

Client
1

Serveur

10

Souche
client
2

Souche
serveur

Transport
client

7
8

Transport
serveur

1. Appel local
2. Prparation du
message dappel
2. Envoi
4. Upcall vers
la souche serveur
5. Dcodage du message
6..10 : Chemin inverse

Vocabulaire franais
Vocabulaire anglais
C/S Middleware

souche ou talon
souche cl. = stub ou proxy, souche serv. = skeleton
27

Lionel Seinturier

Les comm. entre 1 cl. et 1 serv. (ie tapes 1 10) sont-elles prcdes
d'une ouverture de cx ? (resp. suivies d'une fermeture)
Mode non connect (le + simple)
les messages sont envoys "librement"
ex : NFS
Mode connect
Rq : la cx est le + souvent
lie au transport (TCP)
plutt qu'au protocole
applicatif lui-mme

Avantages
- facilite la gestion d'tat
- permet un meilleur contrle des clients
ex : FTP, Telnet, SMTP, POP, JDBC, HTTP
C/S Middleware

28

Lionel Seinturier

1.2 Communications

1.2 Communications

Reprsentation des donnes

Passage de paramtres

Problmatique

Problmatique

Comm. entre machines avec des formats de reprsentation de donnes


pas le mme codage (big endian vs little endian)
pas la mme faon de stocker les types (entiers 32 bits vs 64 bits, ...)

Client et serveur ont des espaces mmoire


passage par valeur ok
passage par rfrence
pas possible directement
une ref. du client n'a aucun sens pour le serveur (et vice-versa)

2 solutions
On prvoit tous les cas de conversions possibles
(n2 convertisseurs)

Solution : mcanisme copie/restauration


1. copie de la valeur rfrence dans la requte
2. le serveur travaille sur la copie
3. le serveur renvoie la nouvelle valeur avec la rponse
4. le client met jour la rf. avec la nouvelle valeur

On prvoit un format pivot et on


effectue 2 conversions (2n convertisseurs)
Nbreux formats pivots : ASN.1, Sun XDR, srialisation Java, CORBA CDR, ...
C/S Middleware

29

Lionel Seinturier

C/S Middleware

1.2 Communications

30

Lionel Seinturier

1.2 Communications

Passage de paramtres

Passage de paramtres

Mais copie/restauration pas parfait

Dfinitions couramment adopte (au lieu de valeur/rfrence)


- mode IN (entre)
- mode OUT (sortie)
- mode IN/OUT (entre/sortie)

Pb du double incrment
void m (&x, &y) { x++; y++; }
a=1; m(a,a);

passage par valeur avec la requte


passage par valeur avec la rponse
copie/restauration de la valeur
IN

rsultat attendu a=2, rsultat obtenu a=1 !!

Serveur

Client

! dtecter les doubles (multiples) rfrencements


! pas facile dans le cas gnral

OUT

Pb en cas de mises jour concurrentes de la valeur rfrence

IN
si le serv. modifie la valeur, le cl. ne "voit" pas cette modif.
OUT si le cl. transmet une valeur, le serv. ne la "voit" pas
C/S Middleware

31

Lionel Seinturier

C/S Middleware

32

Lionel Seinturier

1.2 Communications

1.2 Communications

Passage de paramtres

Passage de paramtres

pb : IN/OUT et OUT pas tjrs faciles grer dans les lang. de prog.

pb : IN/OUT et OUT pas tjrs faciles grer dans les lang. de prog.

ex : Java

Illustration
4

4
Serveur

Souche

Client

x=4;
o.m(x);

! comment transmettre en IN/OUT (ou OUT) un int ?


! comment implanter la copie/restauration non prvue par la VM ?
- sans modifier le code du client, ni celui du serveur
- seuls codes "maitrisables" : souches client et serveur

Souche

- types simples (int, float, ...) transmis par valeur


- objets transmis par rfrence

x=5;

- la souche connat simplement la valeur 4


- elle n'a pas la ref. de x
! elle ne peut pas la mettre jour

C/S Middleware

33

Lionel Seinturier

C/S Middleware

1.2 Communications

34

Lionel Seinturier

1.2 Communications

Passage de paramtres

Traitement des pannes

Solution

3 types

- pas possible de ne pas modifier les codes client et serveur


- le client transmet un conteneur pour la valeur

client
serveur
rseau - panne de rsx local en gnral dtectable (ex. brin Ethernet)
- panne rsx large chelle (Internet) non signale gnralement

class IntHolder { int x; }

! la souche cliente peut mettre jour la valeur contenue

Dans la majorit des cas


4

Serveur

ih.x=5
C/S Middleware

4
Souche

Souche

Client

ih.x=4;
o.m(ih);

35

ih.x=5;

symptme : absence de rponse


cause (rsx, serveur plante, serveur trs lent) inconnue
solution
- choisir un autre serveur : pas toujours possible
- abandonner : pas forcment satisfaisant
- ressayer plus tard (en esprant un retour en service) ! mieux

5
Lionel Seinturier

C/S Middleware

36

Lionel Seinturier

1.2 Communications

1.2 Communications

Traitement des pannes

Traitement des pannes

Problmatique

Au moins 1 fois

Comportement de l'interaction c/s satisfaisant en prsence de r missions


( appel de mthode local)
sans que cela soit trop lourd grer pour le middleware

Il faut que le traitement demand soit idempotent


ie +sieurs excutions du mme traitements ne doivent pas poser pb
ex idempotent
idempotent

! Notion de smantique d'invocation


au moins 1 fois garantie traitement demand excut au moins 1 fois [1..n]
au plus 1 fois [0..1]
exactement 1 fois
- le plus satisfaisant
- mais le plus lourd

C/S Middleware

37

x:=5
x++

lire_fichier(bloc k)
ecrire_fichier(bloc k)
lire_fichier_bloc_suivant()

Algorithme
client envoie requte
tant que rsultat non reu
attendre dlai
renvoyer requte
Lionel Seinturier

C/S Middleware

1.2 Communications

38

1.2 Communications

Traitement des pannes

Traitement des pannes

Au plus 1 fois

Exactement 1 fois

Algorithme

ex : client renvoie sa requte l'expiration du dlai

client envoie requte


si au bout d'un dlai d'attente pas de rsultat
alors signaler la panne au client

- serveur plant dfinitivement


en gnral, pas de ressai ad vitam abandon au bout de 3 envois
- serveur plant mais redmarre
est-ce que la req. avait quand mme t reue ?
si oui continuer l'excution
est-ce que la rponse avait t envoye mais s'est perdue ?
si oui renvoyer la rponse, si non excuter
- serveur trs lent
donc requte bien reue et traitement commenc
continuer l'excution
- rseau coup dfinitivement (idem serveur plant dfinitivement)
- rseau coup mais reprend (idem serveur plant mais redmarre)

Exactement 1 fois (le + dur assurer)


On ne sait pas si l'absence de rponse est due
- une perte de message sur le rseau
- une panne de serveur
- un serveur trs lent
! r missions
! dtection des r missions
C/S Middleware

39

Lionel Seinturier

Lionel Seinturier

C/S Middleware

40

Lionel Seinturier

1.2 Communications

2. C/S OO

Dtection des pannes

Client/serveur orient objet

Mcanisme complmentaire pour dtecter des pannes


en cours d'excution d'un traitement
heart beat
pinging

2.1 Nommage
2.2 Scurit daccs

priodiquement le serveur signale son activit au client


priodiquement le client sonde le serveur qui rpond

2.3 Dure de vie


2.4 Objets concurrents
2.5 Synchronisation
2.6 Migration
2.7 Rplication
2.8 Ramasse-miettes

C/S Middleware

41

Lionel Seinturier

C/S Middleware

2. C/S OO

42

2.1 Nommage

Client/serveur orient objet

Identifier les objets dans un environnement rparti

But : coupler la notion d'objet avec les concepts client/serveur

Deux objets sur le mme site ou sur des sites


ne doivent pas avoir la mme identit (on parle de rfrence)
La rfrence sert retrouver lobjet pour pouvoir invoquer ses mthodes
Gnralisation de la notion de pointeur un environnement rparti

Objectifs
meilleure modularisation des applications
entits logiciels plus rutilisables
applications mieux packages, portables et maintenables plus facilement

Deux techniques principales


un ID sans rapport avec la localisation gnr par une fonction mathmatique
+ une table de translation entre lID et la localisation de lobjet
un ID en deux parties : son site de cration + un numro local unique

Rsultats
unit de distribution = objet
un objet = un ensemble de traitement fournis par ses mthodes
interaction client/serveur = invocation de mthode

Recherche dun objet partir de sa rfrence


annuaires de localisation centraliss ou rpartis, ou diffusion
interrogation du site contenu dans la rfrence + liens de poursuite

! Nombreux aspects techniques intgrer pour y arriver

C/S Middleware

43

Lionel Seinturier

Lionel Seinturier

C/S Middleware

44

Lionel Seinturier

2.2 Scurit daccs

2.3 Dure de vie

Grer le partage des objets dans un environnement rparti

Grer la dure de vie des objets

Pour des raisons de scurit, laccs certains objets peut tre restreint

Objets temporaires : leur dure de vie correspond celle de leur crateur

- en fonction de lidentit de lobjet appelant


ex : seuls les accs en provenance de lintranet sont autoriss
- partir dune liste de contrle daccs
ex : mot de passe, mcanismes de cls de session, ...

Objets persistants
- lobjet reste prsent en mmoire tant quil nest pas dtruit
- la persistance peut tre limite par la dure de vie du systme
ou stendre au del des redmarrages

La restriction peut

Plusieurs possibilits

- interdire compltement laccs lobjet


- fournir une vue dgrade
ex : autoriser les mthodes qui fournissent un service de consultation
mais interdire celles qui modifient ltat de lobjet

- tous les objets sont persistants ou non


- un objet est cre persistant ou non
- un objet temporaire peut devenir persistant et vice-versa
- un objet rfrenc par un objet persistant est persistant ou non

! Nombreuses informations ajouter aux objets

C/S Middleware

45

Lionel Seinturier

C/S Middleware

2.4 Objets concurrents

46

Lionel Seinturier

2.5 Synchronisation

Deux types dobjets concurrents

Restreindre la concurrence d'excution des mthodes

Objet passif

En prsence d'invocations de mthodes concurrentes


toutes les invocations ne sont pas forcment traitables simultanment

Objet actif

Lactivit
manipule de faon explicite
orthogonal lobjet
se plaque sur les mthodes

Une (+sieurs) activit ddie


lobjet excutent les mthodes

- soit pour des raisons strictement ncessaires (cohrence de l'application)


- soit pour assurer une qualit de service (ex. ne pas crouler la machine)
! on en met en attente ou on en rejette certaines

appelant

3 types de synchronisations

appelant

pour 1 mthode d'un objet


- synchronisation intra-objet
- synchronisation comportementale

Ex :
thread Java

pour +sieurs mthodes situes sur des objets


- synchronisation inter-objets
C/S Middleware

47

Lionel Seinturier

C/S Middleware

48

Lionel Seinturier

2.5 Synchronisation

2.5 Synchronisation

Synchronisation comportementale

Outils pour les synchro. intra-objet & comportementale

Fonction de ltat des donnes de lobjet


ex : Pile avec empiler et depiler
vide : empiler
1/2 : empiler et depiler
plein : depiler

Synchronisation intra-objet

smaphores

objets avec mthodes P et V

moniteurs

objet avec mthodes synchronized


wait et notify (ex Java)

expressions
de chemin

oprateurs , * | // pour spcifier


les squences valides de mthodes

gardes

chaque mthode est associe


une condition boolenne

graphes
tats/transitions

chaque objet est associ un ensemble dtats


chaque tat est associ un sous-ensemble de
mthodes pouvant tre excutes

Fonction de ltat dexcution de lobjet


ex : Fichier avec lire et crire
soit +sieurs lire simultanment
soit 1 seul ecrire

C/S Middleware

49

Lionel Seinturier

C/S Middleware

2.5 Synchronisation

50

2.6 Migration

Synchronisation inter-objets

Dplacer des objets

Assurer l'excution cohrente d'une suite d'invocations de mthodes

dun espace dadressage un autre


dune zone de stockage une autre (mmoire, disque)
dun site un autre

Exemple : un transfert entre deux objets comptes bancaires


Assurer quun ensemble de 2 ou +sieurs invocations de mthodes

Objectifs

compte1.depot(50);
compte2.retrait(50);

seffectuent compltement ou pas du tout ( + proprits ACID /* cf. BD */ )

- rduire les cots de communication entre objets bavards


- rpartir la charge vers les sites inutiliss
- augmenter la disponibilit dun service en le rapprochant de ses clients

Problmatique de la thorie de la srialisatibilit et des moniteurs transactionnels

Nombreux problmes rsoudre

! intgration du moniteur dans le systme rparti objet avec un


- protocole de validation (2PC ou 3PC)
- mcanisme de verrouillage des ressources
- mcanisme de dtection et de traitement des conflits
C/S Middleware

51

Lionel Seinturier

- interrompre ? attendre la fin ? des traitements en cours avant de migrer


- impact de la migration sur la rfrence ?

Lionel Seinturier

C/S Middleware

52

Lionel Seinturier

2.7 Rplication

2.8 Ramasse-miettes

Dupliquer des objets sur +sieurs sites

Dtruire les objets qui ne sont rfrencs par aucun autre

Objectif principal : tolrance aux fautes

Objectif : rcuprer les ressources (mmoire, CPU, disque) inutilises


Difficult / aux systmes centraliss : suivre les rfrences entre sites distants

Active

Passive
(primary-backups)

Deux techniques
comptage de rfrences : on associe un compteur chaque objet
+1 lorsque la rfrence est acquise
-1 lorsque elle est libre
inconvnient : utilisation mmoire + pas de gestion des cycles de rf.
avantage : simple

client
client
rplique
primaire

rplique 1

tat

traage (mark and sweep) : parcours graphe objets partir dune racine
objets non marqus dtruits
inconvnient : temps CPU pour le traage
avantage : pas de modification des objets

rplique 2
rplique 2
rplique 3
rplique 3

C/S Middleware

53

Lionel Seinturier

3. Bibliographie
R. Orfali, D. Harkey, J. Edwards. The Essential Client/Server Survival Guide. Wiley 1996.
B. Meyer. Object-Oriented Software Construction. Prentice Hall 1997.
A. Tanenbaum. Distributed Operating Systems. Prentice-Hall 1995.
C. Atkinson. Object-Oriented Reuse, Concurrency and Distribution.
Addison Wesley 1992.
R. Balter, J.P. Bantre, S. Krakowiak.
Constructions des systmes dexploitation rpartis. 1991.

Concurrent Object Oriented Programming. CACM 36(9). Sept. 1992.


J.P. Briot, R. Guerraoui. Objets pour la Programmation Parallle et Rpartie :
Intrts, Evolutions et Tendances. TSI 15(6):765-800. Juin 1996.

C/S Middleware

55

Lionel Seinturier

C/S Middleware

54

Lionel Seinturier