Support des services et des serveurs L’architecture Client-Serveur.

41
Support des services et des serveurs L’architecture Client- Serveur

Transcript of Support des services et des serveurs L’architecture Client-Serveur.

Page 1: Support des services et des serveurs L’architecture Client-Serveur.

Support des services et des serveurs

L’architecture Client-Serveur

Page 2: Support des services et des serveurs L’architecture Client-Serveur.

PLAN

• HISTORIQUE• DEFINITION• AVANTAGES DU C/S• TECHNIQUE DE DIALOGUE DU C/S• LES DIFFERENTS TYPES DE C/S• LES BD ET LE C/S• ARCHITECTURE C/C INTERNET - INTRANET

Page 3: Support des services et des serveurs L’architecture Client-Serveur.

I - Historique

• Architecture centralisée : mainframe ;• Terminaux passif : Juste des écrans ;• Productivité des programmeurs faibles : maintenance difficiles• Utilisateur prisonnier : système propriétaire

• Cependant application encore en cours, difficile de les éradiquer. Mais souvent remplacement des anciens calculateurs centraux par un ou plusieurs serveurs départementaux interconnectés à des stations de travail graphiques de type PC par exemple.

A – Avant 1980

Terminaux passif

Applications

Système d’exploitation

BD

Page 4: Support des services et des serveurs L’architecture Client-Serveur.

• Développement des bases de données et du Transactionnel.

• Commencement de la migration du centralisé vers des systèmes plus ouvert tel que UNIX.

• Bases de données relationnelles s’imposent.

• Développement de langages qui tournent autour des données. • SQL : une norme.

• Développement des réseaux.

• Parallèlement les PC et leur monde graphique ont commencé à s’imposer dans les entreprises.

B – Les années 80

Page 5: Support des services et des serveurs L’architecture Client-Serveur.

• Réseaux : place centrale dans l’entreprise;• Le graphisme omniprésent;• Accélération technologique du matériel;• Besoin du partage de l’information essentiel;• Pour toutes ces raisons nous avons l’évolution suivante :

C – Les années 90

clientsMachine serveur

Échange

via le réseau

Page 6: Support des services et des serveurs L’architecture Client-Serveur.

• L’architecture c/s s’articule en générale autour d’un réseau.

• Deux types d’ordinateurs sont interconnectés. – Le SERVEUR (assure la gestion des données entre les utilisateurs), – le CLIENT (gestion de l’interface graphique et la station de travail

personnelle).

• Les deux communiquent par des protocoles.

• Les programmes doivent être idéalement réparti entre le client et le serveur pour réduire les coûts.

• Dans la réalité l’architecture c/s est plus large car un réseau n’est pas obligatoire, on peut réaliser sur la même machine un processus client et un processus serveur.

II - DéfinitionA – Une répartition hiérarchique des fonctions

Page 7: Support des services et des serveurs L’architecture Client-Serveur.

• On dira que l’on travaille en c/s lorsque les traitements et la gestion des données d’un applicatif s’exécutent simultanément sur plusieurs machines. Le client est une machine de type micro-ordinateur ; le serveur dispose généralement de ressources mémoire et disque importantes associés à une grande puissance de calcul.

• Le concept de client/serveur s’appuie sur trois supports technologiques :

client – serveur - réseau

B – Définition

Page 8: Support des services et des serveurs L’architecture Client-Serveur.

• Il faut :• Mieux satisfaire les clients, par exemple en leur présentant des

informations consolidées et claires ;• Respecter les réglementations en vigueur (réagir vite);• Produire mieux et plus vite;

III – Les avantages du client/serveurA – Les contraintes de l’entreprise

Les contraintes interne à l’entreprise

• Pour être plus compétitif, il faut :• Mieux maîtriser le système d’information ;• Prendre en compte les évolutions des technologies• Réduire les coûts.

Page 9: Support des services et des serveurs L’architecture Client-Serveur.

• Le c/s est avant tout une technique de dialogue entre deux processus : l’un LE CLIENT sous traitant à l’autre : LE SERVEUR des fonctions à réaliser.

