Architecture Client/Serveur

PLAN Caractéristiques du client/serveur Évolution des architectures et systèmes informatiques Le modèle client/serveur Caractéristiques du client/serveur Dialogue client/serveur Application Client/Serveur

Évolution des architectures et systèmes informatiques Architecture centralisée Utilisation d'architectures dites « Mainframe ». Dans ce type d'architectures, les composants matériels (tels que les unités de stockage, le(s) processeur(s) (CPU), les lecteurs de bande, etc) étaient centralisés et les utilisateurs équipés de « simple » terminaux. Le hardware représentait une part prépondérante des coûts de fonctionnement d'un système d'information (SI), d'où la nécessité de partager entre un grand nombre d'utilisateurs les ressources les plus coûteuses. Les terminaux n'étaient utilisés qu'afin d'afficher les données, les calculs mais également la préparation de la présentation étaient effectués sur le Host

Évolution des architectures et systèmes informatiques Architecture centralisée

Évolution des architectures et systèmes informatiques Les utilisateurs se connectent aux applications exécutées par le serveur central (le mainframe) à l'aide de terminaux passifs se comportant en esclaves. C'est le serveur central qui prend en charge l'intégralité des traitements, y compris l'affichage qui est simplement déporté sur des terminaux passifs.

Évolution des architectures et systèmes informatiques Les années 70 ont vu naître des systèmes dits «Mini » par opposition à la taille des « Mainframes ». L'avènement de la mini-informatique a permis à des sociétés de taille moyenne, mais également à des départements de sociétés plus importantes qui ne voulaient pas dépendre des priorités informatiques définies à l'échelle de l'entreprise, de s'équiper en IT (Information Technology).

Évolution des architectures et systèmes informatiques Caractéristiques Systèmes propriétaires, un seul OS; Applications monolithiques; Traitements au niveau du Serveur Central; Gros systèmes mêlant interfaces, règles métiers (logique applicative) et données; Terminaux passifs; Avantages Facilité d'administration; Performance : la centralisation de la puissance sur une seule et même machine permet une utilisation optimale des ressources et se prête très bien aux traitements par lots . Sécurité et fiabilité;

Évolution des architectures et systèmes informatiques Inconvénients Interface utilisateur en mode caractère peu convivial; Systèmes non ouverts vers d'autres, dépendance d'un fabricant particulier. Maintenance logicielle peu aisée et délicate, et donc un coût très élevé pour la maintenance logicielle. Problèmes de compatibilité : les « Hosts » (ou les «Minis»), non contents d'être incompatibles d'un constructeurs à un autre, ils n'étaient parfois pas compatibles dans la gamme d'un même constructeur. Le simple passage d'un modèle à un autre au sein du même constructeur impliquait souvent une réécriture des applications.

Évolution des architectures et systèmes informatiques Système répartis - Architecture réparties Introduction L'avènement de la micro-informatique. Les réseaux d'ordinateurs sont partout ! Internet, réseaux de téléphones mobiles, réseaux locaux, etc. Les progrès technologiques des ordinateurs et le haut débit permettent aux différentes applications sur des ordinateurs distincts de coopérer pour effectuer des tâches coordonnées. Avant les années 80, les systèmes étaient encombrants et chers ( les systèmes centralisés). A partir de la mi-80, de nouveautés : (i) Microprocesseurs (moins chers et très rapides); (ii) LANs et WANs. Les ordinateurs en réseaux non seulement faisable, mais simple aussi (standardisation)

Évolution des architectures et systèmes informatiques Downsizing Passage d’un environnement centralisé à un environnement décentralisé.

Évolution des architectures et systèmes informatiques Évolution technologique (banalisation matérielle, bon rapport coût/performances). Évolution des besoins structure des entreprises et des organisations : répartition géographique et fonctionnelle -> besoin d'adapter la structure d'un système à celles des applications. besoin de communication et de partage d'information. besoin d'intégration (applications existantes). besoin en partage de ressources (programmes, données, services). besoin de systèmes à grande capacité d'évolution.

