Mode de structuration d'applications réparties.pdf

Modes de structuration d’applications réparties Rolan oland d Balt er

Modes de s truct uratio n d’appli cations répart ies - 1

Autr ans - 99

Problématique (1) o

application répartie = traitements coopérants sur des données réparties u traitements

:

v description

: programme v exécution : flot d'exécution (processus) o

coopération = communication + synchronisation u modèle d

’exécuti ’exécution on u interface de programmation (et/ou langage) v modèle

de programmation

u outils

de développement environnement d'exécution : services systèmes u environnement (pour différents types d'infrastructures) Modes de s truct uratio n d’appli cations répart ies - 2

Autr ans - 99

Page 1

Problématique (2) Méthodes et outils de modélisation

Modèle d’exécution

outils de développement

middleware

Service Servicess applicatif applicatifss fichiers répartis, moniteur transactionnel, accès BD, ...

Services systèmes communication, RPC, désignation, sécurité, ...

outils d’ administration

Système d’exploitation d’exploitation Machines et Réseaux Modes de s truct uratio n d’appli cations répart ies - 3

Autr ans - 99

Modèles d’exécution o

Modèle client-serveur client-serveur -serveur u client

"traditionnel" u client-serveur "de données" client-serveur "à objets" : Corba, Corba, Com/Dcom ( mardi ) u client-serveur

Modèle de communication par messages o Modèle de communication par événements o Modèle à composants ( mercredi ) o Modèle à base de code mobile (jeudi) o Modèle à mémoire "virtuelle" partagée o


Autr ans - 99

Page 2

Problématique (2) Méthodes et outils de modélisation

Modèle d’exécution

outils de développement

middleware

Service Servicess applicatif applicatifss fichiers répartis, moniteur transactionnel, accès BD, ...

Services systèmes communication, RPC, désignation, sécurité, ...

outils d’ administration

Système d’exploitation d’exploitation Machines et Réseaux Modes de s truct uratio n d’appli cations répart ies - 3

Autr ans - 99


Modèle client-serveur client-serveur -serveur u client

"traditionnel" u client-serveur "de données" client-serveur "à objets" : Corba, Corba, Com/Dcom ( mardi ) u client-serveur

Modèle de communication par messages o Modèle de communication par événements o Modèle à composants ( mercredi ) o Modèle à base de code mobile (jeudi) o Modèle à mémoire "virtuelle" partagée o


Autr ans - 99

Page 2

Modèle client-serveur : principes directeurs Service_1

Client_a

. .

Serveur

Service_n

Client_b

Client

Serveur

émet des requêtes (demandes de service)

ensemble de services exécutables

mode d'exécution synchrone

exécute des requêtes émises par des clients -> exécution des services (exécution séquentielle ou parallèle)

le client est l'initiateur du dialogue clientserveur

Exemples :

serveur de fichiers, serveur de base de données, serveur d'impression, serveur de noms (annuaire des services)


Autr ans - 99

Modèle client-serveur : principes (2) o

Vu du client

Requête client Réponse

o

Service distant

Vu du serveur u Gestion

des requêtes (priorité) u Exécution du service (séquentiel, concurrent) u Mémorisation ou non de l'état du client Sélection Requêtes


Exécution du service

Réponses

Autr ans - 99

Page 3

Mise en œuvre du modèle client-serveur o

Appel de procédure à distance (Rem emo ot e

) Prr oc P ocedu edurr e Call u L'opération à réaliser est présentée sous la forme d'une procédure (le service), située sur un site distant distant,, dont le client demande l'exécution u Objectif : forme et effet " identiques " à ceux d'un appel local v interface

de programmation v sémantique u Opérations

de base

v Client ] doOp

(IN Port Port server serverId, Id, Name opName opName, Msg *arg, OUT Msg Msg *resul *result) t)

v Serveur

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


RPC

[Birr [Bi rrel el & Nel elso sonn 84 84]]

Service RPC

Appelant

(talon client) ( stub stub))

Autr ans - 99

: principe de réalisation Protocole de Service RPC communication (talon serveur) ( skeleton skeleton))

Protocole de communication

A

appelé

B appel

appel

C

réseau E

D

retour

retour

client

serveur


Page 4

Autr ans - 99

RPC : rôle des talons Talon client - stub o

Talon serveur - skeleton

procédure d’interface sur le site client

o

u reçoit

l’appel en mode local, u "emballe" les paramètres et le transforme en appel distant en envoyant un message, u attend les résultats en provenance du serveur, u "déballe" les paramètres résultats, et les retourne au programme client "comme" dans un retour de procédure local. u Liaison initiale

procédure d'interface sur le site serveur u reçoit