• Le modèle de communication c/s est orienté vers la fourniture de service par un processus SERVEUR à un processus CLIENT. Cet échange consiste donc en la transmission d’une requête à un serveur qui exécute l’opération demandée et envoi en retour une réponse.

• En général, c/s s’exécutent sur des machines hétérogènes qui communiquent par un réseau. Les données sont souvent codées de manières différentes sur des machines distinctes. Il est donc nécessaire de définir un format d’échange standard, afin de convertir les noms de fonctions et paramètres dans ce format au départ et à l’arrivée.

• Lors de l’émission d’une requête les paramètres doivent être codées sous forme de message : c’est l’ASSEMBLAGE et décodé lors de l’arrivée : c’est le DESASSEMBLAGE.

IV – Technique de dialogue c/s

Page 10: Support des services et des serveurs L’architecture Client-Serveur.

– Interopérabilité multi-technologie– Réduction de la complexité– Uniformisation des interfaces– Ingénierie modulaire– Evolution rapide des technologies– Simplification de l’enseignement et de l’acquisition des connaissances

A – Rappel du modèle OSI : Avantages

Page 11: Support des services et des serveurs L’architecture Client-Serveur.

A – Rappel du modèle OSI : Terminologie OSI/TCP-IP : Protocoles et services

Page 12: Support des services et des serveurs L’architecture Client-Serveur.

A – Rappel du modèle OSI : Terminologie OSI/TCP-IP : Protocoles et services

Source : ENSEIHT

Page 13: Support des services et des serveurs L’architecture Client-Serveur.

A – Rappel du modèle OSI : Terminologie OSI/TCP-IP : Services et encapsulation

Source : ENSEIHT

Source : cours M.Braux

Page 14: Support des services et des serveurs L’architecture Client-Serveur.

Source : cours M.Braux

A – Rappel du modèle OSI : Terminologie OSI/TCP-IP : Gestion de l’hétérogénéité

Page 15: Support des services et des serveurs L’architecture Client-Serveur.

A – Rappel du modèle OSI : Terminologie OSI/TCP-IP : Services et encapsulation

Source : cours M.Braux

Page 16: Support des services et des serveurs L’architecture Client-Serveur.

A – Rappel du modèle OSI : Terminologie OSI/TCP-IP : Services et encapsulation

Source : ENSEIHT

Page 17: Support des services et des serveurs L’architecture Client-Serveur.

A – Rappel du modèle OSI : OSI et TCP-IP

Source : ENSEIHT

Page 18: Support des services et des serveurs L’architecture Client-Serveur.

Source : cours M.Braux

A – Rappel du modèle OSI : OSI et TCP-IP

Page 19: Support des services et des serveurs L’architecture Client-Serveur.

• Les sockets - interface de programmation permettant l'échange de données (via TCP ou UDP)

Source : cours M.Braux

A – Rappel du modèle OSI : Fondement des applications C/S

Page 20: Support des services et des serveurs L’architecture Client-Serveur.

• HTTP - HyperText Transport Protocol– protocole du web– échange de requête/réponse entre un client et un serveur web

• FTP - File Transfer Protocol– protocole de manipulation de fichiers distants– transfert, suppression, création, …

• TELNET - TELetypewriter Network Protocol– système de terminal virtuel– permet l'ouverture d'une session distante

• SMTP - Simple Mail Transfer Protocol– service d'envoi de courrier électronique– réception (POP, IMAP, IMAPS, …)

A – Rappel du modèle OSI : Protocoles applicatifs

Page 21: Support des services et des serveurs L’architecture Client-Serveur.

• DNS - Domain Name Service– assure la correspondance entre un nom

symbolique et une adresse Internet (adresse IP)– bases de données réparties sur le globe

• SNMP - Simple Network Management Protocol– protocole d'administration de réseau

(interrogation, configuration des équipements, …)

A – Rappel du modèle OSI : Protocoles de gestion

Page 22: Support des services et des serveurs L’architecture Client-Serveur.

