Mode de structuration d'applications réparties.pdf

1Modes de structuration dapplications rparties - Autrans - 99

Modes de structurationdapplications rparties

Roland Balter


Problmatique (1)

o application rpartie = traitements cooprants sur des donnes rparties

utraitements :v description : programmev excution : flot d'excution (processus)

o coopration = communication + synchronisationumodle d excutionu interface de programmation (et/ou langage)

v modle de programmationuoutils de dveloppementuenvironnement d'excution : services systmes

(pour diffrents types d'infrastructures)


Problmatique (2)

Services applicatifsfichiers rpartis, moniteur transactionnel, accs BD, ...

Services systmescommunication, RPC, dsignation, scurit, ...

Systme dexploitation

Machines et Rseaux

outilsde

dveloppement

outilsd

administration

middleware

Modle dexcutionMthodes et outils

demodlisation


Modles dexcution

oModle client-serveuruclient-serveur "traditionnel"uclient-serveur "de donnes"uclient-serveur " objets" : Corba, Com/Dcom (mardi)

oModle de communication par messages oModle de communication par vnementsoModle composants (mercredi )oModle base de code mobile (jeudi)oModle mmoire "virtuelle" partage


Modle client-serveur : principes directeurs

Service_1

Service_n

.

.Serveur

Client_a

Client_b

Clientmet des requtes (demandes de service)mode d'excution synchrone

le client est l'initiateur du dialogue client-serveur

Serveurensemble de services excutablesexcute des requtes mises par des clients --> excution des services (excution squentielle ou parallle)

Exemples : serveur de fichiers, serveur de base de donnes,serveur d'impression, serveur de noms (annuaire des services)


oVu du client

oVu du serveuruGestion des requtes (priorit)uExcution du service (squentiel, concurrent)uMmorisation ou non de l'tat du client

Modle client-serveur : principes (2)

Servicedistant

Requte

Rponseclient

Excutiondu

service

SlectionRponsesRequtes


Mise en uvre du modle client-serveur

oAppel de procdure distance (Remote Procedure Call)uL'opration raliser est prsente sous la forme d'une procdure

(le service), situe sur un site distant, dont le client demande l'excution

uObjectif : forme et effet "identiques" ceux d'un appel localv interface de programmationv smantique

uOprations de basev Client

]doOp (IN Port serverId, Name opName, Msg *arg, OUT Msg *result)v Serveur

]getRequest (OUT Port clientId, Message *callMessage)]sendReply (IN Port clientId, Message *replyMessage)

8Modes de structuration dapplications rparties - Autrans - 99client serveur

RPC [Birrel & Nelson 84] : principe de ralisation

Service RPC(talon serveur)

(skeleton)

appel

rseau

Appelant

appel

Service RPC(talon client)

(stub)

retour

Protocole decommunication

Protocole decommunication

appel

retour

A

E

B

D

C


RPC : rle des talons

Talon client - stub

o procdure dinterface sur le site client

u reoit lappel en mode local,u "emballe" les paramtres et le

transforme en appel distant en envoyant un message,

u attend les rsultats en provenance du serveur,

u "dballe" les paramtres rsultats, et les retourne au programme client "comme" dans un retour de procdure local.

u Liaison initiale

Talon serveur - skeleton

o procdure d'interface sur le site serveur

u reoit lappel sous forme de message,

u "dballe" les paramtres d'appel,

u fait raliser lexcution sur le site serveur par la procdure de service invoque,

u "emballe" les paramtres rsultats et les retransmet par message.

u Enregistrement initial


oMotivationsuSpcification commune au client et au serveur

*contrat entre le client et le serveuruDfinition du type et de la nature des paramtres (IN, OUT,

IN-OUT)uIndpendance des langages de programmation

o Principes directeursuLangage dclaratifuOutils de gnration des talons (stub et skeleton)

Langages de description d'interfaces (IDL)


IDL : chane de compilation

Procduredu client

Procduredu client

Descriptiond interface

bibliothque

Programmeclient

Programmeclient

compilateurcompilateur

Procduredu serveurProcduredu serveur

Programmeserveur

Programmeserveur

compilateurcompilateur

Gnrateurde talons

talonclient

talonclient

Dfinitionscommunes

talonserveur

talonserveur


Appel distant versus appel local

