Intergiciels-cours-3

Merle

Description

nuIntergicielsDr. Philippe MerleADAM / INRIA Futurs – GOAL / LIFL - USTLhttp://www.lifl.fr/~merlePatrons et canevas pourl’exécution répartie• Objets répartis : Broker• Désignation et liaison : Export-Bind ; • Coordination : Observer, Publish-Subscribe© 2003-2007, S. Krakowiak ICAR’06 2Objets répartisSchéma de baseApplication = ensemble d’objets répartis sur un réseau, communiquant entre eux (1 objet intégralement sur un site)communicationAutres modèles (non considérés ici)Objets fragmentésObjets dupliquésObjets mobiles…© 2003-2007, S. Krakowiak ICAR’06 31unnnuuunuuunuuunuununnnuIntergiciel pour objets répartisExemplesJava Remote Method Invocation (RMI) : appel d’objets distants en Java - SunCommon Object Request Broker Architecture (CORBA) : support pour l’exécution d’objets répartis hétérogènes - OMGDCOM, COM+ : Distributed Common Object Model - MicrosoftSchéma commun : ORB (Object Request Broker)Modèle de base : client-serveurIdentification et localisation des objetsLiaison entre objets clients et serveursExécution des appels de méthode à distanceGestion du cycle de vie des objets (création, activation, …)Services divers (sécurité, transactions, etc.)© 2003-2007, S. Krakowiak ICAR’06 4Problèmes de l’exécution répartieSchéma d’interactionCommunicationSynchronisationDésignation et localisation des objetsIdentification et référenceLiaison Établissement de la chaîne d’accèsCycle de vieCréation, ...

Sujets

• réseau
• réseaux

Informations

• Publié par: Indou
• Nombre de lectures: 76
• Langue: Catalan

Extrait

© 2003-2007, S. Krakowiak

Intergiciels

IC A R ’06

Autres modèles (non considérés ici) Objets fragmentés Objets dupliqués Objets mobiles …

© 2003-2007, S. Krakowiak

Objets répartis

•Objets répartis :Broker •Désignation et liaison :Export-Bind; •Coordination :Observer,Publish-Subscribe

n

Dr. Philippe Merle ADAM / INRIA Futurs – GOAL / LIFL - USTL http://www.lifl.fr/~merle

Patrons et canevas pour l’exécution répartie

2

3

1

com m unication

Schéma de base Application = ensemble d’objets répartis sur un réseau, u communiquant entre eux (1 objet intégralement sur un site)

IC A R ’06

n

n

n

5

Schémas d’interaction

© 2003-2007, S. Krakowiak

n

n

6

R M I, C O R B A , C O M , …

IC A R ’06

Exemples Java Remote Method Invocation(RMI) : appel d’objets distants en u Java - Sun Common Object Request Broker Architecture(CORBA) : support u pour l’exécution d’objets répartis hétérogènes - OMG DCOM, COM+ :Distributed Common Object Model- Microsoft u Schéma commun : ORB (Object Request Broker) Modèle de base : client-serveur u Identification et localisation des objets u Liaison entre objets clients et serveurs u Exécution des appels de méthode à distance u Gestion du cycle de vie des objets (création, activation, …) u Services divers (sécurité, transactions, etc.) u

2

Intergiciel pour objets répartis

Problèmes de l’exécution répartie

4

n

n

© 2003-2007, S. Krakowiak

n

n

Semi-synchrones

n

© 2003-2007, S. Krakowiak

Synchrones

IC A R ’06

IC A R ’06

C om binaisons synchrone- asynchrone

Asynchrones

Schéma d’interaction Communication u Synchronisation u Désignation et localisation des objets Identification et référence u Liaison Établissement de la chaîne d’accès u Cycle de vie Création, conservation, destruction des objets u Mise en œuvre (réalisation, services) Notre objectif • élaborer des patrons pour les aspects ci-dessus • proposer un canevas pour la structure d’un ORB

Files de m essages

É vénem ents

C ouplage faible

C ouplage fort

receiv send

niveau application

pack re send

logiciel de communication (sockets)

logiciel de communication (sockets)

w ait

send receive

P (x, y, … )

niveau intergiciel