l’appel sous forme de message, u "déballe" les paramètres d'appel, u fait réaliser l’exécution sur le site serveur par la procédure de service invoquée, u "emballe" les paramètres résultats et les retransmet par message. u Enregistrement

initial


Autr ans - 99

Langages de description d'interfaces (IDL) o

Motivations u Spécification

commune au client et au serveur * contrat entre le client et le serveur u Définition du type et de la nature des paramètres (IN, OUT, IN-OUT) u Indépendance des langages de programmation o

Principes directeurs u Langage

déclaratif u Outils de génération des talons ( stub et skeleton)


Autr ans - 99

Page 5

IDL : chaîne de compilation Procédure Procédure du duclient client

Description d ’interface

compilateur compilateur talon talon client client

Générateur de talons

Procédure Procédure du duserveur serveur

Définitions communes

bibliothèque

talon talon serveur serveur

compilateur compilateur


Appel o

d i st a nt versus

Programme Programme client client

Programme Programme serveur serveur Autr ans - 99

appel

local

Objectifs u préserver

la sémantique habituelle de l ’appel de procédure u "transparence" de la distribution : programmation "identique" à celle d'un appel local o

Objectifs difficiles à atteindre u réalisation

peu conviviale (même avec l'utilisation d'un IDL) u sémantique différente de l ’appel de procédure même en l ’absence de panne v exemple

: passage des paramètres par référence

* sé mant ique pr é ci se f onct ion d e l ' impl é ment at ion d u RPC


Autr ans - 99

Page 6

RPC : quelques problèmes de mise en œuvre 4 Traitement des défaillances u panne et/ou congestion du réseau, u panne du client pendant le traitement de la requête, u panne du serveur avant ou pendant le traitement de la requête, 4 Gestion de l'Hétérogénéité 4 Désignation et liaison o

Problèmes de sécurité u authentification

du client et du serveur u confidentialité des échanges o

Aspects pratiques u adaptation

à des environnements d'utilisation variables (protocoles, langages, matériels) u performance Modes de s truct uratio n d’appli cations répart ies - 13

Autr ans - 99

RPC : traitement des défaillances o

En cas d'erreur : sémantique variable

(selon la nature du mécanisme de reprise mis en œuvre) u Indéfini u Au

plus une fois

v si

expiration du délai A alors erreur v pas de mécanisme de reprise u Au

moins une fois

v si

expiration du délai A alors ré-émission de la requête, v plusieurs exécutions possibles du service, v acceptable si opération idempotente u Exactement

une fois (idéal...)

v ré-émission

de la requête et/ou de la réponse si nécessaire, v élimination des "doublons"


Autr ans - 99

Page 7

RPC : traitement de l'hétérogénéité o

Problème : représentation des données u Conversion

nécessaire si le site client et le site serveur

vn

’utilisent pas le même système de codage (big endian versus little endian) v utilisent des formats internes différents (pour les types de base : caractère, entier, flottant, …) o

Solutions u Syntaxe

abstraite de transfert ASN 1 u Représentation externe commune : XDR Sun (non optimal si même représentation) u Représentation locale pour le client et conversion par le serveur u Choix d'une représentation parmi n (standard), conversion par le serveur u Négociation client serveur Modes de s truct uratio n d’appli cations répart ies - 15

Autr ans - 99

RPC : désignation et liaison (1) o

Problèmes u objets

à désigner : le site d ’exécution, le serveur, la procédure u désignation globale indépendante de la localisation v possibilité

charge, …)

o