oObjectifs uprserver la smantique habituelle de l appel de procdureu "transparence" de la distribution : programmation "identique" celle

d'un appel localoObjectifs difficiles atteindre

uralisation peu conviviale (mme avec l'utilisation d'un IDL)usmantique diffrente de l appel de procdure mme en l absence de

pannev exemple : passage des paramtres par rfrence

* smantique prcise fonction de l'implmentation du RPC


RPC : quelques problmes de mise en uvre

4Traitement des dfaillancesu panne et/ou congestion du rseau,u panne du client pendant le traitement de la requte,u panne du serveur avant ou pendant le traitement de la requte,

4Gestion de l'Htrognit4Dsignation et liaison

o Problmes de scuritu authentification du client et du serveuru confidentialit des changes

o Aspects pratiquesu adaptation des environnements d'utilisation variables

(protocoles, langages, matriels)u performance


RPC : traitement des dfaillances

oEn cas d'erreur : smantique variable(selon la nature du mcanisme de reprise mis en uvre)

uIndfiniuAu plus une fois

v si expiration du dlai A alors erreurv pas de mcanisme de reprise

uAu moins une foisv si expiration du dlai A alors r-mission de la requte,v plusieurs excutions possibles du service,v acceptable si opration idempotente

uExactement une fois (idal...)v r-mission de la requte et/ou de la rponse si ncessaire,v limination des "doublons"


RPC : traitement de l'htrognit

o Problme : reprsentation des donnesuConversion ncessaire si le site client et le site serveur

v n utilisent pas le mme systme de codage (big endian versus little endian)

v utilisent des formats internes diffrents (pour les types de base : caractre, entier, flottant, )

oSolutionsuSyntaxe abstraite de transfert ASN 1 uReprsentation externe commune : XDR Sun (non optimal si

mme reprsentation)uReprsentation locale pour le client et conversion par le serveuruChoix d'une reprsentation parmi n (standard), conversion par

le serveuruNgociation client serveur


RPC : dsignation et liaison (1)

o Problmesuobjets dsigner : le site d excution, le serveur, la procdureudsignation globale indpendante de la localisation

v possibilit de reconfiguration des services (pannes, rgulation de charge, )

oMise en uvre : statique ou dynamiqueustatique : localisation du serveur connue la compilationudynamique : localisation dtermine l'excution (au premier

appel)v sparer connaissance du nom du service de la slection de la

procdure qui va l excuterv permettre l implmentation retarde


RPC : dsignation et liaison (2)

o Liaison : mise en uvre

Programmeclient

Talonclient

Communicationclient

Programmeserveur

Talonserveur

Communicationserveur

Servicede

dsignationconsultation enregistrement

communicationlogique

communicationphysique

12

Appel 3


Les limites du modle client-serveur

omodle de structurationupermet de dcrire linteraction entre deux composants logiciels

* absence de vision globale de lapplicationuschma d'excution rpartie lmentaire (appel synchrone)

* absence de proprits portant sur la synchronisation, la protection, la tolrance aux pannes, . .

o services pour la construction dapplications rpartiesu le RPC est un mcanisme de bas niveauudes services additionnels sont ncessaires pour la construction

dapplications rparties (dsignation, fichiers rpartis, scuri t, etc.)o outils de dveloppement

u limits la gnration automatique des talonsupeu (ou pas) doutils pour le dploiement et la mise au point

d'applications rparties


Environnements client-serveur

4environnement client-serveur "traditionnel"uDCE (Distributed Computing Environment) :

v un exemple denvironnement intgr dapplications rparties, fond sur le modle client-serveur

o environnement client-serveur " objet"

o environnement client-serveur "de donnes"

o environnement client-serveur " composant"


DCE : architecture gnrale

appel de procdure distance

authentificationgestion

du temps dsignation

service defichiers rpartis

support de stationssans disque

autresservices

processus lgers (threads)

Ou

tils

de

dv

elo

pp

emen

t

adm

inis

trat

ion


Atouts et limites de DCE

+ architecture de type bote outilsuchaque fonction est utilisable via une interface normaliseuaccs direct des fonctions volues

---> intgration gros grain

+ standard de fait (diffusion dans la communaut industrielle)

uex. : RPC, Service de noms, service dauthentification---> portabilit et interoprabilit

dveloppement dapplications grain fin laborieuxuex. : utilisation des services de thread et du RPC

