Master M2R “Systèmes et Logiciel”

Motivations

! La répartition est un état de fait pour un nombre

Construction d!Applications Réparties et important d!applications
" Développement des réseaux (Internet, réseaux sans fil)
Parallèles " Intégration d!applications existantes initialement séparées
" Pénétration de l!informatique dans des domaines nouveaux
Introduction d!application
# Intégration d!objets du monde réel (informatique omniprésente
(ubiquitous computing))
# Intégration entre informatique et télécommunications
Sacha Krakowiak
Université Joseph Fourier ! Le parallélisme est la réponse aux besoins croissants
Projet Sardes (INRIA et IMAG-LSR) des applications
http://sardes.inrialpes.fr/~krakowia " Puissance de traitement
" Gestion de grandes masses de données
" Intégration et mise en commun de ressources

© 2005-2006, S. Krakowiak 2

Objectifs du cours Contenu du cours

Notions de base des systèmes répartis

! Présentation des principes de la construction d!applications Problèmes de la construction d!applications réparties
réparties et parallèles
" Modèles de programmation Modèles d!organisation d!applications réparties
" Architectures logicielles des applications et de l!intergiciel (middleware) Patrons et canevas de base pour le modèle client-serveur

! Trois aspects Systèmes asynchrones, coordination, programmation par événements

" Les principaux problèmes abordés par la recherche
" Les patrons de conception (design patterns) et canevas logiciels (software
frameworks) utilisés dans la construction d!applications
" Des exemples illustratifs de l!état de l'art (recherche, industrie)
! Autres cours utiles
" Couvrent des aspects fondamentaux
" SR - Algorithmique et techniques de base des systèmes répartis (les années
paires, donc en 2006-2007)
" CP - Algorithmique et techniques de base du calcul parallèle (le présent
cours, ouvert les années impaires)
Exemples de systèmes asynchrones
Systèmes à composants. Intergiciels à composants. Patrons et canevas de
base pour les composants. Exemples de systèmes à composants
Sécurité des applications réparties : besoins, techniques, exemples.
Techniques d!adaptation. Applications : infrastructures mobiles, gestion de la
qualité de service, reconfiguration
Administration d!applications. Concepts et outils. Déploiement, configuration,
gestion de ressources, disponibilité. Exemples
Systèmes et applications parallèles sur grappes et grilles

© 2005-2006, S. Krakowiak 3 © 2005-2006, S. Krakowiak 4

 Plan de la séance 1 Caractéristiques des systèmes répartis (1)

! Introduction aux applications réparties ! Définition d!un système réparti

" Caractéristiques des systèmes réparties, notion d!intergiciel " Ensemble composé d!éléments reliés par un système de
communication ; les éléments ont des fonctions de traitement
" Les principaux schémas d!architecture des applications réparties (processeurs), de stockage (mémoire), de relation avec le monde
" Les problèmes à résoudre extérieur (capteurs, actionneurs)
" Les différents éléments du système ne fonctionnent pas
! Patrons et canevas de base pour les applications indépendament mais collaborent à une ou plusieurs tâches
réparties communes. Conséquence : une partie au moins de l!état global du
système est partagée entre plusieurs éléments (sinon, on aurait un
" Proxy, Factory, Wrapper, Adapter, Observer, …
fonctionnement indépendant)
" Architectures d!intergiciel

! Architectures d!intergiciel pour les objets répartis De manière plus précise : toute expression de la spécification du système
fait intervenir plusieurs éléments (exemple : préserver un invariant global,
mettre des interfaces en correspondance, etc.)

© 2005-2006, S. Krakowiak 5 © 2005-2006, S. Krakowiak 6

Caractéristiques des systèmes répartis (2) Caractéristiques des systèmes répartis (3)

! Difficultés
! Propriétés souhaitées " Propriété d!asynchronisme du système de communication (pas de borne
" Le système doit pouvoir fonctionner (au moins de façon dégradée) même supérieure stricte pour le temps de transmission d!un message
en cas de défaillance de certains de ses éléments # Conséquence : difficulté pour détecter les défaillances
" Le système doit pouvoir résister à des perturbations du système de " Dynamisme (la composition du système change en permanence)
communication (perte de messages, déconnexion temporaire,
performances dégradées) # Conséquences : difficulté pour définir un état global
" Le système doit pouvoir résister à des attaques contre sa sécurité (violation # Difficulté pour administrer le système
de la confidentialité, de l!intégrité, usage indu de ressources, déni de " Grande taille (nombre de composants, d!utilisateurs, dispersion
service) géographique)
" Le système doit pouvoir facilement s!adapter pour réagir à des # Conséquence : la capacité de croissance (scalability) est une
changements d!environnement ou de conditions d!utilisation propriété importante, mais difficile à réaliser
" Le système doit préserver ses performances lorsque sa taille croît (nombre
d'éléments, nombre d!utilisateurs, étendue géographique)
Malgré ces difficultés, des grands systèmes répartis existent et sont largement
utilisés
le DNS (Domain Name System)
le World Wide Web