de reconfiguration des services (pannes, régulation de

Mise en œuvre : statique ou dynamique u statique

: localisation du serveur connue à la compilation u dynamique : localisation déterminée à l'exécution (au premier appel) v séparer

connaissance du nom du service de la sélection de la procédure qui va l ’exécuter v permettre l ’implémentation retardée


Autr ans - 99

Page 8

RPC : désignation et liaison (2) o

Liaison : mise en œuvre communication logique

Programme client Talon client

2

Service de désignation

consult at ion Appel

Programme serveur Talon serveur

1 enregist r ement

3

Communication client

Communication serveur

communication physique


Autr ans - 99

Les limites du modèle client-serveur o

modèle de structuration u permet *

o

deux composants logiciels

absence de vision globale de l’application

u schéma *

de décrire l’interaction entre

d'exécution répartie élémentaire (appel synchrone)

absence de propriétés portant sur la synchronisation, la protection, la tolérance aux pannes , . .

services pour la construction d’applications réparties u le

RPC est un mécanisme de “bas niveau” u des services additionnels sont nécessaires pour la construction d’applications réparties (désignation, fichiers répartis, sécuri té, etc.) o

outils de développement u limités

à la génération automatique des talons u peu (ou pas) d’outils pour le déploiement et la mise au point d'applications réparties Modes de s truct uratio n d’appli cations répart ies - 18

Autr ans - 99

Page 9

Environnements client-serveur 4environnement u DCE

client-serveur "traditionnel"

(Distributed Computing Environment) :

v un

exemple d’environnement “intégré” d’applications réparties, fondé sur le modèle client-serveur

o

environnement client-serveur "à objet"

o

environnement client-serveur "de données"

o

environnement client-serveur "à composant"


Autr ans - 99

DCE : architecture générale

t n e m e p p o l e v é d e d s l i t u O

support de stations sans disque

autres services

service de fichiers répartis

authentification

gestion du temps

désignation

n o i t a r t s i n i m d a

appel de procédure à distance

processus légers (threads)


Autr ans - 99

Page 10

Atouts et limites de DCE + architecture de type “boîte à outils” u chaque

fonction est utilisable via une interface “normalisée” u accès direct à des fonctions évoluées ---> intégration “à gros grain”

+ “standard” de fait (diffusion dans la communauté

industrielle) u ex. : RPC, Service de noms, service d’authentification ---> portabilité et interopérabilité

– développement d’applications “à grain fin” laborieux u ex.

: utilisation des services de thread et du RPC (limitations équivalentes à celles du client-serveur) u peu d’outils de développement disponibles aujourd’hui Modes de s truct uratio n d’appli cations répart ies - 21

Autr ans - 99

Environnements client-serveur o

environnement client-serveur "traditionnel"

4environnement

client-serveur "à objet"

o


o



Autr ans - 99

Page 11

Client-serveur "à objet" o

Motivations u propriétés

de l’ objet (encapsulation, modularité, réutilisation, polymorphisme, composition) u objet : unité de désignation et de distribution o

Principe de fonctionnement objet client

objet serveur état

appel Talon client

Talon serveur

Methode_1 . . Methode_n

Système de com mu nic ation Modes de s truct uratio n d’appli cations répart ies - 23

Appel de m thode

Autr ans - 99

distance

Remot e Met hod I nvocat ion (RMI ) o

éléments d'une "invocation" u référence

d'objet ("pointeur" universel) u identification d'une méthode u paramètres d'appel et de retour (y compris signal d'exception) v passage

par valeur : types élémentaires et types construits v passage par référence o

objets "langage" u représentation

propre au langage : instance d'une classe u exemple : Java RMI o

objets "système" u représentation "arbitraire"

définie par l'environnement d'exécution u exemple : CORBA (--> mardi) Modes de s truct uratio n d’appli cations répart ies - 24

Autr ans - 99

Page 12

Client-serveur "à objet" : mise en œuvre Interface

état

Méthode_i

référence

talon client

Talon serveur

Référence d'objet + méthode + arguments

Objet Résultat ou exception

dé si g n ati o n env oi d e req uêtes ex é c u ti o n d e re q u ête Autr ans - 99 ret ou r d e ré su ltat




o


4environnement o

client-serveur "de données"



Autr ans - 99

Page 13

le client-serveur de données principes directeurs (1) Site client

Site Serveur

programme client

Mé d ia teu r

programme serveur

re q uête SQ L

ré su lt ats (tu ple s)


Autr ans - 99

Le client-serveur de donn es principes directeurs (2)

o

fonction du client u code

de l'application non lié aux données u dialogue avec l'utilisateur o

fonction du serveur u stockage

des données, gestion de la disponibilité et de la

sécurité u interprétation/optimisation des requêtes o

fonctions du “médiateur” u procédures de

connexion/déconnexion u préparation/communication de requêtes u gestion de caches (requêtes et résultats)


Autr ans - 99

Page 14

Le client-serveur de données environnement applicatif

o

Environnement Applicatif Commun (CAE) de l’X/OPEN u objectif

: portabilité des applications u interface applicative CLI (Call Level Interface) v standardisation

des appels SQL depuis un programme (C, Cobol, . .) v connexion/déconnexion, préparation/exécution des requêtes, . . . u protocole

d'échange standardisé RDA (Remote Data Access)

v partie

générique (dialogue et contrôle transactionnel) v partie spécifique SQL (codage commandes et résultats) o

Outils de développement u L4G

: intègre accès aux tables, contrôle, affichage, saisie, ...

u AGL

: fonctions des L4G + gestion d’un référentiel des objets

indépendants des langages de programmation langage cible : C (ou Cobol)

(schémas de données, code des opérations, enchaînement, . . .)


Autr ans - 99

Client-serveur de donn es : la solution ODBC Client

Serveur

Application

SGBD

Bibliothèque (DLL)

Pilote ODBC Local

Pilote ODBC global

Adaptateur

Fichiers Dbase

FAP

FAP


Autr ans - 99