(limitations quivalentes celles du client-serveur)upeu doutils de dveloppement disponibles aujourdhui



o environnement client-serveur "traditionnel"

4environnement client-serveur " objet"




Client-serveur " objet"

oMotivationsuproprits de lobjet (encapsulation, modularit, rutilisation,

polymorphisme, composition)uobjet : unit de dsignation et de distribution

o Principe de fonctionnement

Methode _1

Methode _n

tat

objet serveurobjet client

.

.

appel

Systme de communication

Talonserveur

Talonclient


Appel de mthode distanceRemote Method Invocation (RMI)

o lments d'une "invocation"urfrence d'objet ("pointeur" universel)u identification d'une mthodeuparamtres d'appel et de retour (y compris signal d'exception)

v passage par valeur : types lmentaires et types construitsv passage par rfrence

o objets "langage"ureprsentation propre au langage : instance d'une classeuexemple : Java RMI

o objets "systme"ureprsentation "arbitraire" dfinie par l'environnement d'excutionuexemple : CORBA (--> mardi)


Client-serveur " objet" : mise en uvre

tat

Mthode_i

Talon serveur

Objet

Rfrence d'objet + mthode + arguments

Rsultat ou exception

talon client

Interface

rfrence

dsignationenvoi de requtesexcution de requteretour de rsultat





4environnement client-serveur "de donnes"



le client-serveur de donnesprincipes directeurs (1)

programmeclient programme

serveur

requte SQL

rsultats (tuples)

Site client Site Serveur

Mdiateur


Le client-serveur de donnesprincipes directeurs (2)

o fonction du clientucode de l'application non li aux donnesudialogue avec l'utilisateur

o fonction du serveurustockage des donnes, gestion de la disponibilit et de la

scuritu interprtation/optimisation des requtes

o fonctions du mdiateuruprocdures de connexion/dconnexionuprparation/communication de requtesugestion de caches (requtes et rsultats)


Le client-serveur de donnesenvironnement applicatif

oEnvironnement Applicatif Commun (CAE) de lX/OPENuobjectif : portabilit des applicationsu interface applicative CLI (Call Level Interface)

v standardisation des appels SQL depuis un programme (C, Cobol, . .)v connexion/dconnexion, prparation/excution des requtes, . . .

uprotocole d'change standardis RDA (Remote Data Access)v partie gnrique (dialogue et contrle transactionnel)v partie spcifique SQL (codage commandes et rsultats)

oOutils de dveloppement uL4G : intgre accs aux tables, contrle, affichage, saisie, ...

indpendants des langages de programmationlangage cible : C (ou Cobol)

uAGL : fonctions des L4G + gestion dun rfrentiel des objets (schmas de donnes, code des oprations, enchanement, . . .)


Client-serveur de donnes : la solution ODBC

Application

Bibliothque (DLL)

Pilote ODBC Local

Pilote ODBC global

FAPFichiersDbase

SGBD

FAP

Adaptateur

Client Serveur


Client-serveur de donnes " objet" :la solution ODMG

oObjectifsuPortabilit des sources dune application sur divers moteurs

de bases de donnes objet

o Principes directeursu modle objet = sur-ensemble du modle OMGu un langage de Dfinition de Donnes : ODL (bas sur lIDL

OMG) u un langage de Requtes : OQL, volution de SQL u intgration complte des mcanismes dans le langage hte :

C++ (avec propositions dvolution de la norme) et Smalltalk






4environnement client-serveur " composant"


Client-serveur "composants" (1)

oMotivationsu l'origine, environnements pour la gestion de documents

compositesuautomatisation du processus de cration dun document

partir dinformations htrognes fournies par des utilitaires diffrents

uexemples : OLE/COM, OpenDoc/SOMoApproche

u interoprabilit entre composants logiciels binairesv environnements homognesv interaction de type client-serveurv format de donnes "pivot" et procdures de conversion


Exemple : gestion de documents composites

oOLE (Object Linking and Embedding)

Lien vers texte_1

Lien vers tableau_2

tableau_1

texte-1

Tableau_2

copie detableau_1

Incorporation

Lien

Lien

(Linking)

(Linking)

(Embedding)


oEnvironnement d'intgrationumodle et mcanismes pour raliser l'interoprabilit entre

"composants" logiciels autonomesvcomposant : unit de rutilisation et de construction

d'applications rparties

umodle et mcanismes pour associer des proprits non-fonctionnelles des objets (ou groupes d'objets)

vproprits : persistance, excution transactionnelle, qualit de service, . . .

vcomposant : unit d'administration

mercredi

Client-serveur "composants" (2)


Modles dexcution


4Modle de communication par messagesoModle de communication par vnementsoModle composants (mercredi )oModle base de code mobile (jeudi)oModle mmoire "virtuelle" partage


Communication par messages :un peu d'histoire . . .

od'un mode de communication "ancien" . . .uLe courrier lectronique

v communication de type asynchronev listes de diffusion (communication de groupe)

uLes forums (News)v communication filtre par "sujet"v abonnement avant rception

o . . l'mergence de paradigmes de programmationuAnnes 70: Message Queuing (IBM MQ Series, etc. )umodles vnements/raction, publish/subscribeumodles d'acteursuprogrammation par agents (vendredi)


Communication par messages : modle de programmation

oMode de synchronisationuCommunication asynchrone

v mission non bloquantev rception bloquante (attente jusqu' rception d'un message)

oMode de communicationucommunication directe entre processus (acteurs, agents, . . .)ucommunication indirecte entre processus via des "portes"

(botes aux lettres)

oMode de transmissionumessages possiblement typs


Communication par messages : exemple 1

oRalisation d'un change asynchrone

Processusmetteur

Processusrcepteur

.Send (Id_bal, message)Msg = Receive (Id_bal)


Communication par messages : exemple 2

oRalisation dune interaction de type client-serveur

Client Serveur

bal_S

bal_C

(nom_de_service, paramtres, bal_C)

(rsultat)

.

.

Send(bal-S, nom-de-service, paramtres)Msg = Receive(bal_S)

exec (nom_de_service, paramtres)

.

.

Send (bal-C, rsultat)


Communication par messages : API et mise en uvre

oEnvironnement de type "micro-noyau"umcanisme et primitives de baseuexemples : Chorus, Mach/OSF-1

oEnvironnement " la unix"u "sockets"

oEnvironnement de programmation parallleuPVM et/ou MPI

oEnvironnement "industriel" d'intgration d'applicationsumiddleware messages: MOMu interface de programmation ad hoc

v tentative de normalisation via Java JMS


"Middleware" messages : MOM

o Principes directeursucouche de logiciel sur le systme hte

oModle de programmationumessagesuqueues de messages

o Proprits utransactions

v messages vus comme des ressources "transactionnelles"uscurit

v encodage des messagesv contrle d'accs aux messages

Systmehte

MOM

Systmehte

MOM

Application


MOM : messages

o Identification uniqueoStructure

uEntte :v Information permettant l'identification et l'acheminement du

messageuAttributs :

v Couples (nom, valeur) utilisables par le systme ou l'application pour slectionner les messages

uDonnes :v Dfinies par l'application

o Paramtres udure de vieupriorituscurit


MOM : queues de messages

o identification uniqueo persistantes (rsistance aux dfaillances)o partages par les applicationsomodes de rception variable

sendrecv

Client Serveur


MOM : API

oMsgQ.attach(name, type) msgQoSendQ.sendMsg(msg)oRecvQ.recvMsg(wait) msgoRecvQ.confirmMsg(msg)oMsgQ.detach()


Communication par messages extensions au modle de base

oCommunication de groupeugroupe : ensemble de rcepteurs identifis par un nom uniqueugestion dynamique du groupe : arrive/dpart de membresudiffrentes politiques de service dans le groupe : 1/N, N/Numise en uvre : utilisation possible de IP multicastuexemple : Isis, Horus, Ensemble (Cornell university)uapplications : tolrance aux fautes (gestion de la rplication),

travail coopratif

oCommunication anonymeudsignation associative : les rcipiendaires d'un message sont

identifis par leurs proprits et pas par leur nomuproprit : attribut du message ou identificateur externe indpendance entre metteur et rcepteurs


Modles d'excution


oModle de communication par messages 4Modle de communication par vnementsoModle composants (mercredi )oModle base de code mobile (jeudi)oModle mmoire "virtuelle" partage


Communication vnementielle :principes de fonctionnement

o concepts de base : vnements, ractionsuraction : traitement associ loccurrence dun vnement

o principe dattachementuassociation dynamique entre un nom dvnement et une raction

o communication anonymeu indpendance entre lmetteur et les consommateurs dun

vnementcanaux de

communication

vnements ractionsProcessus

metteurs

Processus

destinataires

Nom (type) d'vnement


Processus_a Processus_b

.

.

Communication vnementielle (publish/subscribe)principes de ralisation

reaction

Subscribe (event, reaction)

Publish (event) 12

3

Gestion des

vnements et des

abonnements

serveur centralis ("Hub and Spoke")serveur rparti ("Snowflake")service rparti (bus logiciel)


Gestion des vnements

oMode "Pull"uLes clients viennent "prendre" priodiquement leurs messages

sur le serveur.

oMode "Push"uUne mthode prdfinie (raction) est attache chaque type

de message (vnement) ;u l'occurrence d'un vnement entrane l'excution de la

raction associe.


Architecture - "Hub and Spoke"

Client

ClientClient

Broker

ClientClient

Client

o Serveur centralis de gestion d'vnementsprotocole de communication point--point


Architecture - "Snowflake"

Client

Client

Broker

Client

Client

BrokerClient

Broker

Client

protocole de communication point--point

o Serveur rparti de gestion d'vnements


HubHub

Architecture - bus de message

S.E.

Machine A

Bus Bus Bus

Client Client Client Client

Machine B Machine C

S.E. S.E.S.E.

Machine B

S.E.

Machine B

protocole de communication multicast

o Service rparti de gestion d'vnements


Java Message Service (JMS)

oObjectif : API Java d'accs uniforme aux systmes de messagerie

uIBM MQSeriesuNovell, Oracle, SybaseuTibcou . . .

o PropritsuPoint--PointuPublish/Subscribe


JMS : principe de fonctionnement

Provider X

JVM

Client

Client

Client

MQ X MQ XMQ X MQ X

JMSClientProvider X

JVM

Client

JMS


JMS - Architecture

JNDI

ConnectionFactory

Connection

Session

MessageProducer

MessageConsummer

Destination

JMS Client

+

+


Communication vnementielle : conclusion

oDomaines d'applicationugnie logiciel (coopration entre outils de dveloppement) :

SoftBench, ToolTalk , DecFuse, . . uworkflow : KoalaBus, . . uIntgration/extension d'applications existantes : AAA, . . 4diffusion de logiciels et d'information sur le Web :

iBus, Castanet, Ambrosia, Smartsockets, TIB/Rendezvous, Active Web,

o Infrastructures propritairesu interface applicative et protocoles propres chaque systme

---> problmes de portabilit et dinteroprabilit

oOutils de dveloppementusommaires


Modles dexcution


oModle de communication par messages oModle de communication par vnementsoModle composants (mercredi )4Modle base de code mobile (jeudi)oModle mmoire "virtuelle" partage


Code mobile

oDfinitionuprogrammes pouvant se dplacer d'un site un autreuexemples : requte SQL, "applet" Java

oMotivations urapprocher le traitement des donnes

v rduire le volume de donnes changes sur le rseauv partage de charge

4function shipping versus data shippingoCaractristiques

ucode interprtableuscurituschmas d'excution base de code mobile


Processus_a

Modles d'excution pour la mobilit

o code " la demande"umobilit "faible"

(code excutable, sans contexte)uexemple : "applet" Java

o agents mobiles umobilit "faible"

v code excutable + donnes modifies

v exemple : Agletsumobilit "forte"

v code excutable, + donnes+ contexte d'excution

v exemples : AgentTcl

Site A Site B

code

Processus

code

Site A Site B

code

Processus_b

codectx. ctx.


Modles dexcution


oModle de communication par messages oModle de communication par vnementsoModle composants (mercredi )oModle base de code mobile (jeudi)4Modle mmoire "virtuelle" partage


oMotivationsu (re)placer le programmeur d'application dans les conditions d'un

systme centralisv utiliser une mmoire commune comme espace de communicationv synchronisation par variables partages

uavantages attendus (pour le programmeur)v simplicit : distribution "transparente"v efficacit : utilisation des paradigmes usuels de la programmation

concurrente

* problmatiqueuutilisation des outils de dveloppement existants : langages,

compilateurs, metteurs au point, . . .umise en uvre "efficace" d'une mmoire partage distribue

Systmes mmoire partage (1)


Objets partagsObjets partags


o Principe de ralisationu "simulation" d'une mmoire globale (d'objets) partage

Site A Site B Site C


oApprochesuModles espace de tuples

v base de donnes (de tuples) partagev modle de programmation " la Linda"

] dpt, retrait, et consultation d'objetsv exemple : JavaSpaces