© 2005-2006, S. Krakowiak 7 © 2005-2006, S. Krakowiak 8

 Applications réparties Services et interfaces

! Distinction entre “système” et “application” ! Définition

" Système : gestion des ressources communes et de l!infrastructure, lié de
manière étroite au matériel sous-jacent
# Système d!exploitation : gestion de chaque élément
# Système de communication : échange d!information entre les
éléments
# Caractéristiques communes : cachent la complexité du matériel et des
communications, fournissent des services communs de plus haut
niveau d!abstraction
" Application : réponse à un problème spécifique, fourniture de services à
ses utilisateurs (qui peuvent être d!autres applications). Utilise les services
généraux fournis par le système
" La distinction n!est pas toujours évidente, car certaines applications
peuvent directement travailler à bas niveau (au contact du matériel).
Exemple : systèmes embarqués, réseaux de capteurs
" Un système est un ensemble de composants (au sens non technique du
terme) qui interagissent
" Un service est “un comportement défini par contrat, qui peut être
implémenté et fourni par un composant pour être utilisé par un autre
composant, sur la base exclusive du contrat” (*)
! Mise en œuvre
" Un service est accessible via une ou plusieurs interfaces
" Une interface décrit l!interaction entre client et fournisseur du service
# Point de vue opérationnel : définition des opérations et structures de
données qui concourent à la réalisation du service
# Point de vue contractuel : définition du contrat entre client et
fournisseur
(*) Bieber and Carpenter, Introduction to Service-Oriented Programming, http://www.openwings.org

© 2005-2006, S. Krakowiak 9 © 2005-2006, S. Krakowiak 10

Définitions d!interfaces (1) Définitions d!interfaces (2)

contrat conformité
! Partie “opérationnelle”
" Interface Definition Language (IDL)
client fournisseur # Pas de standard, mais s!appuie sur un langage existant
$ IDL CORBA sur C++
$ Java et C# définissent leur propre IDL

int. requise int. fournie

! Partie “contractuelle”
" La fourniture d!un service met en jeu deux interfaces
" Plusieurs niveaux de contrats
# Interface requise (côté client)
# Sur la forme : spécification de types -> conformité syntaxique
# Interface fournie (côté fournisseur )
" Le contrat spécifie la compatibilité (conformité) entre ces interfaces # Sur le comportement (1 méthode) : assertions -> conformité
# Au delà de l!interface, chaque partie est une “boîte noire” pour l!autre
sémantique
(principe d!encapsulation) # Sur les interactions entre méthodes : synchronisation
# Conséquence : client ou fournisseur peuvent être remplacés du moment # Sur les aspects non fonctionnels (performances, etc.) : contrats de
que le composant remplaçant respecte le contrat (est conforme) QoS

© 2005-2006, S. Krakowiak 11 © 2005-2006, S. Krakowiak 12

 L!intergiciel (middleware) Place et interfaces de l!intergiciel

! Motivations ! L!intergiciel est la couche “du milieu” (Middleware)

" Dans un système réparti, même l!interface fournie par les systèmes
d!exploitation et de communication est encore trop complexe pour
être utilisée directement par les applications. Application Application
APIs haut niveau
# Hétérogénéité
# Complexité des mécanismes (bas niveau)
# Nécessité de gérer (et de masquer, au moins partiellement) la Intergiciel
répartition

! Solution Système Système

APIs bas niveau d!exploitation d!exploitation
" Introduire une couche de logiciel intermédiaire (répartie) entre les
niveaux bas (systèmes et communication) et le niveau haut
(applications) : c!est l!intergiciel Communication
" L!intergiciel joue un rôle analogue à celui d!un “super-système
d!exploitation” pour un système réparti
L!intergiciel est une notion récente (années 90), mais la chose existait avant le mot

© 2005-2006, S. Krakowiak 13 © 2005-2006, S. Krakowiak 14

Fonctions de l!intergiciel Classes d!intergiciel

! Objets répartis
! L!intergiciel a quatre fonctions principales " Java RMI, CORBA, DCOM, .NET
" Fournir une interface ou API (Applications Programming Interface) de haut
niveau aux applications ! Composants répartis
" Java Beans, Enterprise Java Beans, CCM
" Masquer l!hétérogénéité des systèmes matériels et logiciels sous-jacents
" Rendre la répartition aussi invisible (“transparente”) que possible ! Message-Oriented Middleware (MOM)
" Fournir des services répartis d!usage courant " Message Queues, Publish-Subscribe

! L!intergiciel vise à faciliter la programmation répartie ! Coordination

" Développement, évolution, réutilisation des applications ! Intégration d!applications
" Web Services
" Portabilité des applications entre plates-formes
" Interoperabilité d!applications hétérogènes ! Accès aux données, persistance
! Support d!applications mobiles

© 2005-2006, S. Krakowiak 15 © 2005-2006, S. Krakowiak 16

 Modèles d!architecture logicielle Principaux modèles examinés

Plusieurs critères de classification