• Le middleware assure une liaison transparente entre le client et le serveur. • Il est l’élément médian entre le client ou le serveur d’une part et le réseau d’autre part. • Ses objectifs sont d’assurer :

• Le transport de requêtes et de réponses ;• La simplification de la vision utilisateur ;• L’harmonisation du type de données ;• Les performances ;• La fiabilité.

• Dans le modèle c/s, le middleware assure le dialogue entre les processus client et serveur. C’est ce que l’on appelle un IPC (Inter Process Communication).

• Situé au dessous de la couche transport (couche 4) du modèle OSI, le middleware assure les fonctions se rapportant aux couches 5 (session), 6 (représentation) et 7 (application) de l’OSI.

• Le middleware a donc une double mission d’interface :• Avec le réseau (mise en forme de la donnée en vue de sa prise en charge par la couche transport) ;• Avec le processus (client ou serveur) : il permet la gestion des appels de fonctions de l’application.

• Ces deux missions du middleware sont en fait assurées par des composantes distinctes :• L’API (Application Programming Interface) ou interface de programmation au niveau applicatif ;• Le FAP (Format and Access Protocol) ou protocole d’échange et de format de données au niveau du

réseau.

B – Le middleware

Page 23: Support des services et des serveurs L’architecture Client-Serveur.

• C’est un ensemble de fonctions standards pour accéder à un service local ou distant.

• Les fonctions accessibles à l’application au moyen de l’API sont les suivantes :

• Connexion et déconnexion avec le serveur ;• Définition de l’environnement de la connexion (variables de

contexte, zone tampon…)• Transfert des requêtes ;• Réception des résultats.

• L’API transfert alors les requêtes destinées au serveur à l’autre couche du middleware : le FAP qui se chargera du conditionnement pour le transport sur le réseau.

B – Le middleware : API : couche logicielle du middleware en relation avec l’application.

Page 24: Support des services et des serveurs L’architecture Client-Serveur.

•Le FAP reçoit la requête, la renferme dans une trame destinée au transport sur le réseau.

•A l’arrivée, sur le serveur, le FAP de celui-ci, récupère la trame, la dépaquette et adresse la requête à l’adaptateur (identique à l’API pour le serveur)

API

FAP FAP

API

PROTOCOLE DE TRANSPORT

CLIENT SERVEUR

B – Le middleware : FAP : assure un formatage de la requête adressée par l’API pour permettre son transport sur le réseau

Page 25: Support des services et des serveurs L’architecture Client-Serveur.

Le middleware est donc un ensemble de programmes (par exemple des DLL) assurant la fonctions de traduction et d’adaptation entre systèmes différents.

Par exemple la couche ODBC ou le modèle objet ADO.

Ce middleware est fourni par chaque constructeur de SGBD.

Il peut être propriétaire ( SQL-Net d’Oracle) ou ouvert (ADO).

B – Le middleware :

Page 26: Support des services et des serveurs L’architecture Client-Serveur.

• Le C/S s’appuie sur le réseau ; il est donc influencé par :

• La bande passante ;• La disponibilité ;• La qualité.

• Il faut de plus penser aux problèmes de confidentialité, d’archivage et de cryptage.

C - Technologie

Page 27: Support des services et des serveurs L’architecture Client-Serveur.

• Un programme peut se décomposer en 4 blocs fonctionnelles :

• L’Interface Homme-Machine ;• Les traitements locaux (contrôle technique) ;• Les traitements globaux (comparaison des données) ;• L’accès aux données.

IV – Présentation des différents c/sA – Composante d’un programme

• La répartition de ces 4 blocs entre le client et le serveur va induire l’architecture fonctionnelle du modèle.

• Problématique de la répartition des traitements entre le client et le serveur.

Page 28: Support des services et des serveurs L’architecture Client-Serveur.

Machine client

Machineserveur BD

Échange via le réseau

IHM Accès aux données

Traitements locaux

Traitements globaux

Où se passent ces traitements ?

Répartition :