uModles objets rpartis partagsv espace d'objets rpartis partagsv interface de programmation : langage objet "tendu"v plusieurs modes de ralisation

] objets rpliqus (exemple : Javanaise)] objets image unique (exemple : Guide)



JavaSpaces : modle (1)

oUn JavaSpace : un espace de tuples (entres)oUne entre : un ensemble de champsoUn champ : une rfrence une instance Java

JavaSpace

entre


JavaSpaces : modle (2)

oOprations de baseucriture dans un JavaSpace (dpt)u lecture dans un JavaSpace (avec conformit)uretrait dans un JavaSpace (avec conformit)unotification de l'criture d'une entre conformeutransaction groupant plusieurs oprations

(sur potentiellement plusieurs JavaSpaces)upersistance

v par srialisation des objets d'une entre


Positionnement de JavaSpaces

oDiffrence avec bases de donnesupas de langage de requteuslection de donnes par "conformit" (vis--vis d'un modle)upas de modification sur les donnes de la base (ajouts et

retraits seulement)uutilisation : espace de travail partag pour applications

coopratives

oDiffrence avec Lindau les entres et les objets sont typsugestion possible de plusieurs espacesutransactions


JavaSpaces : interface de programmation

o Les primitivesuwrite : dept d'une nouvelle entreuread : lit une entre conforme un templateutake : lit et retire une entre conforme un templateunotify : enregistre une notification envoyer lorsqu'une