Évolution des architectures et systèmes informatiques Définitions Un système réparti (SR) « Distributed System (DS) » se compose d'un ensemble d'ordinateurs reliés par un réseau informatique et équipés d'un logiciel réparti. Le logiciel d'un SR permet à des ordinateurs de coordonner leurs activités et de partager les ressources du système : équipements, logiciels et données. Définition [Tanenbaum] : " Un ensemble d'ordinateurs indépendants qui apparaît à un utilisateur comme un système unique et cohérent. " Les machines sont autonomes. Les utilisateurs ont l'impression d'utiliser un seul système.

Évolution des architectures et systèmes informatiques Propriétés, caractéristiques Partage de ressources Mise à l'échelle « scalable » Concurrence « concurrent access » Transparence « transparency » Ouverture « open system » Tolérance aux pannes « fault-tolerant » Fiabilité Performances

Évolution des architectures et systèmes informatiques Partage de ressources : Partage de ressources matérielles et logicielles. Chaque ressource est gérée par un gestionnaire de ressources (RM) «resource management » (SGBD=Système de Gestion de Base de Données, «DBMS Database Management systems») Mise à l'échelle : Fonctionner efficacement dans différentes échelles (de quelques postes et serveur(s) à plusieurs centaines de postes de travail et de serveurs, à plusieurs réseaux locaux reliés par Internet).

Évolution des architectures et systèmes informatiques Concurrence : Plusieurs processus s'exécutant en parallèle (ou peuvent s'exécuter en parallèle). Concurrence d'accès aux ressources (possibilité de plusieurs accès à un même objet, même fichier, même table d'une base de données, ...) Transparence : Transparence de données, d'emplacement, ... (Masquer la répartition) La notion de transparence correspond à la possibilité d'accéder à un service ou une donnée indépendamment de certaines propriétés liées à la distribution. Cette notion de transparence présente différents aspects :

Évolution des architectures et systèmes informatiques Uniformité des accès : correspond à la possibilité d'accéder à une ressource par une interface unique que cette ressource soit locale ou distante (la séparation physique entre machines et les différences matériels/logiciels pour les accès sont invisibles par l'utilisateur). Localisation : exprime la possibilité d'accéder à une ressource sans en connaître la localisation (localisation des ressources non perceptible). Réplication : permet d'accéder à des exemplaires multiples de ressources sans en connaître l'existence à des fins de performances et/ou de fiabilité; Concurrence : correspond à la possibilité pour plusieurs processus d'accéder "simultanément" à une même ressource sans que ces accès n'interfèrent entre eux.

Évolution des architectures et systèmes informatiques Mobilité / Migration: autorise la mobilité (ou migration) d'objets (ressources ou processus) sans affecter le déroulement des opérations en cours (sans modification de leurs noms, de la manière d'y accéder et de l'environnement d'un utilisateur). Défaillance: correspond au masquage des pannes de sites ou d'inaccessibilité des objets jusqu'au recouvrement de l'erreur correspondante.

Évolution des architectures et systèmes informatiques Ouverture : Permettre l'ajout d'autres composantes logicielles ou matérielles sans remettre en cause le fonctionnement du système. Services offerts selon des règles standards qui décrivent la syntaxe et la sémantique de ces services (Interfaces publiées (IDL), API's standards). Interopérabilité des matériels (de fournisseurs différents). Portabilité. Flexibilité (facilité d'utilisation et de configuration). Extensibilité (Ajout/MAJ de composants sans en affecter les autres).

Évolution des architectures et systèmes informatiques Tolérance aux pannes : Cas de pannes détectés et récupérés. Redondances (ex. réplication) matérielles et logicielles. Permettre à un utilisateur/programme de ne pas s'interrompre (ou même se rendre compte) à cause d'une panne d'une ressource. L'idée est que si un composant tombe en panne, le système continuera d'être accessible, contrairement à ce qui se passe dans un système centralisé classique. La tolérance aux pannes est un champ d'étude important du domaine des systèmes répartis.