logique

physique

…vers ici ? …ou vers ici ?

Les différents modèles de clients serveurs ont été classifiés par une entreprise de consultant américain : le GARTNER GROUP

On peut avoir différents types de répartition

Page 29: Support des services et des serveurs L’architecture Client-Serveur.

Source : JP. Pujol

Page 30: Support des services et des serveurs L’architecture Client-Serveur.

• Regroupent le type 1 et le type 2. • Le type 1 = présentation distribuée.

– Apparu avec la généralisation des outils de présentation graphique. Cet ancien modèle permet de conserver les applications existantes sur les mainframes.

– Le client fournit qu’une petite partie de ses ressources pour la gestion de l’IHM.

– Le serveur élabore l’interface que le client se contente d’afficher.

– Cette version permet d’avoir un client très léger et de garder les anciennes applications, cependant elle oblige à une surcharge du serveur et des coûts importants car il faudra de nouveau migrer

• Le type 2 = présentation distante– Permet de déporter toute la gestion de l’IHM au

client. – Méthode utilisé principalement pour des

applications bancaires.

B- Détail des différents types de c/s

1 – Les c/s de présentation

Source : Cours JP Pujol

Page 31: Support des services et des serveurs L’architecture Client-Serveur.

2 – Les c/s de traitement

• Présentation la plus finalisée du client/serveur ;

• Tout ce qui peut être partagé par des applications clientes est déporté vers le serveur.

• Les requêtes ne sont plus des requêtes exprimées dans un langage de manipulation de données, mais un appel de procédure au serveur.

Source : Cours JP Pujol

Page 32: Support des services et des serveurs L’architecture Client-Serveur.

• Type 4 = Gestion distante des données ;– Les données sont chez le serveur et les applications chez

les clients.– Généralement développé avec une méthode de type RAD

;– Grande fiabilité (expérience) ;– Coût de développement limité et répartition des charges

équilibrés ;– Problème de saturation du réseau si volume de transit

trop important…

• Type 5 = Gestion distribuée des données– Permet la mise en place de BD réparties;– Suppose une répartition du SQBD ;– Inconvénient principal : gestion des erreurs

3 – Client/serveur de données

Source : Cours JP Pujol

Page 33: Support des services et des serveurs L’architecture Client-Serveur.

• Appuient sur les principaux SGBDR (Oracle, Ingres, SQL Server…)

• Les SGBDR se caractérisent par l’utilisation de SQL,

• Existent tous sur de multiple plate-forme ce qui rend leur choix moins dépendent de l’architecture matérielle.

• Les serveurs de BD peuvent travailler en collaboration dans le cadre de BD réparties.

• Tous les principaux serveurs proposent aussi des mécanismes de gestion des copies (la réplication).

• Ils proposent aussi une gestion des transactions avec une journalisation et divers procédés de validation de la transaction.

VI – Les bases de données et le c/sA – les serveurs de BD

Page 34: Support des services et des serveurs L’architecture Client-Serveur.

• Une BD répartie permet de rassembler des ensembles de données plus ou moins hétérogènes, disséminés sur un réseau d’ordinateur sous forme d’une BD globale homogène et intégrée.

• Une BD peut être répartie pour deux raisons :– Des BD existent sur différents sites, elles sont rassemblés à travers une

BD répartie ;– La BD est, dès sa conception, distribuée sur différents sites, en fonction

de la localisation de ses clients potentiels.

B – Les BD réparties

Page 35: Support des services et des serveurs L’architecture Client-Serveur.

• Pour analyser l’architecture globale d’une BD répartie, on distingue les notions suivantes :

• Le schéma local d’une BD locale (description de la BD sur son propre site)

• Le schéma exporté d’une BD locale (description de la vue externe de la BD communiquée aux autres sites clients et serveurs) ;

• Le schéma global (ensemble des vues des schémas exportés) ;• La vue intégré (vue externe du schéma globale visible d’une

application cliente)

Page 36: Support des services et des serveurs L’architecture Client-Serveur.