nouvelle entre conforme un template est critev la mthode notify du gestionnaire d'vnement (listener) est

appeleutemplate : modle pour la recherche d'entres dans un

JavaSpace


JavaSpaces : transactions (1)

o Les transactionsuavec write

v criture visible ssi la transaction valide (commit)v si write suivi de take dans une transaction : pas visible de

l'extrieuruavec read

v recherche dans les JavaSpaces et dans les dpts de la transaction en cours (sans ordre)

v une entre lue (read) ne peut pas tre retire (taken) par une autre transaction


JavaSpaces : transactions (2)

o Les transactions (suite)uavec take

v une entre retire (taken) ne peut tre lue (read) ou retire (taken) par une autre transaction

uavec notifyv hors transaction, les notifications de voient que les critures

validesv dans une transaction, les notifications voient en plus les critures

internes la transactionv la fin d'une transaction annule les dfinitions de notification dans

la transactionuLes proprits ACID sont respectes


Modle espace de tuples : conclusion

oUtilisationucoordination entre applications rpartiesudcouplage entre le client et le serveururemarque : ncessite toujours au moins le partage d'une

interface (comme RMI) ...o Implantations possibles

uclient/serveur : requtes distantes depuis tous les clientsuobjets dupliqus : localit des accs la base

otat des lieuxuUne version fournie dans l'environnement Jini