Page 15

Client-serveur de données "à objet" : la solution ODMG

o

Objectifs u Portabilité

des sources d’une application sur divers “moteurs” de bases de données à objet

o

Principes directeurs u modèle objet = sur-ensemble du modèle OMG

un langage de Définition de Données : ODL (basé sur l’IDL OMG) u un langage de Requêtes : OQL, évolution de SQL u intégration complète des mécanismes dans le langage hôte : C++ (avec propositions d’évolution de la norme) et Smalltalk u


Autr ans - 99



o


o


4 environnement

client-serveur "à composant"


Autr ans - 99

Page 16

Client-serveur à "composants" (1) o

Motivations uà

l'origine, environnements pour la gestion de documents composites u automatisation du processus de création d’un document à partir d’informations hétérogènes fournies par des utilitaires différents u exemples : OLE/COM, OpenDoc/SOM o

Approche u interopérabilité

entre composants logiciels binaires

v environnements

homogènes v interaction de type client-serveur v format de données "pivot" et procédures de conversion


Autr ans - 99

Exemple : gestion de documents composites o

OLE

(Object Linking and Embedding)

Lien vers texte_1

Lien

texte-1

(Linking) Incorporation

copie de tableau_1

tableau_1 (Embedding)

Lien vers tableau_2

Lien

Tableau_2

(Linking)


Autr ans - 99

Page 17

Client-serveur à "composants" (2) o

Environnement d'intégration u modèle

et mécanismes pour réaliser l'interopérabilité entre "composants" logiciels autonomes v composant : unité de réutilisation et de construction d'applications réparties

u modèle

