Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Bernard ESPINASSE - Architecture Client-Serveur 1 Architectures Client-Serveur

Bernard ESPINASSE - Architecture Client-Serveur 1 Architectures Client-Serveur Bernard ESPINASSE Professeur à Aix-Marseille Université (AMU) Ecole Polytechnique Universitaire de Marseille Octobre 2018 • Introduction • Couplage entre client et serveur • Découpage d’une application, Middleware • Différentes architectures de Client-Serveur • Middleware en détail • Performance/Optimisation en Client-Serveur Bernard ESPINASSE - Architecture Client-Serveur 2 Plan 1. Introduction • Pourquoi le C/S • Les enjeux 2. Couplage client-serveur • Découpage d'une application • Dialogue entre client et serveur : le Middleware • Types de Middleware : RPC, APPC / RDA, Message queuing, … 3. Architectures client-serveur • Les différentes générations de C/S • Client - Serveur 2 tiers • Client - Serveur 3 tiers • Client - Serveur N tiers (Multi tiers) 4. Performance/optimisation en Client-Serveur Bernard ESPINASSE - Architecture Client-Serveur 3 1. Introduction • Pourquoi le C/S • Les enjeux Bernard ESPINASSE - Architecture Client-Serveur 4 Introduction : pourquoi le Client-Serveur ? Evolution des organisations : 1980-1990 1985-1995 1995-2000 hiérarchique et centralisé hiérarchique et décentralisé réparti (entreprise virtuelle) Bernard ESPINASSE - Architecture Client-Serveur 5 Pourquoi le Client-Serveur ? Inversion de la pyramide : Bernard ESPINASSE - Architecture Client-Serveur 6 Pourquoi le Client-Serveur ? • évolution des besoins : production, informationnel, communication • évolution des techniques : micro-informatique + réseaux locaux • contraintes des architectures hierachiques : réseau centralisé, hétérogénité des postes de travail, rigidité des applications, ... → le client-serveur : • principes généraux : • poste de travail multi-fonction • possibilité d'accés multi-serveur • localisation des données • répartition des traitements • pilotage par l'utilisateur • conséquences : • définition de relation Client - Fournisseur • transformation des métiers • évolution des responsabilités • une mutation délicate Bernard ESPINASSE - Architecture Client-Serveur 7 Enjeux stratégiques du Client-Serveur ? Enjeux stratégiques : • productivité individuelle (micro) • performance collective : communication, disponibilité du patrimoine d'information personnalisable • réactivité : réduction des délais, flexibilité des applications Enjeux organisationnels : • souplesse organisationnelle par banalisation du couple "homme-machine" et "polyvalence" du personnel • fluidité de l'information • communication inter-services et inter-personnes Enjeux humains : • usage intuitif, appropriation de l'outil, enrichissement des tâches, initiative, moindre résistance au changement, communication,... Enjeux techniques : • cohérence technique : libres échanges des applications et des informations, … • définition d'architectures modulaires : serveurs, poste de travail, … • édification de normes et standards : chartes, guides, règles d'hygiène , … Bernard ESPINASSE - Architecture Client-Serveur 8 2. Couplage client-serveur • Découpage d’une application • Dialogue entre client et serveur • Inter Process Communication (IPC) ou Middleware Bernard ESPINASSE - Architecture Client-Serveur 9 Découpage d'une application : 3 niveaux Bernard ESPINASSE - Architecture Client-Serveur 6 D é c o u p a g e d ' u n e a p p l i c a t i o n : 3 n i v e a u x Présentation gestion de la présentation logique de la présentation Traitements logique des traitelents gestion des traitements Données logique des données coeur de l'application gestion des données • l'interface avec l'utilisateur 1 • la gestion de l'affichage : concerne le fenêtrage (lié à un env. graphique d'exploitation (Window, XWindow,...)) 2 • la logique de l'affichage : transmet à la gestion de l'affichage la description des éléments de présentation • les traitements 3 • la logique des traitements : contient l'arborescence algorithmique de l'application ( → lancement des procédures de la couche 4) 4 • la gestion des traitements : procédures de traitements contenant des requêtes SQL de manipulation de données) • les données 5 • la logique des données : garantit le respect de la règle CRUDE pour les objets de la BD mis à jour par les procédures 6 • la gestion des données : sélections ou mises à jour des enregistrements (généralement pris en charge par le SGBD) Modules 2 et 3 inséparables : coeur de l'application !!! • l'interface avec l'utilisateur 1 • la gestion de la présentation : concerne le fenêtrage (lié à un env. graphique d'exploitation (Window, XWindow,...)) 2 • la logique de la présentation : transmet à la gestion de l'affichage la description des éléments de présentation • les traitements 3 • la logique des traitements : contient l'arborescence algorithmique de l'application ( → lancement des procédures de la couche 4) 4 • la gestion des traitements : procédures de traitements contenant des requêtes SQL de manipulation de données) • les données 5 • la logique des données : garantit le respect de la règle CRUDE pour les objets de la BD mis à jour par les procédures 6 • la gestion des données : sélections ou mises à jour des enregistrements (généralement pris en charge par le SGBD) Modules 2 et 3 inséparables : coeur de l'application !!! Bernard ESPINASSE - Architecture Client-Serveur 10 Découpages d'une application : grandes stratégies 1 • Application en traitements coopératifs : → module de logique de traitement : • éclaté sur plusieurs processeurs • résidant sur plusieurs machines 2 • Application en client/serveur : → un ou plusieurs modules sont déportés sur un serveur : Ex: le module de gestion des données est transformé en service et hébergé par un serveur (serveur de données) Bernard ESPINASSE - Architecture Client-Serveur 11 Dialogue entre client et serveur • Permettre l'échange de la demande et du résultat à cette demande • S'effectue à travers le réseau qui relie les 2 machines : → Dialogue interprocessus : Inter Process Communication (IPC) qui s'appuie côté client et côté serveur sur : • API : Application Programming Interfaces (interface de programmation au niveau applicatif) • FAP : Format And Protocols (protocoles de communication et formats de données) IPC = Middleware (intergiciel) = ensemble des couches logicielles qui s'interposent entre l'application et le réseau Bernard ESPINASSE - Architecture Client-Serveur 12 Inter Process Communication (IPC) ou Middleware • FAP (Format And Protocols) pilote les échanges à travers le réseau : • synchronisation des échanges selon un protocole de communication • mise en forme des données échangées selon un format connu de part et d'autre • API (Application Programming Interfaces) : • les fonctions encapsulées dans l'API permettent à l'application de faire appel aux services proposés par le serveur Bernard ESPINASSE - Architecture Client-Serveur 13 Exemple de dialogue C/S SELECT libellé, date, sujet FROM dossiers WHERE responsable = mon_user • l'application construit la requête et fait appel à des fonctions de l'API pour l'envoyer au serveur : • fonction 1: remise à zéro de la zone tampon • fonction 2: écriture du message de requête, première partie • fonction 3: écriture du message de requête, seconde partie à mettre à la suite du précédent • fonction 4: fermeture de la zone tampon, le message est complet • fonction 5: vérification de la syntaxe de la requête (analyse du message par l'API (phrase en ASCII)) • si OK : fonction 6: passer la main au FAP pour envoi du message au serveur. L'application se met en attente de la réponse ou effectue une autre tâche en attendant de consulter l'API pour récupérer le résultat • l'API passe la main au FAP : • formatage du message : encapsulation du message dans une trame réseau (valise) • envoi du message formaté au serveur : selon le protocole de communication • à son arrivé, le résultat subit le même l'opération inverse Bernard ESPINASSE - Architecture Client-Serveur 14 Types de Middleware • caractérise la nature du dialogue : • synchrone / asynchrone : obligation (/ou non) pour le client d'attendre la réponse du serveur après chaque envoi • avec connexion / sans connexion (ou avec session): nécessité (/ou non) d'établir une connexion entre le client et le serveur Dialogue ... sans session avec session synchrone RPC APPC ou RDA asynchrone message queuing APPC ou RDA • RPC : Remote Procedure Call ou appels de procédure à distance (ex: DCE = IPC basé sur RPC) • APPC : Application Program to Communication (l'APPC = élément de SNA d'IBM) • RDA : Remote Data Access : norme de l'ISO pour l'accès distant aux BdD Bernard ESPINASSE - Architecture Client-Serveur 15 RPC : dialogue synchrone sans cession • le client fait une RPC et reste "suspendu" en attendant la réponse du serveur • conversation synchrone très simple : • le message d'appel contient tous les éléments nécessaires au serveur (nom de la procédure et paramètres associés, données d'identification de l'appelant (pour vérifier autorisation)) • le message en retour, en un seul flot, contient toute la réponse attendue par le programme client → Inconvénients : • synchrone • fiabilité médiocre (si l'émission initiale échoue, le client n'est pas averti et pas de mécanisme de reprise interne au protocole sous-jacent), • pas de resynchronisation possible entre C et S • pas de gestion de flux de retour (tjs un seul flot) Bernard ESPINASSE - Architecture Client-Serveur 16 APPC/RDA : dialogue asynchrone avec session • la demande de connexion émise par le programme client • si le serveur accepte la connexion → création d'un contexte propre au programme client sur le serveur • durant uploads/Management/ clientserveur-4p-pdf.pdf