Objectifs du cours - WikiDocs, Université de Lorraine

14/09/2009
Programmation d’applications
réparties
Objectifs du cours

Comprendre les fondements de la programmation
d’applications réparties



Modèles de programmation
Architecture et Middleware
Savoir mettre en œuvre les principales solutions
existantes


Conception
Plateformes
1
14/09/2009
Plan du cours

Introduction et principes de base


Pl f
Plateformes



Modèle, principes, mise en œuvre
J2EE EJB
J2EE,


Défis majeurs
Middleware (définition, caractérisation, histoire)
Invocation de méthodes à distance (RMI Java)


Architecture, conception
Objet distribué, Persistence, aspects non fonctionnels
Service et orchestration

Web Service, BPEL
Bibliographie


Cours de Martin Quinson (ESIAL 2008)
Cours sur Internet





SSystèmes
è
et Applications
A l
Répartis
Ré
(S.
(S Krakowiak)
K k
k)
http://sardes.inrialpes.fr/~krakowia/Enseignement/M2P-GI/
Ecole d’été sur les intergiciels
http://sardes.inrialpes.fr/ecole/2003/support.html
Autres références

http://www loria fr/~charoy/index
http://www.loria.fr/
charoy/index.php?n
php?n=Main
Main.PAR2009
PAR2009
2
14/09/2009
Introduction et principes de base


Introduction
Architectures applicatives



Patrons de conception


RPC
Multi-niveaux
Proxy, Factory, Wrapper, Interceptor,…
Conclusion
Applications réparties

Passage d’un informatique centralisée à une informatique
décentralisée



Communication entre des applications développées
séparément
Mise en commun de ressources (grille, bases de données)
Nouveaux domaines d’application


Web, mobilité, ubiquité
Baisse des couts et des performances


Machine
Communication
3
14/09/2009
Système réparti

Définition (from S. Krakowiak)


Ensemble composé d’éléments reliés par un système de
communication; les éléments ont des fonctions de traitement
(processeurs), de stockage (mémoire) et de relation avec le
monde extérieur (capteurs, actionneurs)
Les éléments du système ne fonctionnent pas indépendamment
mais collaborent à une ou plusieurs tâches communes. Une
partie au moins de l’état du système est partagée entre
pplusieurs éléments.
Propriétés des applications





Sureté
Sécurité
Disponibilité
Maintenabilité, extensibilité
Passage à l’échelle
4
14/09/2009
Définitions de propriétés

Sureté (Reliability)


Di
Disponibilité
ibili é (A
(Availability)
il bili )


Pourcentage du temps pendant lequel un système est
disponible (de 99 à 99,999)
Serviceability


Probabilité qu’un système fonctionne à t+1 s’il fonctionnait à t.
Facilité de maintenance corrective et préventive (améliore la
disponibilité)
Passage à l’échelle

Cout pour passer de 1 à 10, 100, 1000, 10000… clients
Problèmes

Détection des défaillances des éléments


P blè
Problèmes
liés
lié à lla communication
i i


Coupure, déconnection, pertes de messages
Ouverture et donc problèmes de sécurité


Multiplication des causes de pannes
Confidentialité, intégrité, déni de service
Il faut prendre des décisions sont connaitre réellement la
situation

Timeout, redéploiement, changement de service, annulation
5
14/09/2009
Les applications









Commerce et trading
Applications bancaires
Call Centers
Assurances
…
Nombreuses sources d’information potentielles
Interactions entre systèmes hétérogènes
Grands nombre de transactions (throughtput)
Evolution rapide
Les questions à résoudre












L’invocation de méthodes à distance
Le cycle de vie des objets
LL’intégration
intégration avec le backend
Les transactions
L’audit et les traces
Le déploiement et le redéploiement
Les arrêts du serveur
La concurrence
L gestion
La
i d
des messages
L’équilibrage de la charge
La sécurité
…
6
14/09/2009
Le problème n°1