Définition : une description d!un aspect (point de vue, fonction) de l!architecture
Usage : compréhension, explication, prévision, preuve, guide pour la réalisation ! Selon nature du flot de contrôle
" Synchrone (client-serveur)
Fondement Objets mathématiques " Asynchrone (messages, événements)
mathématique
" Mixte

Entités logicielles ! Selon unité d!organisation

Abstrait représentation non spécifiée
Une hiérarchie " Objets répartis
de modèles " Composants

Concret API génériques ! Structure statique ou dynamique

" Mobilité des éléments
" Reconfiguration,
Spécifique API dans un langage
La majorité des modèles sont concrets ou spécifiques (état de l!art)

© 2005-2006, S. Krakowiak 17 © 2005-2006, S. Krakowiak 18

Problèmes communs Principes de conception

La construction de systèmes et applications répartis nécessite de résoudre des ! Principe directeur : séparation des préoccupations
problèmes communs
" Isoler les aspects indépendants (ou faiblement corrélés) et les traiter séparément
" Examiner un problème à la fois
! Architecture logicielle
" Éliminer les interférences
" Unités d!organisation, relations
" Permettre aux aspects d!évoluer indépendamment
! Désignation et liaison
! Mise en œuvre
! Sécurité " Encapsulation : séparer interface et réalisation (contrat commun)
! Tolérance aux fautes " Abstraction : décomposition en niveaux, cacher les détails non pertinents à un
" Non traité dans ce cours ; traité dans le cours SR niveau donné
" Séparation entre politiques et mécanismes
! Qualité de service
# Ne pas réimplémenter les mécanismes quand on change de politique
" En particulier performances, passage à l!échelle
# Ne pas “sur-spécifier” les mécanismes
! Administration " Isolation et expression indépendante des aspects extra-fonctionnels (hors
interface)
Ces aspects forment le fil directeur de la suite du cours

© 2005-2006, S. Krakowiak 19 © 2005-2006, S. Krakowiak 20

 Patrons de conception (1) Patrons de conception (2)

! Définition d!un patron

! Définition [dépasse le cadre de la conception de logiciel]
" Ensemble de règles (définitions d!éléments , principes de composition, règles
d!usage) permettant de répondre à une classe de besoins spécifiques dans un
environnement donné.
! Propriétés
" Un patron est élaboré à partir de l!expérience acquise au cours de la résolution
d!une classe de problèmes apparentés"; il capture des éléments de solution
communs
" Un patron définit des principes de conception, non des implémentations
spécifiques de ces principes.
" Un patron fournit une aide à la documentation, par ex. en définissant une
terminologie, voire une description formelle (“langage de patrons ”)
E. Gamma, R. Helm, R. Johnson, J. Vlissides. Design Patterns - Elements of Reusable Object-Oriented Software, Addison-Wesley,
1995
F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal. Pattern-Oriented Software Architecture - vol. 1, Wiley 1996
D. Schmidt, M. Stal, H. Rohnert, F. Buschmann. Pattern-Oriented Software Architecture"- vol. 2, Wiley, 2000
" Contexte : Situation qui donne lieu à un problème de conception ; doit être aussi
générique que possible (mais éviter l!excès de généralité)
" Problème : spécifications, propriétés souhaitées pour la solution; contraintes de
l!environnement
" Solution :
# Aspects statiques : composants, relations entre composants; peut être décrit
par diagrammes de classe ou de collaboration
# Aspects dynamiques : comportement à l!exécution, cycle de vie (création,
terminaison, etc.); peut être décrite par des diagrammes de séquence ou d!état
! Catégories de patrons
" Conception : petite échelle, structures usuelles récurrentes dans un contexte
particulier
" Architecture : grande échelle, organisation structurelle, définit des sous-systèmes et
leurs relations mutuelles
" Idiomatiques: constructions propres à un langage
Source: F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal. Pattern-Oriented Software Architecture - vol. 1, Wiley 1996

© 2005-2006, S. Krakowiak 21 © 2005-2006, S. Krakowiak 22

Quelques patrons de base Proxy (Mandataire)

! Contexte
! Proxy " Applications constituées d!un ensemble d!objets répartis ; un client accède à des services
" Patron de conception : représentant pour accès à distance fournis par un objet pouvant être distant (le “servant”)

! Factory ! Problème
" Patron de conception : création d!objet " Définir un mécanisme d!accès qui évite au client
# Le codage “en dur” de l!emplacement du servant dans son code
! Wrapper [Adapter] # Une connaissance détaillée des protocoles de communication
" Patron de conception : transformation d!interface " Propriétés souhaitables
! Interceptor # Accès efficace et sûr
# Programmation simple pour le client ; idéalement, pas de différence entre accès local et
" Patron d!architecture : adaptation de service distant
! Observer " Contraintes
" Patron de base pour l!asynchronisme # Environnement réparti (pas d!espace unique d!adressage)

! Solutions
" Utiliser un représentant local du servant sur le site client (isole le client du servant et du
Ces patrons sont d!un usage courant dans la construction d!intergiciel système de communication)
" Garder la même interface pour le représentant et le servant
Nombreux exemples dans toute la suite " Définir une structure uniforme de représentant pour faciliter sa génération automatique