réseau

results results

L’effet de l’appel doit être identique dans les deux situations. Cela est impossible à réaliser en présence de défaillances

P(x, y, …)

IC A R ’06

P (x, y, … )

3

7

P(x, y, …)

Pourquoi les objets répartis Avantages d’un modèle à objets pour la programmation u L’encapsulation se prête bien à la répartition (objet = unité u naturelle de répartition) Réutilisation de l’existant (parwrappers) u Différences avec RPC Encapsulation de données u Création dynamique d’objets u Donc liaison dynamique v Intégration de services u Persistance, duplication, transactions, etc. v

9

© 2003-2007, S. Krakowiak

IC A R ’06

Du RPC aux objets répartis…

8

© 2003-2007, S. Krakowiak

n

IC A R ’06

n

procedure P(x, y, …)

souche serveur (stub)

arameters arameters

Réalisation de l’appel de procédure à distance

Bref rappel sur RPC (2/2)

processus p

L'appel de procédure à distance (RPC), un outil pour construire des applications client-serveur

n

processus p

Bref rappel sur RPC (1/2)

© 2003-2007, S. Krakowiak

souche client (stub)

n

Client

Les étapes d’un appel d’objet réparti (vues du programmeur)

target lookup(name)

target.method(params)

Serveur de noms

Servant

Serveur

create(servant)

register(servant, name)

Connaissances requises : le client et le serveur connaissent le serveur de noms le client et le serveur s’accordent sur le nomname le client connaît l’interface du servant

© 2003-2007, S. Krakowiak

IC A R ’06

Les étapes d’un appel réparti (vues du système)

En partant de la fin… Pour réaliser l’appel réparti, il faut avoir établi une chaîne d’accès entre le client et le servant

client

souche

session de communication

servant

squelette

L’opération deliaison(binding) est la création de cette chaîne d’accès (également appelée “objet de liaison”)

© 2003-2007, S. Krakowiak

n

n

n

IC A R ’06

Désignation et liaison

Désignation Associer des noms à des objets u Retrouver un objet à partir de son nom u Liaison Créer une chaîne d’accès à un objet (à partir d’un nom) u Spécificité de la liaison répartie En centralisé (très schématiquement) u 2 sortes de noms : nom symboliques, adresses v Liaison = recherche de l’adresse (souvent avec indirection) v En réparti u “Adresse” = référence (exemple : [adresse IP, n°de p ort]) v Maisréférence≠chaîne d’accès ! v

© 2003-2007, S. Krakowiak

IC A R ’06

10

11

12

4

Nom symbolique

Référence

Point d’accès (adresse locale)

© 2003-2007, S. Krakowiak

n

n

Étapes de la liaison répartie

Résolution

Liaison

IC A R ’06

E xem ple : rm i://m yexam ples/bank/account

E xem ple : [194.199.25.18, 38245]

E xem ple : _AccountS tub.class

Rappel rapide sur les noms

Deux sortes de noms Identificateurs : distinguer un objet des autres u Références : localiser un objet (en vue d’y accéder) u Noms contextuels Un nom

Un espace plat est inutilisable recherche inefficace pas de localité

Contexte = partie de l’univers Graphe de contextes (souvent hiérarchique : arbre, etc.)

© 2003-2007, S. Krakowiak

n

n

alpha foo beta Un contexte

IC A R ’06

Un objet

zzz

here

Résolution et liaison des noms

a foo bar u