L’appel de méthodes à distance
Comment faire en sorte de pouvoir appeler une fonction
d’ programme dans
d’un
d
autre
t programme quii ne partage
t
pas le même espace d’adressage ?
Quels sont les problèmes qui se posent ?
Quelles sont les solutions ?
Découpage de l’application

La procédure comme brique de base


Procédure = abstraction
A ld
Appel
de procédure
éd
à distance
di

RPC – remote procedure call
7
14/09/2009
RPC

Historique




Idée en 1976 (RFC 707)
Im l t ti par SUN en 1988
Implantation
Utilisé par NFS (entre autre)
Avantages


Appel distant identique à l’appel local
Abstraction : la distribution est masquée
SUN RPC (1988)

Génération du code commun à tous les appels
8
14/09/2009
SUN RPC

Le Talon Client








Reçoit l’appel local
Emballe les pparamètres (marshalling)
(
g)
Crée un identificateur
Exécute l’appel client
Attend le résultat
Reçoit et déballe les résultats (unmarshalling)
Les retourne au client
Le Talon serveur




Reçoit le
R
l message d’appel
d’
l
Déballe les paramètres
Exécute la procédure en local
Emballe et transmet le résultat
Découpage de l’application

Problème de la granularité des appels


Cout d’un aller retour sur les réseau (ms)
C mm t structurer
Comment
t t
l’application
l’ li ti : question
ti d’
d’architecture
hit t
9
14/09/2009
Architectures applicatives : un niveau
Deux niveaux


Problème de déploiement et de maintenance
Cohérence des traitements
10
14/09/2009
Trois niveaux
Quatre niveaux ou plus
11
14/09/2009
Le modèle Client - Serveur




Le client demande à exécuter un service
Le serveur exécute le service
Client et serveur sont sur des machines distinctes (ou
pas)
Indépendance Interface/Implantation
Client
Serveur
Interface
Les défis de l’informatique répartie

Problèmes théoriques



Informatique concurrente : compétition, interblocage, famine
I f m ti
Informatique
di
distribuée
t ib é : connaissance
i
partielle,
ti ll communication
mm i ti
asynchrone, consensus
Problèmes pratiques






Identification des objets sur le réseau
Transmission des paramètres et des résultats
Hétérogénéité
Traitement des erreurs
Gestion de l’exécution
Gestion de la mémoire (GC distribué)
12
14/09/2009
La désignation et la liaison



Désignation : nom qu’une entité donne à une autre
Liaison : faire se rencontrer les entités
Désignation : quelle est la procédure appelée, sur quel
site d’exécution.


La désignation doit être indépendante de la localisation
Li i
Liaison
précoce
é
ou tardive
di


Précoce : connue à la compilation
Tardive : sélection à l’exécution (au premier ou à chaque appel)
Utilisation d’un annuaire

1: Enregistrement du serveur dans l’annuaire
2: Recherche du serveur par le client

Critère de recherche



Par nom (machine, fonction, service)
Par propriété (CPU, mémoire, disque,…)
13
14/09/2009
Représentation des données en mémoire


Hétérogénéité des machines
Différences de représentation




LLittle-endian
l
d (x86)
( 86) vs Big-endian
B
d (ppc,
(
sparc))
Représentation des flottants (IEEE 754)
Alignement des données dans les structures
Tailles
Représentation des données sur le réseau

eXternal Data Representation (XDR, SUN RPC)



Pivot pour la transmission sur le réseau
Bibli thè
Bibliothèques
d
de conversion
i
Autres solutions





htonl, ntohl, etc : conversions manuelles
ASN.1 : normalisé mais lourd
XML : SOAP, JXTA. Un peu lourd
IIOP : CORBA
NDR : le récepteur décode.
14
14/09/2009
Passage des paramètres

Passage par valeur : toto(43)


P
Passage
par référence
éfé
: toto(&x)
(& )


Pas de problème
Impossible, pas le même espace d’adressage
Passage par copie/restauration

