Programmation d applications. Comprendre les fondements de la programmation d applications réparties

Transcription

1 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

2 Plan du cours Introduction et principes de base Architecture, conception Plateformes Défis majeurs Middleware (définition, caractérisation, histoire) Invocation de méthodes à distance (RMI Java) Modèle, principes, mise en œuvre J2EE, EJB Objet distribué, Persistence, aspects non fonctionnels Service et orchestration Web Service, BPEL Bibliographie Cours de Martin Quinson (ESIAL 2008) Cours sur Internet Systèmes et Applications Répartis (S. Krakowiak) Ecole d été sur les intergiciels Autres références fr/~charoy/index.php?n=main.par2009 2

3 Introduction et principes de base Introduction Architectures applicatives RPC Multi-niveaux Patrons de conception 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

4 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 plusieurs éléments. Propriétés des applications Sureté Sécurité Disponibilité Maintenabilité, extensibilité Passage à l échelle 4

5 Définitions de propriétés Sureté (Reliability) Probabilité qu un système fonctionne à t+1 s il fonctionnait à t. Disponibilité ibili (Availability) Pourcentage du temps pendant lequel un système est disponible (de 99 à 99,999) Serviceability Facilité de maintenance corrective et préventive (améliore la disponibilité) Passage à l échelle Cout pour passer de 1 à 10, 100, 1000, clients Problèmes Détection des défaillances des éléments Multiplication des causes de pannes Problèmes liés à la communication i Coupure, déconnection, pertes de messages Ouverture et donc problèmes de sécurité Confidentialité, intégrité, déni de service Il faut prendre des décisions sont connaitre réellement la Il faut prendre des décisions sont connaitre réellement la situation Timeout, redéploiement, changement de service, annulation 5

6 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 L 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 La gestion des messages L équilibrage de la charge La sécurité 6

7 Le problème n 1 L appel de méthodes à distance Comment faire en sorte de pouvoir appeler une fonction d un programme dans autre programme qui ne partage 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 Appel de procédure à distance RPC remote procedure call 7

8 RPC Historique Idée en 1976 (RFC 707) Implantation ti par SUN en 1988 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

9 SUN RPC Le Talon Client Reçoit l appel local Emballe les paramètres (marshalling) 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 message d appel 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) Comment structurer t l application li : question d architecture t 9

10 Architectures applicatives : un niveau Deux niveaux Problème de déploiement et de maintenance Cohérence des traitements 10

11 Trois niveaux Quatre niveaux ou plus 11

12 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 If Informatique mti ditibé distribuée : connaissance partielle, till communication 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

