Intergiciels-cours-3
11
pages
Catalan
Documents
Le téléchargement nécessite un accès à la bibliothèque YouScribe Tout savoir sur nos offres
11
pages
Catalan
Documents
Le téléchargement nécessite un accès à la bibliothèque YouScribe Tout savoir sur nos offres
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, ...
Voir
Publié par
Langue
Catalan
© 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