v liaison dynamique des ressources dans un rseau


Modles objets rpartis partags

oModle de programmationumodle objetsumodle d'excution

v objets "actifs" versus objets "passifs"u langage de programmation d'applications rparties intgrant

distribution, paralllisme, synchronisation, persistance, etc.v extension d'un langage existant (pre-processeur) ou langage ad-hoc

o Principes de mise en uvreudsignation : rfrences universelles d'objetsugestion de la persistanceugestion du partage : synchronisation, cohrence

v image unique d'un objet versus copies (cohrentes) d'un objet


Modle objets dupliqus : principe directeur

oExtension un systme objets des mthodes de partage :

ude la mmoire commune dans un SMPudun systme de fichiers (NFS)ude mmoire virtuelle dans Unix


Modle objets dupliqus : exemple (1)

o Partage de la mmoire commune dans un SMPucache associ chaque processeuruMise jour immdiate (write -through) ou retarde (write -

back)

mmoirecommune

processeur processeur

cache cache



o Partage dun systme de fichier (NFS)ucache NFS sur les sites clientsu invalidations priodiques

partition exporte

partition monte



o Partage de mmoire virtuelle (Unix)upartage de segments (suite de pages)upartage de la mmoire centrale par couplage

mmoirecentrale

processusUnix

segment