13 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 Liaison i précoce ou tardive 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 Représentation des données en mémoire Hétérogénéité des machines Différences de représentation Little-endian (x86) vs Big-endian (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 Bibliothèques de conversion 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

15 Passage des paramètres Passage par valeur : toto(43) Pas de problème Passage par référence : toto(&x) Impossible, pas le même espace d adressage Passage par copie/restauration Solution imparfaite Problème d aliasing 15

16 Les défaillances Réseau Congestion message retardé mais pas perdu Perte de message Ordre d arrivée des messages Serveur 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

17 Congestion réseau ou serveur Panne transitoire Détection : délai de garde A ou D Reprise en A Réemission par le talon client (même Id) Le serveur peut détecteur une réémission Exécution en cours : ne fait rien Résultat émis : réémet le résultat Reprise en D Réémission du résultat 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 État du traitement? Commencé? Fini? 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

18 Panne du client Appel traité, servant déclaré «orphelin» Détection : expiration du délai de garde D (n réémissions) i Reprise avant retour client Elimination des orphelins Reprise après le retour du client 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

19 Développement d un objet distribué Prise en compte de son contexte d exécution Middleware explicite Le développeur est chargé des appels transversaux (sécurité, transactions, ) Middleware implicite Contexte déclaratif. C est le container de l objet qui se charge de tout. Middleware explicite 19

20 Middleware implicite RPC vs RMI (Remote Method Invocation) Les RPC masquent les communications Mais statique et synchrone Difficile il à mettre en œuvre Programmation objet Encapsulation, interface bien définie Classes et instances Héritage Polymorphisme (facile les évolutions) 20

21 Java RMI Objectif : simplifier la programmation d applications réparties en Java Même principe 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 environnement Java fournit 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 distants Le nommage Objet opaque + méthodes d usage Localisation et protocole d accès Exemples 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

22 Principes de programmation Les grandes lignes Définir l interface Implanter l interface (objet servant) 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 Doit implanter l interface distante (Remote) Peut avoir des méthodes locales (non disponibles pour le client) Le serveur 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 relation nom référence d objet Implante java.rmi.registry.registry Fournit les méthodes d enregistrement et de recherche (bind, lookup) 22

23 Exemple L interface HelloInterface.java Exemple L implantation du servant : HelloImpl.java 23

24 Exemple Implantation du serveur : Serveur.java Exemple Implantation du client : Client.java 24

25 Compilation et déploiement Il faut bien sur compiler toutes les classes javac * Sur le serveur HelloInterface, HelloImpl, Serveur Sur le client Client, HelloInterface Il est préférable de faire des jar (simplifie le déploiement) Exécution rmiregistry & Port par défaut : 1099 Il est possible de changer le port mais mi il faudra le passer en argument dans le serveur et le client -J-Dsun.rmi.loader.logLevel=BRIEF pour écouter ce qui se passe Lancer le serveur java -Djava.security.policy=java.policy HelloServer & Lancer le client java HelloClient & 25

26 La sécurité Accepter des connections réseau de machines distantes est dangereux Exécuter du code téléchargé é est dangereux 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

27 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 de la localisation des classes : Spécification de l URL du codebase : RMI et téléchargement de code 27

28 Polymorphisme et RMI Polymorphisme 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 Par passage de paramètres 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 demander d à un servant de lui créer des objets Par exemple maintien de session différentes pour chaque client 28

29 Implantation de la fabrique Mise en œuvre de la fabrique 29

30 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

31 Appels en retour Les appels RMI sont synchrones (le client attend la réponse) Comment faire si 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 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 Les clients peuvent disparaitre sans prévenir 31

32 Mise en œuvre RMI On passe au serveur un objet remote qui fournit une méthode de rappel Implantation du serveur 32

33 Implantation du client Implantation du servant 33

34 Implantation du callback Où a lieu l affichage du message? Conception des applications réparties Problèmes récurrents Architecture logicielle Désignation et liaisoni Sécurité Gestion des erreurs, tolérance aux pannes Qualité de service Transactions, communication de groupe, anonymat 34

35 Conception des applications réparties Solutions éprouvées : patrons de conception Principe généraux Séparation 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 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

36 Proxy (rappel) La factory Problème : créer et obtenir une référence à un objet sur le serveur Il faut que 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

37 Gestion des pools Réduire le cout de la gestion des ressources Connection à des bases de donnée Instances de classe Thread Principe Réutiliser des exemplaires existant On constitue une réserve de ressources On alloue les ressources plutôt que d en créer de nouvelles Wrapper ou adapter Contexte Les servants fournissent un service définit par une interface Les clients demandent d des services avec une interface 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

38 Adapter (rappel) Intercepteur Transformation du service, changement conditionnel de l appel Contrôle de sécurité Audit Transaction Solution Créer des objets d interposition (décorateur) 38

39 Rappel décorateur Comparaison des patrons Wrapper vs proxy Wrapper vs Interceptor Proxy vs Interceptor

40 Conclusion sur RMI Points forts Intégration au langage Chargement dynamique de code 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 Simplifier le développement Simplifier la maintenance Intéropérabilité RPC 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

41 Conclusion Limite des objets distribués Pas de vision de l architecture Pas de séparation des préoccupations Pas d outil pour la composition et le déploiement Réponse Les approches à composants Les approches orientées services Les serveurs d applications 41