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