et mécanismes pour associer des propriétés nonfonctionnelles à des objets (ou groupes d'objets) v propriétés : persistance, exécution transactionnelle, qualité de service, . . . v composant : unité d'administration å mercredi


Autr ans - 99


Modèle client-serveur u client-serveur

"traditionnel" u client-serveur "de données" u client-serveur "à objets" : Corba, Com/Dcom ( mardi )

Modèle de communication par messages o Modèle de communication par événements o Modèle à composants ( mercredi ) o Modèle à base de code mobile (jeudi) o Modèle à mémoire "virtuelle" partagée 4


Autr ans - 99

Page 18

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

d'un mode de communication "ancien" . . . u Le

courrier électronique

v communication

de type asynchrone v listes de diffusion (communication de groupe) u Les

forums (News)

v communication

filtrée par "sujet" v abonnement avant réception o

. . à l'émergence de paradigmes de programmation u Années

70: Message Queuing (IBM MQ Series, etc. ) u modèles événements/réaction, publish/subscribe u modèles d'acteurs u programmation par agents (vendredi)


Autr ans - 99

Communication par messages : modèle de programmation o

Mode de synchronisation u Communication asynchrone v émission

non bloquante v réception bloquante (attente jusqu'à réception d'un message) o

Mode de communication u communication

directe entre processus ( acteurs, agents, . . .) u communication indirecte entre processus via des "portes" (boîtes aux lettres ) o

Mode de transmission u messages

possiblement typés


Autr ans - 99

Page 19

Communication par messages : exemple 1 o

Réalisation d'un échange asynchrone

Processus émetteur

Processus récepteur

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

.


Autr ans - 99

Communication par messages : exemple 2 o

Réalisation d’une interaction de type « clientserveur » Serveur

Client bal_S

Send(bal-S, nom-de-service, paramètres)

.

(nom _de_serv ice, paramètres, bal_C)

bal_C

.

Msg = Receive(bal_S) exec (nom_de_service, paramètres) . . Send (bal-C, résultat)

su lt at ) ( ré


Autr ans - 99

Page 20

Communication par messages : API et mise en œuvre o

Environnement de type "micro-noyau" u mécanisme

et primitives de base u exemples : Chorus, Mach/OSF-1 o

Environnement "à la unix" u "sockets"

o

Environnement de programmation parallèle u PVM

o

et/ou MPI

Environnement "industriel" d'intégration d'applications u middleware

à messages: MOM u interface de programmation ad hoc v tentative

de normalisation via Java JMS


Autr ans - 99

"Middleware" à messages : MOM o

Principes directeurs u couche

o

Application

de logiciel sur le système hôte

Modèle de programmation u messages u queues

o

MOM

MOM

Système hôte

Système hôte

de messages

Propriétés u transactions v messages

vus comme des ressources "transactionnelles"

u sécurité v encodage

des messages v contrôle d'accès aux messages


Autr ans - 99

Page 21

MOM : messages Identification unique o Structure o

u Entête

:

v Information

message

u Attributs

permettant l'identification et l'acheminement du

:

v Couples

(nom, valeur) utilisables par le système ou l'application pour sélectionner les messages

u Données

:

v Définies

o

par l'application

Paramètres u durée

de vie u priorité u sécurité Modes de s truct uratio n d’appli cations répart ies - 43

Autr ans - 99

MOM : queues de messages identification unique o persistantes (résistance aux défaillances) o partagées par les applications o modes de réception variable o

Serveur

Client

send

recv


Autr ans - 99

Page 22

MOM : API MsgQ.attach(name, type) Ü msgQ o SendQ.sendMsg(msg) o RecvQ.recvMsg(wait) Ü msg o RecvQ.confirmMsg(msg) o MsgQ.detach() o


Autr ans - 99

Communication par messages

extensions au modèle de base

o

Communication de groupe u groupe :

ensemble de récepteurs identifiés par un nom unique u gestion dynamique du groupe : arrivée/départ de membres u différentes politiques de service dans le groupe : 1/N, N/N u mise en œuvre : utilisation possible de IP multicast u exemple : Isis, Horus, Ensemble (Cornell university) u applications : tolérance aux fautes (gestion de la réplication), travail coopératif o

Communication anonyme u dé signat ion assoc iat ive :

les récipiendaires d'un message sont identifiés par leurs propriétés et pas par leur nom u propriété : attribut du message ou identificateur externe èindépendance entre émetteur et récepteurs Modes de s truct uratio n d’appli cations répart ies - 46

Autr ans - 99

Page 23

Modèles d'exécution o



Modèle de communication par messages 4 Modèle de communication par événements o Modèle à composants ( mercredi ) o Modèle à base de code mobile (jeudi) o Modèle à mémoire "virtuelle" partagée o


Autr ans - 99

Communication v nementielle : principes de fonctionnement o

concepts de base :

é vé nement s , r é ac t ions u réaction : traitement associé à l’occurrence d’un événement

o

principe d’attachement u association

o

dynamique entre un nom d’événement et une réaction

communication anonyme u indépendance

entre l’émetteur et les “consommateurs” d’un

événement Nom (type) d'événement

canaux de communication Processus

Processus émetteurs

é vé n em en ts

ré ac tio n s


destinataires

Autr ans - 99

Page 24

Communication événementielle (publish/subscribe) principes de réalisation Processus_a Pu b l i s h (event)

Processus_b

2

1 Subscribe (event, reaction)

Gestion des événements et des abonnements

. . 3

reaction

serveur centralisé ("Hub and Spoke") serveur réparti ("Snowflake") service réparti (bus logiciel) Modes de s truct uratio n d’appli cations répart ies - 49

Autr ans - 99

Gestion des événements o

Mode "Pull" u Les

clients viennent "prendre" périodiquement leurs messages sur le serveur.

o

Mode "Push" u Une

méthode prédéfinie ( réaction ) est attachée à chaque type de message (événement) ; u l'occurrence d'un événement entraîne l'exécution de la réaction associée.


Autr ans - 99

Page 25

Architecture - "Hub and Spoke" o

Serveur centralisé de gestion d'événements protocole de communication point-à-point

Client Client

Client

Broker

Client

Client Client


Autr ans - 99

Architecture - "Snowflake" o

Serveur réparti de gestion d'événements protocole de communication point-à-point Client Broker Client

Broker Client

Client Client Broker Client


Autr ans - 99

Page 26

Architecture - bus de message o

Service réparti de gestion d'événements protocole de communication multicast

Client

Client

Client

Client

Bus

Bus

Hub

Hub

Bus

S.E.

S.E.

S.E.

S.E.

S.E.

Machine A

Machine B

Machine B

Machine B

Machine C


Autr ans - 99

Java Message Service (JMS) o

Objectif : API Java d'accès uniforme aux systèmes de messagerie u IBM

MQSeries u Novell, Oracle, Sybase u Tibco u. . . o

Propriétés u Point-à-Point u Publish/Subscribe


Autr ans - 99

Page 27

JMS : principe de fonctionnement

Client

Client

Client

JMS

JMS Client

Provider X

Client

JVM

Provider X JVM

MQ X

MQ X

MQ X

MQ X


Autr ans - 99

JMS - Architecture

JNDI Destination

JMS Client ConnectionFactory +

MessageProducer

Connection +

MessageConsummer

Session


Autr ans - 99

Page 28

Communication événementielle : conclusion o

Domaines d'application u génie

logiciel (coopération entre outils de développement) : SoftBench, ToolTalk , DecFuse, . . u workflow : KoalaBus, . . u Intégration/extension d'applications existantes : AAA, . . 4diffusion de logiciels et d'information sur le Web : iBus, Castanet, Ambrosia, Smartsockets, TIB/Rendezvous, Active Web , o

Infrastructures propriétaires u interface

applicative et protocoles propres à chaque système ---> problèmes de portabilité et d’interopérabilité

o

Outils de développement u sommaires


Autr ans - 99




Modèle de communication par messages o Modèle de communication par événements o Modèle à composants ( mercredi ) 4Modèle à base de code mobile (jeudi) o Modèle à mémoire "virtuelle" partagée o


Autr ans - 99

Page 29

Code mobile o

Définition u programmes u exemples

o

pouvant se déplacer d'un site à un autre

: requête SQL, "applet" Java

Motivations u rapprocher

le traitement des données

v réduire

le volume de données échangées sur le réseau v partage de charge 4function shipping versus data shipping o

Caractéristiques u code

interprétable u sécurité u schémas d'exécution à base de code mobile


Autr ans - 99

Modèles d'exécution pour la mobilité o

code "à la demande"

Site A

u mobilité

"faible" (code exécutable, sans contexte) u exemple : "applet" Java o

Site B Processus

code

code

Site A

Site B

agents mobiles u mobilité

"faible"

v code

exécutable + données modifiées v exemple : Aglets u mobilité

"forte"

exécutable, + données + contexte d'exécution v exemples : AgentTcl

Processus_a

Processus_b

code

code

v code


ctx.

ctx.

Autr ans - 99

Page 30




Modèle de communication par messages o Modèle de communication par événements o Modèle à composants ( mercredi ) o Modèle à base de code mobile (jeudi) 4Modèle à mémoire "virtuelle" partagée o


Autr ans - 99

Systèmes à mémoire partagée (1) o

Motivations u (re)placer

le programmeur d'application dans les conditions d'un système centralisé v utiliser

une mémoire commune comme espace de communication v synchronisation par variables partagées u avantages

attendus ( pour le programmeur)

v simplicité :

distribution "transparente" v efficacité : utilisation des paradigmes usuels de la programmation concurrente *

problématique u utilisation

des outils de développement existants : langages, compilateurs, metteurs au point, . . . u mise en œuvre "efficace" d'une mémoire partagée distribuée Modes de s truct uratio n d’appli cations répart ies - 62

Autr ans - 99

Page 31


Principe de réalisation u " simulation"

d'une mémoire globale (d'objets) partagée Site B