Évolution des architectures et systèmes informatiques Fiabilité : Un des buts recherchés est d'améliorer la disponibilité du système et donc d'offrir un service plus fiable. C’est la Probabilité (%) de tomber en panne ou de ne pas avoir accès. Performances : Un système réparti peut offrir la possibilité de distribuer les traitements sur plusieurs machines ou de permettre l'exécution d'une application sur un serveur adapté à ses besoins (soit par exemple qu'il soit peut chargé ou que l'espace disponible en mémoire y soit plus adapté aux besoins de l'application)

Évolution des architectures et systèmes informatiques En conclusion, systèmes répartis : Avantages : L'hétérogénéité : plusieurs machines de nature différente peuvent être reliées via un même médium de communication et ainsi pouvoir échanger de l'information. La croissance modulaire : la configuration d'une architecture distribuée peut croître en fonction des besoins réels des utilisateurs. Une plus grande disponibilité : un élément défaillant d'une architecture peut être mis hors service sans entraîner un arrêt complet du système. Les traitements effectués par cet élément défaillant peuvent être éventuellement repris sur une autre machine de l'architecture distribuée.

Évolution des architectures et systèmes informatiques Inconvénients : les inconvénients liés à l'utilisation des systèmes distribués résultent principalement de l'absence d'un état global observable. Le partage d'informations : difficulté due à l'absence de mémoire commune. Le partage s'implante donc par des échanges explicites de messages entre les diverses entités communicantes. Ces difficultés s'amplifient lorsque pour des raisons d'efficacité d'accès, les données sont répliquées sur plusieurs machines. Dans ce cas leur mise à jour doit se faire de manière cohérente. L'administration du système : la difficulté de l'administration d'un SR provient de la nécessité de gérer simultanément plusieurs machines qui sont à priori localisées sur des sites répartis géographiquement.

Évolution des architectures et systèmes informatiques Inconvénients : Aussi, l'administration qui, dans le cas des systèmes centralisés, était du ressort du personnel spécialisé dans ce type d'activité, est maintenant assurée par l'ensemble des utilisateurs du système ce qui ne va pas sans poser des problèmes dans la cohérence des décisions prise : sauvegarde de fichiers, retraits ou ajouts de machines, ...

Évolution des architectures et systèmes informatiques Après un rappel sur l'évolution des architectures et systèmes informatiques, ainsi que sur les avantages et inconvénients des systèmes centralisés et distribués, une conclusion s'impose : ce qu'aimerait les utilisateurs c'est de bénéficier simultanément des avantages des systèmes centralisés et des systèmes distribués, sans leurs inconvénients. le modèle Client-Serveur. L’hétérogénéité La croissance modulaire Grande disponibilité Facilité d’administration, Performance, Sécurité et fiabilité.

Le modèle client/serveur Définition 1 : Clients et Serveurs sont des entités distinctes fonctionnant de concert sur un réseaux pour accomplir une tâche Réseau pas vraiment nécessaire clients et serveurs « locaux » Définition 2 : Modèle d’architecture applicative où les programmes sont répartis entre processus clients et serveurs communiquant par des requêtes avec réponses

Le modèle client/serveur

Le modèle client/serveur Idée : l'application est répartie sur différents sites pour optimiser le traitement, le stockage... Le client effectue une demande de service auprès du serveur (requête) initie le contact (parle en premier), ouvre la session Le serveur est la partie de l'application qui offre un service est à l'écoute des requêtes clientes répond au service demandé par le client (réponse)

Le modèle client/serveur Le client et le serveur ne sont pas identiques, ils forment un système coopératif les parties client et serveur de l'application peuvent s'exécuter sur des systèmes différents une même machine peut implanter les côtés client ET serveur de l'application un serveur peut répondre à plusieurs clients simultanément

Le modèle client/serveur Communication entre processus deux à deux: un client, un serveur; Ces processus forment un système coopératif: le client réceptionne les résultats finaux délivrés par le serveur. Requête Client Serveur Réponse Application Service Modèle client/serveur ==> répartition des services plutôt que l’application elle-même.

Le modèle client/serveur Fonctionnement Communication réalisée par un dialogue entre un processus client et un processus serveur (Session). Le client émet des requêtes et reçoit les réponses du serveur. Le serveur reçoit les requêtes, les traite et émet les réponses aux clients correspondants.

Caractéristiques du client/serveur le service les ressources partagées les protocoles asymétriques la transparence la compatibilité le faible couplage l’encapsulation des services l’adaptabilité

Caractéristiques du client/serveur le service : C’est le travail fourni par le serveur suite à la requête du client. Le client est donc consommateur et le serveur fournisseur de services. les ressources partagées : le serveur est capable de servir de nombreux clients simultanément et réguler leur accès. les protocoles asymétriques : Ce protocole permet de nombreux clients demandent un service à un serveur qui attend leurs requêtes.

Caractéristiques du client/serveur la transparence : le serveur peut résider ou non sur la même machine que le client, sans différence pour ce dernier. la compatibilité : l’application Client ou Serveur est indépendante du matériel. le faible couplage : le client et le serveur communiquent uniquement par envoi de messages

Caractéristiques du client/serveur l’encapsulation des services : le serveur choisit la manière dont il réalise le service demandé; le client se borne à définir ce qu’il désire obtenir. Ainsi l’implémentation du serveur peut être changé sans préoccuper le client. l’adaptabilité : des machines peuvent être ajoutées ou retirées du réseau; les performances des machines peuvent aussi évoluer.

Dialogue client/serveur Application Serveur Opération Requête Réponse

Dialogue client/serveur Définition : Processus demandant l’exécution d’une opération à un autre processus par envoi d’un message contenant le descriptif de l’opération à exécuter, et attendant la réponse à cette opération par un message en retour.

Dialogue client/serveur Définition : Processus accomplissant une opération sur demande d’un client, et transmettant la réponse à ce client.

Dialogue client/serveur Requête Définition : Message transmis par un client à un serveur décrivant l’opération à exécuter pour le compte du client

Dialogue client/serveur Réponse Définition : Message transmis par un serveur à un client suite à l’exécution d’une opération contenant les paramètres de retour de l’opération

Application Client/Serveur Une application Client/Serveur, c'est une partie cliente qui exécute des requêtes vers un serveur une partie serveur qui traite les requêtes clientes et y répond un protocole applicatif qui définit les échanges entre un client et un serveur un accès via une API (interface de programmation) à la couche de transport des messages Bien souvent les parties cliente et serveur ne sont pas écrites par les mêmes programmeurs (Navigateur Netscape/Serveur apache) --> rôle important des RFCs qui spécifient le protocole!

Application Client/Serveur

Application Client/Serveur

Application Client/Serveur Utilisation du modèle s’étend de plus en plus vers tous les domaines d’activités : Gestion des bases de données, Systèmes transactionnels, Systèmes de messagerie, Web, Intranet, Systèmes de partage des données, Calcul scientifique ...

Application Client/Serveur Exemple d'application client/serveur DAYTIME (RFC 867, « request for comments » ) permet au client d'obtenir la date et l'heure du serveur Le protocole spécifie l'échange des messages : dès qu'un serveur reçoit un message d'un client, il renvoie une chaîne de caractères contenant la date et l'heure le contenu du message client n'est même pas regardé le format de la chaîne renvoyée : 1 ligne ASCII Par exemple "Weekday, Month Day, Year Time-Zone " « Friday, Octobre 31, 2009 10:12:43-PST "

Application Client/Serveur Serveurs de fichiers Les appels sur le réseau concernent les opérations de lecture -écriture des fichiers. Aucun filtrage n ’est effectué sur les données échangées.

Application Client/Serveur Serveurs de bases de données Les données reçues par l’application sont le résultat de l’exécution de requêtes SQL. Cette exécution se fait par le serveur de la SGBD.