Solution imparfaite
Problème d’aliasing
15
14/09/2009
Les défaillances

Réseau




Serveur



Congestion – message retardé mais pas perdu
P t de
Perte
d message
m
Ordre d’arrivée des messages
Avant, pendant, après l’exécution de la procédure
Panne définitive vs reprise possible
Client


Pendant l’exécution de la procédure
Panne définitive ou retour ultérieur
Traitement des défaillances

Détection : timeout à différents points du RPC

Sémantique du RPC en présence de défaillances



Au moins une fois : essais tant que échec
Au plus une fois : un seul essai
Exactement une fois : difficile à assurer (transactions)
16
14/09/2009
Congestion réseau ou serveur



Panne transitoire
Détection : délai de garde A ou D
R i en A
Reprise


Réemission par le talon client (même Id)
Le serveur peut détecteur une réémission



Reprise en D


Exécution en cours : ne fait rien
Résultat émis : réémet le résultat
Réé
Réémission
du
d résultat
é l
Sémantique assurée


Si défaillance transitoire : exactement une fois
Si défaillance permanente : détection et notification de l’application
Panne du serveur


Détection : expiration du délai de garde A
Le client ne connait pas la défaillance



É d
État
du traitement ? Commencé
C
é ? Fini
F ?
Reprise : Le client réémet dès le retour du serveur
Sémantique : au moins une fois

Exactement une fois possible avec un service transactionnel
17
14/09/2009
Panne du client



Appel traité, servant déclaré « orphelin »
Détection : expiration du délai de garde D (n
réémissions)
éé i i )
Reprise avant retour client


Reprise après le retour du client


Elimination des orphelins
Client réémet l’appel (ID différent, réémission non détectée)
Sémantique : au moins une fois
Objets distribués


RPC avec des objets
Utilisable comme un objet depuis un client distant
18
14/09/2009
Développement d’un objet distribué


Prise en compte de son contexte d’exécution
Middleware explicite