© 2005-2006, S. Krakowiak 23 © 2005-2006, S. Krakowiak 24

 Usage de Proxy Factory (Fabrique)

! Contexte
Client Proxy Servant " Application = ensemble d!objets en environnement réparti
! Problème
" Créer dynamiquement des instances multiples d!une classe d!objets
service request
" Propriétés souhaitables
pre-processing # Les instances doivent être paramétrables
# L!évolution doit être facile (pas de décisions “en dur”)
Interface I Interface I
" Contraintes
service request
# Environnement réparti (pas d!espace d!adressage unique)
! Solutions
result " Abstract Factory : définit une interface et une organisation génériques pour la
création d!objets ; la création effective est déléguée à des fabriques concrètes qui
implémentent les méthodes de création
post-processing usually:
" Abstract Factory peut être implémentée par Factory Methods (méthode de création
Remote call
redéfinie dans une sous-classe)
result
" Pour plus de de souplesse, on peut utiliser Factory Factory (le mécanisme de
création lui-même est paramétré)

© 2005-2006, S. Krakowiak 25 © 2005-2006, S. Krakowiak 26

Usage de Factory Un complément à Factory : Pool

Factory Factory
! Idée : réduire le coût de la gestion de ressources
" Technique : réutiliser des exemplaires existants Politique de
create gestion du
Client Factory pool
with
parameters
request for creation