VI – Le mécanisme transactionnel

Soit la base de données représentait par le schéma suivant :

Hypothèse de départ : Le client existe ;On est dans une architecture client/serveur. La BD sur le serveur

Travail à faire :Saisir une commande dans la table COMMANDESaisir les produits de la commande dans CONTENIR

Evénement :On a créer la commande, le premier produit de la commande Survient un plantage réseaux.

La base de données est incohérente

CLIENT (code, nom, prenom, adresse, telephone)COMMANDE (Code, date, codeClient#)CONTENIR (codeCommande#, codeProduit#, qte)PRODUIT (code, libelle, prix, qteStock)

Page 37: Support des services et des serveurs L’architecture Client-Serveur.

Comment réparer ? Il faut pouvoir revenir en arrière.

Une transaction est un mécanisme assurant qu’un ensemble d’instructions (SQL par exemple) s’exécute totalement ou pas du tout

Qualités du mécanisme transactionnel

Atomicité : la transaction est atomique vis à vis des données (prise en compte totale ou pas du tout) ;

Cohérence : la transaction laisse la base dans un état stable ;

Isolation : une transaction est indépendante des autres traitements en cours ;

Durabilité : l’ensemble des mises à jour d’une transaction résiste aux incidents.

Qualifiée de ACID

C’est le bloc d’instructions SQL délimité par begin transaction et end transaction se termine par commit ou rollback.

Page 38: Support des services et des serveurs L’architecture Client-Serveur.

Comment allons nous faire avec une base de données réparties ?

Hypothèse de départ :Architecture client/serveur;Base de données réparties ;Table COMMANDE sur Nantes – table CONTENIR sur Toulouse

Travail à faire :Saisir une commande dans la table COMMANDE sur NantesSaisir les produits de la commande dans CONTENIR sur Toulouse

Evénement :On a crée la commande sur Nantes normalement donc la

transaction est ok. On a fait notre commit.On a crée un produit de la commande sur Toulouse, puis on a eu un

plantage. Notre transaction ne s’est pas bien passée, on est donc revenu en arrière avec le roolback.

Nos transactions ont eu lieu sans problème. Pas d’incident et pourtant l’état de notre base est incohérent.

Comment faire?

Page 39: Support des services et des serveurs L’architecture Client-Serveur.

Solution : utiliser un serveur de transactions distribuées avec

la technique du commit à deux phases.

Dans notre exemple :Prendre un serveur mettre dessus les transactions

Faire la transaction sur Nantes - AttendreFaire la transaction sur Toulouse - AttendreSi les deux transactions sont valide alors

faire les commit.

Page 40: Support des services et des serveurs L’architecture Client-Serveur.

VII – Architecture c/s à n niveauxJusqu’à présent nous avions un client et un serveur en dialogue : c’est l’architecture à deux niveaux. On peut en mettre plusieurs.

Le modèle le plus représentatif de cette architecture est le client serveurà trois niveaux, basé sur internet ; on utilise un navigateur appelé aussi client universel.

Page 41: Support des services et des serveurs L’architecture Client-Serveur.

Le client serveur à n niveaux marie les technologies du client serveuret de l’internet.

Internet : Ensemble de réseaux, de technologies et de services permettant de communiqueret d’échanger des informations multimédia de façon interactive.

Intranet : Utilisation des technologies de l’internet au sein d’une organisation, donc sur le réseau local de l’entreprise.

Extranet : Utilisation de technologies internet au sein d’un réseau privé interorganisation géographiquement réparti, donc indépendant de l’internet.

Technologies mises en œuvre : Protocole TCP/IP pour le transport ; HTML et ses dérivés ; HTTP : transfert des données ; Serveur web ; Serveur de données.

Avantages : Moindre complexité au niveau client; Simplification de l’architecture Développement simplifié ; Performances augmentée (répartition)

Premier niveauNavigateur HTML avec composants java, javascript, activeX.

Deuxième niveauServeur web enrichi par ASP ou PHP

Troisième niveauServeur de données : SGBD