Modle objets dupliqusPrincipe de fonctionnement

o Principe ufournir des objets partags par couplage d'objets (distants)

dans les espaces dadressage locauxo Partage par copie locale

uefficacit des accs locauxo Programmation simple

utransparence de la distributiono Le systme prend en charge

u le chargement " la demande" des copies des donnes (lunit de transfert nest pas forcment lobjet)

u la gestion de la cohrence des donnes partages rpliques


Modle objets dupliqusGestion de la cohrence

oModle de cohrence urelation entre les diffrentes copies des donnes

oCohrence squentielleusrialisation des accs aux donnes partages

oCohrences relchesuassocie cohrence et points de synchronisation dfinis

explicitement par l'applicationv cohrence faible (weak consistency)v cohrence la sortie (release consistency)v cohrence l'entre (entry consistency)

oCohrences non-squentiellesucohrence causale


Modle objets dupliqusDsignation et liaison

oNommage : gestion des noms des objetsuGestion des noms en espace de stockage (rfrences)uGestion des noms en espace d'excution (adresses)

o Liaison : opration de traduction des nomsuespace de noms "unique"

v les noms d'objets sont des adresses dans cet espaceuespaces de noms distincts

v traduction des noms ] lors de l'accs initial,] chaque accs


Modle objets dupliqusApplication Java

oJavanaise : systme de gestion d'objets Java partags et rpartis

JVM machine 1 JVM machine 2

mmoire dobjets rpartie

application Copie_1Copie_2

Imagepersistante


Javanaise : applications (1)

oUn diteur coopratif

document partag


Javanaise : applications (2)

o Partage de lenvironnement de courrier

Rlogin THERE

setenv DISPLAY HERE

Netscape

Browser

edit preferences

("leave on server")

Browser

Objets partags (folders)

Station de travail

"Folders"

Partage des "folders" (avec cache)

Serveurde

messagerie

Pas de gestiondes "folders"


Javanaise : principes directeurs

o "Conserver" le modle de programmation de Java

o "Laisser" au systme :u le chargement des copies d'objets la demande sur les sites

d'excutionu la gestion de la cohrence des copies d'objets

* le systme est ralis par un ensemble de classes Java pr-dfinies (et tlchargeables la demande)


Javanaise : modle de programmation (1)

oUnit de duplication : objet globaluun graphe dobjets Java (objets locaux)u la racine du graphe est le seul point dentre de lobjet globaluun objet local ne peut pas tre partag entre des objets globauxuune rfrence externe ne peut rfrencer quun objet global

objet global

rfrence externe


Javanaise : modle de programmation (2)

o Le programmeur dfinit les classes globalesuapproche similaire aux classes "Remote" de RMIu les signatures des mthodes ne peuvent inclure que des

rfrences des classes globales

oUn compilateur ugnre du code appelant les mcanismes systmes grant les

objets ( partir des interfaces des classes globales)* code des talons


Javanaise : chargement

oUnit de chargement uobjet global usrialisation du graphe d'objets locaux

o Liaison dynamique des rfrences externesuun reprsentant (proxy out) pour chaque rfrence externe

dans un objet globalu inclut un identifiant unique et une rfrence Java l'objet

global s'il est prsent


Javanaise : cohrence

o Invalidation / mise jour des objets globauxuun reprsentant (proxy in) dans l'objet global rfrncumme structure que proxy out


Javanaise : passage de paramtres

o Paramtres des mthodes des classes globalesuseulement des rfrences des objets globauxu les proxies sont responsables de l'installation des proxies associs

aux paramtres changs

ref X

passe ref X comme paramtre

ref X


Modle objets dupliqus : conclusion

oConclusionu intrts du modle objets dupliqus

v dveloppement simplifi (distribution transparente)v favorise les accs locaux (efficacit)

o Limites et perspectivesuquel protocole de cohrence ?

v spcialisation de protocoles existantsuapproche mono-langageucot du maintien de la cohrence des donnes dupliques

v adapter la stratgie de mise en uvre du partage aux besoins des applications et aux conditions de l'environnement d'excution


Modes de structuration d'applications rparties : Synthse

TCP/IP

Communication par messages (exemple : interface "sockets ")

Appel de procdure/mthode distance