Site A

Site C

Objets Objetspartagés partagés Modes de s truct uratio n d’appli cations répart ies - 63

Autr ans - 99


Approches u Modèles

à espace de tuples

v base

de données (de tuples) partagée v modèle de programmation "à la Linda" ]

dépôt, retrait, et consultation d'objets

v exemple

u Modèles

: JavaSpaces

à objets répartis partagés

v espace

d'objets répartis partagés v interface de programmation : langage à objet "étendu" v plusieurs modes de réalisation ] objets répliqués (exemple : Javanaise) ] objets à image unique (exemple : Guide)


Autr ans - 99

Page 32

JavaSpaces : modèle (1) Un JavaSpace : un espace de tuples (entrées) o Une entrée : un ensemble de champs o Un champ : une référence à une instance Java o

entrée

JavaSpace


Autr ans - 99

JavaSpaces : modèle (2) o

Opérations de base u écriture

dans un JavaSpace (dépôt) u lecture dans un JavaSpace ( avec conformité ) u retrait dans un JavaSpace ( avec conformité ) u notification de l'écriture d'une entrée conforme u transaction groupant plusieurs opérations (sur potentiellement plusieurs JavaSpaces) u persistance v par

sérialisation des objets d'une entrée


Autr ans - 99

Page 33

Positionnement de JavaSpaces o

Différence avec bases de données u pas