optional
create
Object
Possible delegation from
return abstract to concrete créer :
object reference factory si pool non vide détruire :
"""""sortir une instance du pool placer l!instance
"""""nettoyer/initialiser dans le pool
request for removal
sinon
optional
"""""créer une nouvelle instance

© 2005-2006, S. Krakowiak 27 © 2005-2006, S. Krakowiak 28

 Utilisation de Pool Wrapper (ou Adapter)

! Contexte
! Gestion de la mémoire " Des clients demandent des services ; des servants fournissent des services ; les
" Pool de zones (plusieurs tailles possibles) services sont définis par des interfaces
" Évite le coût du ramasse-miettes ! Problème
" Évite les copies inutiles (chaînage de zones) " Réutiliser un servant existant en modifiant son interface et/ou certaines de ses
fonctions pour satisfaire les besoins d!un client (ou d!une classe de clients)
! Gestion des activités " Propriétés souhaitables : doit être efficace ; doit être adaptable car les besoins
" Pool de threads peuvent changer de façon imprévisible ; doit être réutilisable (générique)
" Évite le coût de la création " Contraintes :
! Solutions
! Gestion de la communication " Le Wrapper isole le servant en interceptant les appels de méthodes vers
" Pool de connexions l!interface de celui-ci. Chaque appel est précédé par un prologue et suivi par un
épilogue dans le Wrapper
! Gestion des composants " Les paramètres et résultats peuvent être convertis
" Voir plus loin (réalisation des conteneurs)

© 2005-2006, S. Krakowiak 29 © 2005-2006, S. Krakowiak 30

Usage du Wrapper Interceptor (Intercepteur)

! Contexte
Client Wrapper Servant " Fourniture de services (cadre général)
# Client-serveur, pair à pair, hiérarchique
# Uni- ou bi-directionnel, synchrone ou asynchrone
service request
! Problème
pre-processing " Transformer le service (ajouter de nouvelles fonctions), par différents moyens
Interface I2 Interface I1 # Interposer une nouvelle couche de traitement (cf. Wrapper)
# Changer (conditionnellement) la destination de l!appel
service request " Contraintes
# Les programmes cleient et serveur ne doivent pas être modifiés
# Les services peuvent être ajoutés ou supprimés dynamiquement
result
! Solutions
post-processing " Créer des objets d!interposition (statiquement ou dynamiquement). Ces objets
# interceptent les appels (et/ou les retours) et insèrent des traitements
result
spécifiques, éventuellement fondés sur une analyse du contenu
# peuvent rediriger l!appel vers une cible différente
# peuvent utiliser des appels en retour

© 2005-2006, S. Krakowiak 31 © 2005-2006, S. Krakowiak 32

 Usage d!Interceptor Comparaison des patrons de base

Supporting
Client Infrastructure
! Wrapper vs. Proxy
" Wrapper et Proxy ont une structure similaire
create # Proxy préserve l!interface ; Wrapper transforme l!interface
Servant
# Proxy utilise (pas toujours) l!accès à distance; Wrapper est en général
Interceptor
create local
! Wrapper vs. Interceptor
service request
" Wrapper et Interceptor ont une fonction similaire
Interface I # Wrapper transforme l!interface
Interface I # Interceptor transforme la fonction (peut même complètement
use service détourner l!appel de la cible initiale)
! Proxy vs. Interceptor
callback " Proxy est une forme simplifiée d!Interceptor
result # on peut rajouter un intercepteur à un proxy (smart proxy)

© 2005-2006, S. Krakowiak 33 © 2005-2006, S. Krakowiak 34

Mise en œuvre des patrons de base Canevas logiciels (Frameworks)

! Définition
! Génération automatique " Un canevas est un “squelette” de programme qui peut être réutilisé (et
" À partir d!une description déclarative adapté) pour une famille d!applications
" Il met en œuvre un modèle (pas toujours explicite)
IDL1
" Dans les langages à objets : un canevas comprend
IDL proxy wrapper
# Un ensemble de classes (souvent abstraites) devant être adaptées
IDL2 (par ex. par surcharge) à des environnements et contraintes
spécifiques
! Optimisation # Un ensemble de règles d!usage pour ces classes
" Éliminer les indirections, source d!inefficacité à l!exécution
! Patrons et canevas
# Court-circuit des chaînes d!indirection
" Ce sont deux techniques de réutilisation
# Injection de code (insertion du code engendré dans le code de
l!application) " Les patrons réutilisent un schéma de conception ; les canevas
# Génération de code de bas niveau (ex. bytecode Java) réutilisent du code
# Techniques réversibles (pour adaptation) " Un canevas implémente en général plusieurs patrons

© 2005-2006, S. Krakowiak 35 © 2005-2006, S. Krakowiak 36

 Schémas de décomposition Décomposition en couches

! Objectifs ! Hiérarchie de “machines abstraites”

" Faciliter la construction " La réalisation des niveaux < i est invisible au niveau i
# La structure reflète la démarche de conception " Exemple : machines virtuelles (OS multiples, JVM, etc.)
# Les interfaces et les dépendances sont mises en évidence
appel ascendant
" Faciliter l!évolution Protocoles de (upcall)
# Principe d!encapsulation communication
Interface i i+1 i+1i+1 i+1
# Échange standard

! Exemples i i i
i
" Structures multi-niveaux
# Décomposition “verticale” ou “horizontale”
" Canevas pour insertion de composants

© 2005-2006, S. Krakowiak 37 © 2005-2006, S. Krakowiak 38

Décomposition “horizontale” Exemple de canevas global (1)

! Exemple : évolution du schéma client-serveur ! Architecture de micro-noyau

gestion de Application
application données

(a) interface Noyau

application gestion de Serveur
utilisateur données Serveur

API de rappel
interface application gestion de API micronoyau
utilisateur données
Micronoyau

(b) (c) : 3-tier

Matériel

© 2005-2006, S. Krakowiak 39 © 2005-2006, S. Krakowiak 40

 Exemple de canevas global (2) Canevas de base et personnalités

! Architecture d!un canevas pour composants (middle ! Motivation : réutilisation de mécanismes génériques
" Un canevas de base réalise les entités définies par un modèle abstrait
tier) # Critères : générique, modulaire, composable, adaptable
composants d!application " Des “personnalités” utilisent les APIs du canevas de base (y compris appels en retour) pour
réaliser des mises en œuvres concrètes du modèle
interface de rappel interface de rappel " Avantages : réutilisation, unité conceptuelle, facilité de (re)configuration
" Difficulté : efficacité
! Exemples

application gestion
cliente de données
Java
Unix Autre OS CORBA EJB CCM
RMI

Noyau
framework API micronoyau ORB générique
à composants

© 2005-2006, S. Krakowiak 41 © 2005-2006, S. Krakowiak 42

Objets répartis Intergiciel pour objets répartis

! Schéma de base
! Exemples
" Application = ensemble d!objets répartis sur un réseau, communiquant
" Java Remote Method Invocation (RMI) : appel d!objets distants en Java -
entre eux (1 objet intégralement sur un site)
Sun
" Common Object Request Broker Architecture (CORBA) : support pour
communication l!exécution d!objets répartis hétérogènes - OMG
" DCOM, COM+ : Distributed Common Object Model - Microsoft

! Schéma commun : ORB (Object Request Broker)

" Modèle de base : client-serveur
Autres modèles (non considérés ici) " Identification et localisation des objets
Objets fragmentés
" Liaison entre objets clients et serveurs
Objets dupliqués
Objets mobiles " Exécution des appels de méthode à distance
… " Gestion du cycle de vie des objets (création, activation, …)
" Services divers (sécurité, transactions, etc.)

© 2005-2006, S. Krakowiak 43 © 2005-2006, S. Krakowiak 44

 Problèmes de l!exécution répartie Schémas d!interaction (1)

Couplage fort
! Schéma d!interaction !""Synchrones
RMI, CORBA,
" Communication COM, …
" Synchronisation
! Désignation et localisation des objets
" Identification et référence
!""Asynchrones Couplage faible

! Liaison Événements
" Établissement de la chaîne d!accès
! Cycle de vie
" Création, conservation, destruction des objets Queues de
! Mise en œuvre (réalisation, services) messages

!""Semi-synchrones

Notre objectif Combinaisons

"•"élaborer des patrons pour les aspects ci-dessus synchrone-
asynchrone
"•"proposer un canevas pour la structure d!un ORB

© 2005-2006, S. Krakowiak 45 © 2005-2006, S. Krakowiak 46

Schémas d!interaction (2) Schémas d!interaction (3)

Schémas asynchrones A
Système de
B
communication A B A B
Exécution parallèle de l!émetteur
et du récepteur
Couplage faible receive

block
Système de send m1
A communication B deliver m1 wait wait callback

send m2
wait
receive
événement
deliver m2
! Appel synchrone
réaction " L!émetteur (client) est bloqué en attendant le
retour
" Couplage fort
" Événement-réaction " Messages asynchrones
événements et messages peuvent être ou non mémorisés
Avec appel en retour (callback)

© 2005-2006, S. Krakowiak 47 © 2005-2006, S. Krakowiak 48

 Schémas d!interaction (4) Accès à un service

Annuaire des services

A B
<description, référence>

requête
3. recherche 2. enregistrement
! Inversion du contrôle
" Situation où B “contrôle” A callback
" La requête de service pour A est déclenchée
description
depuis l!extérieur 1. création
5. accès
référence
callback Représentation
4. liaison concrète du service
point d!accès
local

Demandeur de service Fournisseur de service

© 2005-2006, S. Krakowiak 49 © 2005-2006, S. Krakowiak 50

Bref rappel sur RPC (1/2) Bref rappel sur RPC (2/2)

P(x, y, …)
! L'appel de procédure à distance (RPC), un outil pour
construire des applications client-serveur application level P(x, y, …)

processus p processus p
receive parameters
P(x, y, …) pack parameters unpack parameters
send parameters
client call procedure server
wait middleware level
procedure stub receive results
stub
P(x, y, …) pack results
P(x, y, …) unpack results send results

send receive
network
receive send

communication software communication software

(sockets) (sockets)
L!effet de l!appel doit être identique dans les deux situations. Cela est impossible à
réaliser en présence de défaillances ! Mise en œuvre de l!appel de procédure à distance

© 2005-2006, S. Krakowiak 51 © 2005-2006, S. Krakowiak 52

 Du RPC aux objets répartis… Les étapes d!un appel d!objet réparti
(vues du programmeur)

Serveur
! Pourquoi les objets répartis Client Serveur
de noms
" Avantages d!un modèle à objets pour la programmation
" L!encapsulation se prête bien à la répartition (objet = unité naturelle
de répartition) Servant create(servant)
" Réutilisation de l!existant (par wrappers) register(servant, name)
! Différences avec RPC target = lookup(name)
" Création dynamique d!objets
# Donc liaison dynamique target.method(params)
" Intégration de services
# Persistance, duplication, transactions, etc.
Connaissances requises :
le client et le serveur connaissent le serveur de noms
le client et le serveur s!accordent sur le nom name
le client connaît l!interface du servant

© 2005-2006, S. Krakowiak 53 © 2005-2006, S. Krakowiak 54

Les étapes d!un appel réparti Désignation et liaison

(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 ! Désignation
entre le client et le servant " Associer des noms à des objets
" Retrouver un objet à partir de son nom

! Liaison
client servant
" Créer une chaîne d!accès à un objet (à partir d!un nom)

! Spécificité de la liaison répartie

talon squelette " En centralisé (très schématiquement)
# 2 sortes de noms : nom symboliques, adresses
session de communication
# Liaison = recherche de l!adresse (souvent avec indirection)
" En réparti
L!opération de liaison (binding) est la création de cette chaîne d!accès # “Adresse” = référence (exemple : [adresse IP, n° de porte])
(également appelée “objet de liaison”) # Mais référence # chaîne d!accès !

© 2005-2006, S. Krakowiak 55 © 2005-2006, S. Krakowiak 56

 Étapes de la liaison répartie Rappel rapide sur les noms

Nom symbolique Exemple : rmi://myexamples/bank/account

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

Référence alpha foo

Exemple : [194.199.25.18, 38245]
Un espace plat est inutilisable foo bar
recherche inefficace beta u
Un objet
pas de localité
Liaison Un contexte
Contexte = partie de l!univers
zzz
Point d!accès Graphe de contextes
tau
(adresse locale) Exemple : _AccountStub.class (souvent hiérarchique : arbre, etc.)
here

© 2005-2006, S. Krakowiak 57 © 2005-2006, S. Krakowiak 58

Résolution et liaison des noms Liaison en réparti : exemple

! Résoudre un nom (dans un contexte)

" À partir du nom, trouver l!objet ! sockets
" Processus récursif
target = context.resolve(name) [ou name.resolve()] adresse IP
server
Référence numéro de porte
socket
3 issues possibles pour target accept
# Une valeur typée : c!est l!objet
# Une référence (ex : adresse) => l!objet est localisé
# Un autre nom (dans un autre contexte) => on rappelle resolve connect

! Lier un nom
nom de socket server
" À partir du nom, construire une chaîne d!accès à l!objet Liaison socket
" Rappel : en réparti, résolution # liaison ! socket
# Exemple : une référence (adresse IP, n° de porte) ne suffit pas pour
accéder à l!objet

© 2005-2006, S. Krakowiak 59 © 2005-2006, S. Krakowiak 60

 Un patron pour la liaison répartie Liaison dans un ORB (1)

Serveur
! La liaison est établie en 2 phases Client
de noms
Serveur

! Côté serveur (export )

" “publication” de l!objet à lier (identification) bind …1 … 2 Servant create(servant, stub-image,
" préparation de certains éléments de la liaison skeleton)

! Côté client (bind ) register(stub-image, name)

target = lookup(name)
" établissement de la liaison par création et assemblage des
constituants de l!objet de liaison stub-image stub-image stub-image

! Exemple stub-image.bind()
" La connexion par sockets peut être décrite en ces termes target.method(params) export …1 … 2
# accept = export
# connect = bind stub skeleton

session

© 2005-2006, S. Krakowiak 61 © 2005-2006, S. Krakowiak 62

Structure d!un appel distant (1) Structure d!un ORB

! L!interface “de bout en bout” est spécifique

" Interface d!un objet défini par l!application client servant
" Exprimée dans un IDL, pour faciliter la portabilité client-servant
interface
! Les interfaces intermédiaires (internes à l!ORB) ont intérêt à être stub
delegate skeleton
génériques interface
" Pour faciliter les échanges de composants d!ORB delegate
" Pour faciliter l!interopérabilité entre ORBs ref adapter
inter-ORB
interface
inter-ORB protocol
myAccount.deposit(400) communication
interface
spécifique communication protocol
generic
transformation d!interface
générique
ref.invoke("deposit", marshaller.write_double(400)) Transformation d!interface
côté client, dans le talon (vers le “délégué”, ou talon générique)
ref = référence à l!objet servant myAccount côté serveur, dans un adaptateur

© 2005-2006, S. Krakowiak 63 © 2005-2006, S. Krakowiak 64

 Fonctions de l!adaptateur Une interface générique pour les ORB

! Gestion des objets servants ! GIOP : General Inter-ORB Protocol

" Référentiel des implémentations dans CORBA " Définit une interface et un protocole générique pour l!appel d!objets distants
! Gestion des références d!objets sur une couche de transport
" Créer une référence pour un objet (à la création de l!objet) # Représentation commune de données (Common Data Representation,
CDR)
" Trouver un objet, connaissant sa référence
# Format standard de référence d!objet (Interoperable Object Reference,
! Gestion des activités côté serveur IOR)
" Activer un objet (lui associer un thread pour son exécution) # Format des messages
# Contraintes sur la couche de transport
! Exemple : le POA (Portable Object Adapter) de CORBA (OMG)
" Permet d!isoler les politiques de gestion d!objets ! IIOP : Internet Inter-ORB Protocol
# Persistance, politique d!activation, format de références, etc. " La réalisation “standard” de GIOP
# GIOP sur TCP/IP

© 2005-2006, S. Krakowiak 65 © 2005-2006, S. Krakowiak 66

Format d!une référence Structure d!un appel distant (2)

protocol site myObj.myMeth(x,y) myMeth(x,y) Object

(a) reference
port
site port
target object
address number Stub Skeleton
invoke("myMeth", params)
spécifique
invoke("myMeth", params)
générique
site Clt Delegate Srv Delegate
(b) reference object manager
stub skeleton
port
(adapter)
object manager
internal id stream ={ref, marshaller, reply} adapter
target object
send(stream) Adapter
send(unmarshaller, reply)

site GIOP IIOP IIOP GIOP

(c) reference send(mess)
object manager send(mess, reply)
(adapter)
TCP/IP TCP/IP
locator manager target object
write(mess) send(mess)
internal id
locator socket socket
read(mess)
© 2005-2006, S. Krakowiak 67 © 2005-2006, S. Krakowiak 68
 Liaison dans un ORB (2) Liaison dans un ORB (3)

Construction de la chaîne de liaison : ensemble de “fabriques de liaison” utilisant export-

Phase 1 : génération des talons IDL Générateur
bind
Les objets à construire :
Phase 2 : export
Générateur de talons
+ StubFactory hello = new helloImpl() HelloImpl Stub-class Skel-class

Stub Skeleton
… trouver serveur
ORB Binder hello Skeleton
de noms ns
CltDelegate SrvDelegate export export
GIOP ProtocolGraph ns.rebind("myhello", hello)
ORB Binder GIOPProtocolGraph GIOPSrv
Adapter
GIOP Clt GIOP Srv
TcpIp Protocol
Name Server Stub Factory SrvDelegate TCPIPSrv

"myhello" export
TCP-IP Clt Connection Factory TCP-IP Srv
Adapter

CltDelegate
Connexion Connexion {key, host, port} key host, port

© 2005-2006, S. Krakowiak 69 © 2005-2006, S. Krakowiak 70

Liaison dans un ORB (4) Liaison dans un ORB (5)

Phase 3 : bind hello.sayHello() sayHello() Object

trouver serveur
Stub Skeleton
de noms ns
invoke("sayHello", null)
spécifique
bind invoke("sayHello", null)
obj = ns.resolve("myhello")
GIOPProtocolGraph générique
obj.sayHello() Clt Delegate Srv Delegate
stub skeleton
GIOPClt GIOPSrv stream ={ref, marshaller, reply} adapter
bind send(stream) Adapter
send(unmarshaller, reply)
Name Server {key, host, port} TCP-IPCt TCP-IPSrv
"myhello" GIOP IIOP IIOP GIOP
send(mess)
send(mess, reply)
CltDelegate TCP/IP TCP/IP
{key, host, port} write(mess) send(mess)
socket socket
read(mess)
© 2005-2006, S. Krakowiak 71 © 2005-2006, S. Krakowiak 72
 Un canevas commun pour la Un canevas commun pour la construction d!ORB (2)
construction d!ORB (1)

ORB Marshaller Factory

" Source : Jonathan (www.objectweb.org/jonathan)
" Objectif : fournir une base commune pour construire des ORB, à
partir d!un canevas modulaire et paramétrable
" Motivation : mécanismes uniformes et ouverts, souplesse, facilité Stub Factory
d!évolution par remplacement de parties des canevas
Protocol
" Utilise systématiquement les patrons de base : binder
Connection Manager
# Factory
# Pool de ressources (activités, mémoire, communication)
Protocol
# export-bind (fabriques de liaison) (dynamic
connection)
Protocol

# Configuration (non vu ici)

" Exemples de mise en œuvre
Adapter
# Java RMI, CORBA, persistance (JORM), composants répartis
(Julia)

© 2005-2006, S. Krakowiak 73 © 2005-2006, S. Krakowiak 74

Coordination Observer, patron de base pour la coordination

! Contexte
! Définitions " Des objets “observés”, dont l!état (visible) évolue au cours du temps
" Méthodes et outils permettant à un ensemble d!entités de coopérer à une " Des objets “observateurs”
tâche commune
! Problème
" Modèle de coordination, définit :
" Permettre aux observateurs d!être informés de l!évolution des objets observés
# les entités coopérantes (processus, activités, “agents”, …) " Propriétés souhaitables
# le support (médium) de coordination : véhicule de l!interaction # Requérir un effort minimal de la part des observateurs
# les règles de coordination : primitives, patrons d!interaction # Garantir l!indépendance mutuelle des observateurs
# Permettre l!évolution dynamique (arrivée-départ des observateurs et observés)
! Domaine d!application
" Contraintes
" Couplage faible (évolution indépendante des entités)
# Passage à l!échelle
" Structure très dynamique (les entités peuvent rejoindre/quitter le système à
tout instant) ! Solution
" Les observateurs enregistrent leur intérêt auprès des observés
" Hétérogénéité (système, environnement, administration)
" Les observés notifient aux observateurs enregistrés les événements pertinents, de manière
" Condition requise : capacité de croissance asynchrone

© 2005-2006, S. Krakowiak 75 © 2005-2006, S. Krakowiak 76

 Observer Autres patrons pour la coordination

Observed Observer_1 Observer_2 ! Les limitations de Observer…

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

© 2005-2006, S. Krakowiak 77 © 2005-2006, S. Krakowiak 78

Publish/Subscribe Publish/Subscribe

! Contexte Publisher_1 Mediator Subscriber_1 Subscriber_3

" Ensemble d!entités devant se coordonner par émission d!événements et réaction à
ces événements (autre formulation de Observer)
! Problème subscribe (X)

" Propriétés souhaitables subscribe (X)

# Comme Observer (indépendance, évolution dynamique)

# Pas de rôle prédéfini
Publisher_2
# Sélectivité sur la nature des événements Subscriber_2
" Contraintes
# Passage à l!échelle
publish subscribe (Y)
# Propriétés diverses : tolérance aux fautes, transactions, persistance, ordre (X)
notify
! Solution notify
" Deux “rôles” : abonné (subscriber) et émetteur (publisher)
publish
" Une entité d!intermédiation (médiateur) (Y)
" Abonnement par sujet (statique) ou par contenu (dynamique) notify

© 2005-2006, S. Krakowiak 79 © 2005-2006, S. Krakowiak 80

 Coordination : réalisations La bibliographie

! Deux types de références

! Message-Oriented Middleware (MoM)
" Regroupe Publish-Subscribe et Message Queues " Références de base (souvent livres, parfois revues), relativement
" Abonnement par sujet : nombreuses réalisations industrielles stables
# Tibco, Websphere, … ScalAgent (JORAM) -> cf. atelier " Articles de recherche : avancées récentes, durée de vie en général plus
# Un standard pour l!interface : JMS (Java Messaging System) limitée
" Abonnement par contenu : prototypes de recherche " La bibliographie contient les deux types de références
# Gryphon (IBM Research)
" Le cours utilise en majorité (pas seulement) les références de base…
# Siena (Univ. Colorado)
" … donc lire aussi les articles de recherche, selon votre intérêt
! Espace partagé
spécifique
" Modèle : Linda (espace de tuples), projection dans divers langages
" Réalisation : Jini (Sun) ! Divers degrés de pertinence
# Utilisation : découverte de ressources
" On ne peut pas tout lire…
" … donc classement sélectif

© 2005-2006, S. Krakowiak 81 © 2005-2006, S. Krakowiak 82