Bus logiciel

Http Dcom Corba

Agentsmobiles

M.V. Java

* Hirarchie de modles

GuideOodeJavaSpaces composantsJavanaise


Quel modle ? Pour quelle application ?

oDveloppement de nouvelles applications versus intgration/extension d'applications existantes

oMode de synchronisation usynchrone versus asynchrone

oGestion des informations partagesu image unique versus copies locales

(migration du contrle, migration des donnes, migration du code)

oApproche "langage" versus approche "systme"ueffort de programmation versus complexit du systme

oGnralisation des technologies base d'objets/composantsuprogrammation "in the small" : objetsuprogrammation "in the large" : composants


Rfrences bibliographiques (1)

Rfrences gnrales

S. Mullender, Distributed Systems, Addison-Wesley, 1989

G. Coulouris, J. Dollimore, T. Kindberg, Distributed Systems : Concepts and Design, 2nd Edition, Addison-Wesley, 1994

A. Tanenbaum, "Systmes d'exploitation : systmes centraliss, systmes distribus", InterEditions, 1994

R. Balter, J.-P. Bantre, S. Krakowiak, Construction des systmes dexploitation rpartis, Collection Didactique de l'INRIA, 1991



Modle client-serveur et RPC

A. Birrell, B. Nelson, "Implementing Remote Procedure Calls", ACM Trans. on Computer Systems, Vol. 2, 1984

W. Rosenberg, D. Kenney, G. Fisher, Comprendre DCE, Addison-Wesley, 1993

http://www.osf.org/dce

http://www.omg.orghttp://www.omg.org/corba.htm

J.-M. Geib, C. Gransart, P. Merle, "Corba : des concepts la pratique", InterEditions, 1997

http://www.odmg.org

R. Cattell, Object Databases : The ODMG-93 Standard, Morgan & Kaufman Ed., 1993

G. Gardarin, O. gardarin, "Le client-serveur", Eyrolles, 1996



Modles message et modles vnements

S. Reiss, "Connecting Tools using message passing in the FIELD environment", IEEE Software, juillet 1990

J. Arnold, G. Memmi, "Intgration par le contrle et son rle dans l'intgration de logiciels", Proc. of ICSE'92, Toulouse, Dcembre 1992

http://www.software.ibm.com/ts/mqseries

G. Agha, "Actors: A model of concurrent computation in distributed systems", Series in Artificial Intelligence, 1986

http://www.openhorizon.com

http://www.rv.tibco.com

http://www.softwired.ch/ ibus

M. Rozier et al., "Chorus Distributed Operating System", Computing Systems, Vol 1, N 4, octobre 1988



Modles mmoire partage

D. Gelernter, Generative Communication in Linda, ACM Transactions on Programming Languages and Systems , Vol. 7, No. 1, pp. 80-112, Janvier 1985.

The JavaSpaces Specification, Sun Microsystems Inc ., 1998.

J. S. Chase, H. M. Levy, E. J. Feeley, E. D. Lazowska, "Sharing and Protection in a Single-Address-Space Operating System", ACM Transactions on Computer Systems , 12 (4), pp. 271-307, Novembre 1994.

D. Mosberger, Memory Consistency Models, Operating Systems Review, 27(1), pp. 18-26, Janvier 1993.

D. Hagimont, D. Louvegnies, Javanaise: Distributed Shared Objects for InternetCooperative Applications, IFIP International Conference on Distributed Systems Platforms and Open Distributed Processing (Middleware98), Septembre 1998.

D. Hagimont, J. Mossire , Problmes de dsignation, de localisation et daccs dans les systmes rpartis objets, Technique et Science Informatiques (TSI), 15(1), 1996.

R. Balter, S. Krakowiak, "Retrospective sur le projet Guide : un environnement base d'objets pour applications rparties, L'Objet, Vol. 3 (2), juin 1997


Annexes

o Modle client-serveur et RPCu mise en uvre d'un serveuru RPC - principes de fonctionnementu RPC - traitement des dfaillancesu RPC - passage des paramtresu DCE - description des services

o Modle message/vnementu micro-noyauu publish-subscribeu JMS

o Modle mmoire partageu JavaSpacesu modles de cohrenceu dsignation et liaisonu Javanaiseu Guide/Oode

Documents

Mode de structuration d'applications réparties.pdf