de langage de requête u sélection de données par "conformité" (vis-à-vis d'un modèle) u pas de modification sur les données de la base (ajouts et retraits seulement) u utilisation : espace de travail partagé pour applications coopératives o

Différence avec Linda u les

entrées et les objets sont typés u gestion possible de plusieurs espaces u transactions Modes de s truct uratio n d’appli cations répart ies - 67

Autr ans - 99

JavaSpaces : interface de programmation

o

Les primitives u write

: depôt d'une nouvelle entrée u read : lit une entrée conforme à un template u take : lit et retire une entrée conforme à un template u notify : enregistre une notification à envoyer lorsqu'une nouvelle entrée conforme à un template est écrite v la

méthode notify du gestionnaire d'événement (listener ) est appelée

u template

: modèle pour la recherche d'entrées dans un JavaSpace


Autr ans - 99

Page 34

JavaSpaces : transactions (1) o

Les transactions u avec

write

v écriture visible

ssi la transaction valide (commit) v si write suivi de take dans une transaction : pas visible de l'extérieur u avec

read

v recherche

dans les JavaSpaces et dans les dépôts de la transaction en cours (sans ordre) v une entrée lue (read) ne peut pas être retirée (taken) par une autre transaction


Autr ans - 99

JavaSpaces : transactions (2) o

Les transactions (suite) u avec

take

v une

entrée retirée (taken ) ne peut être lue (read) ou retirée (taken) par une autre transaction

u avec

notify

v hors

transaction, les notifications de voient que les écritures validées v dans une transaction, les notifications voient en plus les écritures internes à la transaction v la fin d'une transaction annule les définitions de notification dans la transaction u Les

propriétés ACID sont respectées


Autr ans - 99

Page 35

Modèle à espace de tuples : conclusion o

Utilisation u coordination

entre applications réparties u découplage entre le client et le serveur u remarque : nécessite toujours au moins le partage d'une interface (comme RMI) ... o

Implantations possibles u client/serveur

: requêtes distantes depuis tous les clients u objets dupliqués : localité des accès à la base o

État des lieux u Une

version fournie dans l'environnement Jini

v liaison

dynamique à des ressources dans un réseau


Autr ans - 99

Modèles à objets répartis partagés o

Modèle de programmation u modèle

à objets u modèle d'exécution v objets

"actifs" versus objets "passifs"

u langage

de programmation d'applications réparties intégrant distribution, parallélisme, synchronisation, persistance, etc. v extension

o

d'un langage existant (pre-processeur) ou langage ad-hoc

Principes de mise en œuvre u désignation

: références universelles d'objets u gestion de la persistance u gestion du partage : synchronisation, cohérence v image

unique d'un objet versus copies (cohérentes) d'un objet


Autr ans - 99

Page 36

Modèle à objets dupliqués : principe directeur o

Extension à un système à objets des méthodes de partage : u de

la mémoire commune dans un SMP u d’un système de fichiers (NFS) u de mémoire virtuelle dans Unix


Autr ans - 99

Modèle à objets dupliqués : exemple (1) o

Partage de la mémoire commune dans un SMP u cache

associé à chaque processeur u Mise à jour immédiate ( write-through) ou retardée ( writeback)

processeur

processeur

cache

cache

mémoire commune Modes de s truct uratio n d’appli cations répart ies - 74

Autr ans - 99

Page 37


Partage d’un système de fichier (NFS) u cache

NFS sur les sites clients u invalidations périodiques

partition montée

partition exportée


Autr ans - 99


Partage de mémoire virtuelle (Unix) u partage

de segments (suite de pages) u partage de la mémoire centrale par couplage

processus Unix

segment

mémoire centrale Modes de s truct uratio n d’appli cations répart ies - 76

Autr ans - 99

Page 38

Modèle à objets dupliqués Principe de fonctionnement o

Principe u fournir

des objets partagés par couplage d'objets (distants) dans les espaces d’adressage locaux

o

Partage par copie locale u efficacité

o

des accès locaux

Programmation simple u transparence

o

de la distribution

Le système prend en charge u le

chargement "à la demande" des copies des données (l’unité de transfert n’est pas forcément l’objet) u la gestion de la cohérence des données partagées répliquées


Autr ans - 99

Modèle à objets dupliqués Gestion de la cohérence o

Modèle de cohérence u relation

o

entre les différentes copies des données

Cohérence séquentielle u sérialisation

o

des accès aux données partagées

Cohérences relâchées u associe

cohérence et points de synchronisation définis explicitement par l'application v cohérence

faible (weak consistency ) v cohérence à la sortie (release consistency) v cohérence à l'entrée ( entry consistency) o

Cohérences non-séquentielles u cohérence

causale


Autr ans - 99

Page 39

Modèle à objets dupliqués Désignation et liaison o

Nommage : gestion des noms des objets u Gestion

des noms en espace de stockage ( références ) u Gestion des noms en espace d'exécution ( adresses) o

Liaison : opération de traduction des noms u espace v les

de noms "unique" noms d'objets sont des adresses dans cet espace

u espaces

de noms distincts

v traduction ] ]

des noms

lors de l'accès initial, à chaque accès


Autr ans - 99

Modèle à objets dupliqués Application à Java : système de gestion d'objets Java partagés et répartis

o J avanaise

Copie_1

application

JVM machine 1

Copie_2

JVM machine 2 mémoire d’objets répartie

Image persistante Modes de s truct uratio n d’appli cations répart ies - 80

Autr ans - 99

Page 40

Javanaise : applications (1) o

Un éditeur coopératif

document partagé


Autr ans - 99

Javanaise : applications (2) o

Partage de l’environnement de courrier

Rlogin THERE

Browser

Browser

setenv DISPLAY HERE

edit preferences

Netscape

("leave on server")

Objets partagés (folders)