Résoudre un nom (dans un contexte) À partir du nom, trouver l’objet u Processus récursif u target=context.resolve(namename.resolve()]) [ou 3 issues possibles pourtarget Une valeur typée : c’est l’objet v Une référence (ex : adresse) => l’objet est localisé v Un autre nom (dans un autre contexte) => on rappelleresolve v Lier un nom À partir du nom, construire une chaîne d’accès à l’objet u Rappel : en réparti, résolution≠liaison ! u Exemple : une référence (adresse IP, n° de porte) ne s uffit pas pour v accéder à l’objet

© 2003-2007, S. Krakowiak

IC A R ’06

13

14

15

5

n

IC A R ’06

IC A R ’06

server socket socket

Client

st

ge.bind() target.m etho

target = lookup(nam e)

stub-im age

nom desocket

server socket

sockets

La liaison est établie en 2 phases Côté serveur (export) “publication” de l’objet à lier (identification) u préparation de certains éléments de la liaison u Côté client (bind) établissement de la liaison par création et assemblage des u constituants de l’objet de liaison Exemple La connexion par sockets peut être décrite en ces termes u accept=export v connect=bind v

n

Serveur de noms

Serveur

stub-im age

accept

adresse IP num éro de port

create(s skeleton

18

17

16

© 2003-2007, S. Krakowiak

Liaison en réparti : exemple

Liaison

connect

Référence

n

Un patron pour la liaison répartie

Servant

bind…1… 2

Liaison dans un ORB (1)

IC A R ’06

© 2003-2007, S. Krakowiak

6

register(stub-im age, nam e)

export…1… 2

n n

© 2003-2007, S. Krakowiak

n

n

Structure d’un appel distant (1)

L’interface “de bout en bout” est spécifique Interface d’un objet défini par l’application u Exprimée dans un IDL, pour faciliter la portabilité u Les interfaces intermédiaires (internes à l’ORB) ont intérêt à être génériques Pour faciliter les échanges de composants d’ORB u Pour faciliter l’interopérabilité entre ORBs u

spécifique

générique

© 2003-2007, S. Krakowiak

client-servant interface delegate interface

inter-O R B interface

com m unication interface generic

myAccount.deposit(400)

transformation d’interface

(réification)

ref.invoke("deposit", marshaller.write_double(400))

ref= référence à l’objet servantmyAccount

IC A R ’06

Structure d’un ORB

client

stub

delega ref

inter-O R B protocol

com m unication protocol

servant

skeleton

adapter

19

Transformation d’interface côté client, dans la souche (vers le “délégué”, ou souche générique) côté serveur, dans un adaptateur

© 2003-2007, S. Krakowiak

n

n

n

n

IC A R ’06

Fonctions de l’adaptateur

20

Gestion des objets servants Référentiel des implémentations dans CORBA u Gestion des références d’objets Créer une référence pour un objet (à la création de l’objet) u Trouver un objet, connaissant sa référence u Gestion des activités côté serveur Activer un objet (lui associer unthreadpour son exécution) u Exemple : le POA (Portable Object Adapter) de CORBA (OMG) Permet d’isoler les politiques de gestion d’objets u Persistance, politique d’activation, format de références, etc. v

© 2003-2007, S. Krakowiak

IC A R ’06

21

7

internal id

24

n

send(m ess, reply)

send(m ess)

GIOP

socket

TCP/IP

TCP/IP

IC A R ’06

site

Object

invoke("m yM eth", param s)

m yM eth(x,y)

adapter

stub

skeleton

send(unmarshaller, reply)

générique

(c)

reference

23

Skeleton

IIOP

IIOP

i object manager

GIOP :General Inter-ORB Protocol Définit une interface et un protocole générique pour l’appel u d’objets distants sur une couche de transport Représentation commune de données (Common Data v Representation, CDR) Format standard de référence d’objet (Interoperable Object v Reference, IOR) Format des messages v Contraintes sur la couche de transport v IIOP :Internet Inter-ORB Protocol La réalisation “standard” de GIOP u GIOP sur TCP/IP v

spécifique

site

target object

site

read(m ess)

Adapter

object manager (adapter)

22

IC A R ’06

Srv Delegate

Structure d’un appel distant (2)

invoke("m yM eth", param s)

8

locator manage

site port address number

Format d’une référence

port

(b)

object manager (adapter)

target object

target object

Une interface générique pour les ORB

reference

n

© 2003-2007, S. Krakowiak

GIOP

stream ={ref, m arshaller, reply} send(stream )

Clt Delegate

© 2003-2007, S. Krakowiak

© 2003-2007, S. Krakowiak

Stub

(a)

protocol reference

m yO bj.m yM eth(x,y)

IC A R ’06

socket

w rite(m ess)

send(m ess)

Intérêt : généricité E xem ples :interceptors

IC A R ’06

© 2003-2007, S. Krakowiak

insertion (dynam ique) de code d’interposition

adaptation du code des représentants

Observer, patron de base pour la coordination

n

n

n

Coordination

Adaptation de la liaison

Définitions Méthodes et outils permettant à un ensemble d’entités de coopérer u à une tâche commune Modèle de coordination, définit : u les entités coopérantes (processus, activités, “agents”, …) v le support (médium) de coordination : véhicule de l’interaction v les règles de coordination : primitives, patrons d’interaction v Domaine d’application Couplage faible (évolution indépendante des entités) u Structure très dynamique (les entités peuvent rejoindre/quitter le u système à tout instant) Hétérogénéité (système, environnement, administration) u Condition requise : capacité de croissance u

25

27

26

9

Intérêt : évolution E xem ples : JavaPod

Contexte Des objets “observés”, dont l’état (visible) évolue au cours du temps u Des objets “observateurs” u Problème Permettre aux observateurs d’être informés de l’évolution des objets u observés Propriétés souhaitables u R equérir un effort m inim al de la part des observate urs v G arantir l’indépendance m utuelle des observateurs v P erm ettre l’évolution dynam ique (arrivée-départ des observateurs et observés) v Contraintes u P assage à l’échelle v Solution Les observateurs enregistrent leur intérêt auprès des observés u Les observés notifient aux observateurs enregistrés les événements u pertinents, de manière asynchrone

serveur

adaptation du serveur

client

objet de liaison

© 2003-2007, S. Krakowiak

n

IC A R ’06

© 2003-2007, S. Krakowiak

adaptation du code d’interposition

Intérêt : souplesse E xem ples : Flexinet

Intérêt : efficacité, personnalisation E xem ples :smart proxies

n

IC A R ’06

n

Observer_1

register

query

notify

query

n

notify

n

n

10

register

Observer_2

Observed

© 2003-2007, S. Krakowiak

29

Contexte Ensemble d’entités devant se coordonner par émission u d’événemens et réaction à ces événements (autre formulation de Observer) Problème Propriétés souhaitables u CommeObserver(indépendance, évolution dynamique) v Pas de rôle prédéfini v Sélectivité sur la nature des événements v Contraintes u Passage à l’échelle v Propriétés diverses : tolérance aux fautes, transactions, persistance, v ordre Solution Deux “rôles” : abonné (subscriber) et émetteur (publisher) u Une entité d’intermédiation (médiateur) u Abonnement par sujet (statique) ou par contenu (dynamique) u

28

30

IC A R ’06

Observer

© 2003-2007, S. Krakowiak

Autres patrons pour la coordination

a change

Les limitations deObserver… Forte charge sur les objets observés (gèrent les observateurs et u répondent aux consultations) Manque de sélectivité du schéma notification-consultation u (l’observateur reçoit toutes les notifications de changement) … et deux réponses Publish-Subscribe u Deux “rôles” : abonné (subscriber) et émetteur (publisher) v Une entité d’intermédiation (médiateur) v Abonnement par sujet ou par contenu v Espace partagé u Le médium de coordination est un ensemble de tuples v Opérations : déposer, consulter avec filtrage (destructivement ou v non)

IC A R ’06

Publish/Subscribe

© 2003-2007, S. Krakowiak

n

IC A R ’06

Publisher_1

Publisher_2

publish (X)

© 2003-2007, S. Krakowiak

n

n

Publish/Subscribe

Mediator

publish (Y)

Subscriber_1

subscribe (X)

subscribe (Y)

notify

notify

IC A R ’06

subscribe (X)

Subscriber_2

notify

Coordination : réalisations

Subscriber_3

Message-Oriented Middleware(MoM) RegroupePublish-SubscribeetMessage Queues u Abonnement par sujet : nombreuses réalisations industrielles u Tibco, Websphere, … ScalAgent (JORAM) -> cf. atelier v Un standard pour l’interface : JMS (Java Messaging System) v Abonnement par contenu : prototypes de recherche u Gryphon (IBM Research) v Siena (Univ. Colorado) v Espace partagé Modèle : Linda (espace de tuples), projection dans divers langages u Réalisation : Jini (Sun) u Utilisation : découverte de ressources v

© 2003-2007, S. Krakowiak

IC A R ’06

31

32

11