LLe dé
développeur
l
est chargé
h é des
d appels
l transversaux (sécurité,
(é
é
transactions,…)
Middleware implicite

Contexte déclaratif. C’est le container de l’objet qui se charge
de tout.
Middleware explicite
19
14/09/2009
Middleware implicite
RPC vs RMI (Remote Method Invocation)

Les RPC masquent les communications



Mais statique et synchrone
Diffi il à m
Difficile
mettre
tt en œuvre
Programmation objet




Encapsulation, interface bien définie
Classes et instances
Héritage
Polymorphisme
y
p
(facile
(
les évolutions))
20
14/09/2009
Java RMI


Objectif : simplifier la programmation d’applications
réparties en Java
Mê
Même
principe
i i que RPC

Le programmer fournit





La description des interfaces
Les objets implantant ces interfaces
L’implantation du serveur qui instancie les objets
Le client qui appelle des méthodes sur ces objets
L’
L’environnement
JJava ffournit



La génération dynamique des talons
Un service de nommage (registry)
La possibilité de charger le code à distance
Objets distants : les problèmes

Créer un objet


Comment faire un new du client vers le serveur
Référence d’objets
j distants

Le nommage
Objet opaque + méthodes d’usage

Exemples






Localisation et protocole d’accès
Java RMI : talon client lui-même
CORBA : IOR (Interoperable Object Reference)
DCOM : format propriétaire
Chargement du code


Le bytecode java est portable et chargeable dynamiquement
Simplifie le déploiement
21
14/09/2009
Principes de programmation

Les grandes lignes





Définir l’interface
Im l t l’i
Implanter
l’interface
t f
((objet
bj t servant)
t)
Implanter le programme qui crée le servant et l’enregistre
(serveur)
Implanter le programme qui appelle les méthodes sur le
servant (client)
Le contrat de l’interface



Doit être publique
Doit étendre java.rmi.Remote
Chaque méthode doit retourner l’exception
java.rmi.RemoteException
Principes de programmation

La classe distante



Le serveur




Doit implanter l’interface distante (Remote)
Peut avoir des méthodes locales (non disponibles pour le client)
Instancie et installe un gestionnaire de sécurité
Instancie la classe servant
Enregistre l’instance de la classe servant dans le serveur de noms
Le serveur de nom (registry)



Maintient la
M
l relation
l
nom – référence
éfé
d’
d’objet
b
Implante java.rmi.registry.Registry
Fournit les méthodes d’enregistrement et de recherche (bind,
lookup)
22
14/09/2009
Exemple

L’interface HelloInterface.java
Exemple

L’implantation du servant : HelloImpl.java
23
14/09/2009
Exemple

Implantation du serveur : Serveur.java
Exemple

Implantation du client : Client.java
24
14/09/2009
Compilation et déploiement

Il faut bien sur compiler toutes les classes


S lle serveur
Sur


HelloInterface, HelloImpl, Serveur
Sur le client


javac *
Client, HelloInterface
Il est préférable de faire des jar (simplifie le déploiement)
Exécution

rmiregistry &




Lancer le serveur


Port par défaut : 1099
Il estt possible
ibl d
de changer
h
lle portt mais
m i il faudra
f d le
l passer en
argument dans le serveur et le client
-J-Dsun.rmi.loader.logLevel=BRIEF pour écouter ce qui se
passe
java -Djava.security.policy=java.policy HelloServer &
Lancer le client

java HelloClient &
25
14/09/2009
La sécurité



Accepter des connections réseau de machines distantes
est dangereux
E é t du
Exécuter
d code
d téléchargé
télé h é estt dangereux
d
Politique de sécurité : spécification des actions autorisées


Sans policy, les connections externes sont refusées
Fichier java.policy
Exécution d’un RMI de base en Java
26
14/09/2009
Téléchargement de code



Talons centralisés et classes sur un site Web
Téléchargement automatique sur les clients
Il y a téléchargement quand




Le client obtient une souche qui n’est pas dans son
CLASSPATH (prioritaire)
Le serveur obtient une référence d’objet dont la classe est
inconnue
Désignation
g
de la localisation des classes :
Spécification de l’URL du codebase :
RMI et téléchargement de code
27
14/09/2009
Polymorphisme et RMI

Polymorphisme




Par passage de paramètres



Comme d’habitude : utilisation d’un type dérivé de celui
attendu
Téléchargement du code du sous-type
Permet l’évolution du code
Le serveur offre une méthode m(C1 p)
Le client invoque serveur.m(p) . La classe de p dérive de C1
Par retour de résultat


Le client exécute C1 r=serveur.m(…)
Serveur retourne un objet de classe C2 sous classe de C1
Création d’objets à distance (Fabrique)


Le client ne peut pas demander la création d’objets sur le
serveur
Il doit
d it d
demander
d à un servantt de
d lui
l i créer
é des
d objets
bj t

Par exemple maintien de session différentes pour chaque client
28
14/09/2009
Implantation de la fabrique
Mise en œuvre de la fabrique
29
14/09/2009
L’exécution
Parallélisme et asynchronisme

Plusieurs clients accède à un serveur RMI

Quel doit être le comportement du serveur ?


Exécution parallèle ? Séquentiel (FIFO) ?
Mise en œuvre actuelle : threads



Appels en parallèle
Accès concurrent aux ressources
Gestion explicite de la cohérence des données globales
30
14/09/2009
Appels en retour


Les appels RMI sont synchrones (le client attend la
réponse)
C
Comment
t ffaire
i sii




Le serveur a besoin d’interroger le client ?
Le serveur veut notifier le client (MVC)
L’exécution du service a besoin du client
Solution : les callbacks (appels en retour)

Permet au serveur d
d’appeler
appeler un méthode sur le client



Le client appelle le serveur avec retour immédiat
Le serveur contacte le client en cas de besoin (callback)
Le client est aussi un objet remote pour le serveur
Appels en retour


Problème : risque de deadlock
Autre problème : référence pendante sur le serveur

L clients
Les
l
peuvent d
disparaitre sans prévenir
é
31
14/09/2009
Mise en œuvre RMI

On passe au serveur un objet remote qui fournit une
méthode de rappel
Implantation du serveur
32
14/09/2009
Implantation du client
Implantation du servant
33
14/09/2009
Implantation du callback

Où a lieu l’affichage du message ?
Conception des applications réparties

Problèmes récurrents






Architecture logicielle
Dé i ti ett liliaison
Désignation
i
Sécurité
Gestion des erreurs, tolérance aux pannes
Qualité de service
Transactions, communication de groupe, anonymat
34
14/09/2009
Conception des applications réparties


Solutions éprouvées : patrons de conception
Principe généraux

Sé
Séparation
d
des préoccupations
é




Isoler les aspects orthogonaux et les traiter séparément
Eliminer les interférences
Evolution indépendante des solutions à chaque aspect
Mise en œuvre




Encapsulation
Abstraction
Composant
Programmation par aspects
Un patron : le proxy




Le client accède à un objet distant
On veut masquer au client les problèmes liés à la
répartition
é titi
Le proxy a la même interface que le servant
Le proxy ou mandataire prend en charge la
communication et tous les problèmes liés à la répartition
35
14/09/2009
Proxy (rappel)
La factory

Problème : créer et obtenir une référence à un objet sur
le serveur


Il faut que l’évolution
l évolution reste possible
Solution : la factory


Fournit des méthodes de construction d’objets
Abstract factory : permet d’obtenir des références sur des
factory concrètes


Evolution plus facile
Mise en œuvre de nouvelles classes
36
14/09/2009
Gestion des pools

Réduire le cout de la gestion des ressources




Connection à des bases de donnée
I t
Instances
d
de classe
l
Thread
Principe



Réutiliser des exemplaires existant
On constitue une réserve de ressources
On alloue les ressources pplutôt qque d’en créer de nouvelles
Wrapper ou adapter

Contexte






Les servants fournissent un service définit par une interface
L clients
Les
li t demandent
d m d t des
d services
i
avec une interface
i t f
différente
Adapter l’interface du servant au client
On utilise un wrapper qui implante l’interface dont a
besoin le client et transforme les appels vers le servant.
Le wrapper peut être mis du coté client (combinaison
avec le proxy)
Il peut être mis du coté du serveur (combinaison avec
intercepteur)
37
14/09/2009
Adapter (rappel)
Intercepteur

Transformation du service, changement conditionnel de
l’appel





Contrôle de sécurité
Audit
Transaction
…
Solution

Créer des objets
j d’interposition
p
((décorateur))
38
14/09/2009
Rappel décorateur
Comparaison des patrons

Wrapper vs proxy


W
Wrapper
vs Interceptor
I


---------------------------------------------------------------------
Proxy vs Interceptor

-----------------------------------
39
14/09/2009
Conclusion sur RMI

Points forts





Intégration au langage
Ch
Chargement
m t dynamique
d mi
de
d code
d
Politique de sécurité explicite
Copie profonde des paramètres passés
Mais…


Intéropérabilité
Services à mettre en œuvre à la main


Nommage basique
Gestion des threads, transactions, réplication
Conclusion

Objectifs pour la construction d’applications réparties




RPC




Simplifier le développement
Sim lifi lla m
Simplifier
maintenance
i t
Intéropérabilité
Tout est à la charge du développeur
Manque d’abstraction
Evolution difficile
Objets distribués


Meilleure abstraction/modularité
Vers une séparation des préoccupations
40
14/09/2009
Conclusion

Limite des objets distribués




Pas de vision de l’architecture
P de
Pas
d séparation
é
ti des
d préoccupations
é
ti
Pas d’outil pour la composition et le déploiement
Réponse



Les approches à composants
Les approches orientées services
Les serveurs d’applications
pp
41