Pas de gestion des "folders"

Serveur de messagerie Station de travail

Partage des " folders" (avec cache)

"Folders" Modes de s truct uratio n d’appli cations répart ies - 82

Autr ans - 99

Page 41

Javanaise : principes directeurs

o

"Conserver" le modèle de programmation de Java

o

"Laisser" au système : u le

chargement des copies d'objets à la demande sur les sites d'exécution u la gestion de la cohérence des copies d'objets le système est réalisé par un ensemble de classes Java prédéfinies (et téléchargeables à la demande)

*


Autr ans - 99

Javanaise : modèle de programmation (1) o

Unité de duplication : objet global u un

graphe d’objets Java (objets locaux) u la racine du graphe est le seul point d’entrée de l’objet global u un objet local ne peut pas être partagé entre des objets globaux u une référence externe ne peut référencer qu’un objet global

référence externe objet global Modes de s truct uratio n d’appli cations répart ies - 84

Autr ans - 99

Page 42

Javanaise : modèle de programmation (2) o

Le programmeur définit les classes globales u approche

similaire aux classes " Remote" de RMI u les signatures des méthodes ne peuvent inclure que des références à des classes globales

o

Un compilateur u génère

du code appelant les mécanismes systèmes gérant les objets (à partir des interfaces des classes globales) * code des talons


Autr ans - 99

Javanaise : chargement o

Unité de chargement u objet

global u sérialisation du graphe d'objets locaux o

Liaison dynamique des références externes u un

représentant ( proxy out) pour chaque référence externe dans un objet global u inclut un identifiant unique et une référence Java à l'objet global s'il est présent


Autr ans - 99

Page 43

Javanaise : cohérence o

Invalidation / mise à jour des objets globaux u un

représentant ( proxy in) dans l'objet global référéncé u même structure que proxy out


Autr ans - 99

Javanaise : passage de paramètres o

Paramètres des méthodes des classes globales u seulement

des références à des objets globaux u les proxies sont responsables de l'installation des proxies associés aux paramètres échangés passe ref X comme paramètre

ref X

ref X


Autr ans - 99

Page 44

Modèle à objets dupliqués : conclusion o

Conclusion u intérêts

du modèle à objets dupliqués

v développement

simplifié (distribution transparente) v favorise les accès locaux (efficacité) o

Limites et perspectives u quel

protocole de cohérence ?

v spécialisation

de protocoles existants

u approche

mono-langage u coût du maintien de la cohérence des données dupliquées v adapter

la stratégie de mise en œuvre du partage aux besoins des applications et aux conditions de l'environnement d'exécution


Autr ans - 99

Modes de structuration d'applications réparties : Synthèse *

H ié r ar ch ie d e modèles

JavaSpaces

M.V. Java

Javanaise

Http

Dcom

Guide Oode

composants

Corba

Appel de procédure/méthode à distance

Bus logiciel

Agents mobiles

Communication par messages (exemple : interface "sockets")

TCP/IP Modes de s truct uratio n d’appli cations répart ies - 90

Autr ans - 99

Page 45

Quel modèle ? Pour quelle application ? Développement de nouvelles applications versus intégration/extension d'applications existantes o Mode de synchronisation o

u synchrone

o

versus asynchrone

Gestion des informations partagées u image

unique versus copies locales

(migration du contrôle, migration des données, migration du code)

o

Approche "langage" versus approche "système" u effort

o

de programmation versus complexité du système

Généralisation des technologies à base d'objets/composants u programmation

"in the small" : objets u programmation "in the large" : composants Modes de s truct uratio n d’appli cations répart ies - 91

Autr ans - 99

Références bibliographiques (1) Références générales S. Mullender, “Distributed Systems”, Addison-Wesley, 1 989 G. Coulouris, J. Dollimore, T. Kindberg, “Distributed Systems : Concepts and Design”, 2nd Edition, Addison-Wesley, 1994 A. Tanenbaum, "Systèmes d'exploitation : systèmes centralisés, systèmes distribués", InterEditions, 1994 R. Balter, J.-P. Banâtre, S. Krakowiak, “Construction des systèmes d’exploitation répartis”, Collection Didactique de l'INRIA, 1991


Autr ans - 99

Page 46

Références bibliographiques (2) Modèle 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.org http://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


Autr ans - 99

Références bibliographiques (3) Modèles à message et modèles à événements S. Reiss, "Connecting Tools using message passing in the FIELD environment", IEEE Software, juillet 1990 J. Arnold, G. Memmi, "Intégration par le contrôle et son rôle dans l'intégration de logiciels", Proc. of ICSE'92, Toulouse, Décembre 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


Autr ans - 99

Page 47

Mode de structuration d'applications réparties.pdf

Recommend Documents