Une «brève» histoire des sid l'Histoire Le système centralisé (70)
tarix 11.12.2017 ölçüsü 445 b. #34525
L'Histoire Le système centralisé (70) Calcul Consoles de connexion Liaison série Le client/serveur de présentation (80) Gestion de données simples Distribution des données Emulation de terminaux Réseau propriétaires Le client/serveur de traitement(90) Gestion interactive des données Clients graphiques Réseaux locaux « Fat Client » Systèmes centralisés Terminaux caractère IBM MVS, Unix émulation de terminal Architecture centralisée Composants localisés sur un site unique Centralisation des données, des traitements et de la présentation Historiquement sur systèmes propriétaires Terminaux légers Coûts ? Peut on réaliser une application centralisée sur NT ? Pourquoi les premières applications étaient centralisées ? Quels sont les problèmes des application centralisées ?
Les familles de CS C/S de présentation Client : gestion de la présentation Serveur : réalisation de l'ensemble des traitements C : Gestion de la présentation + traitements applicatifs S : Gestion de l'accès aux BD C/S multi-tiers C : Gestion de la présentation Serveur applicatif : Connaissance des traitements métiers Serveurs : gestion des accès aux BD C/S de présentation Déporter l'affichage sur un réseau telnet Xwindows NTTerminal Serveur Le développement est « presque » centralisé Client-serveur 2 niveaux (2-tier) Le poste de travail héberge l ’ensemble de la gestion d’interface homme-machine et le traitement, Le serveur est un serveur de base de données Architecture dénommée « client obèse » Architecture informatique Client-serveur 3 niveaux (3-tier) Le poste de travail héberge la gestion d'interface homme-machine et une partie des traitements, Le serveur d ’applications gère l'autre partie des traitements Le serveur de données gère les accès aux données Architecture dénommée "traitements coopératifs" La distribution à "l'ancienne"
Elle nécessite des compétences humaines Connaissances des systèmes propriétaires Des compétences précises sur : Gestion de transactions Définition de queues de messages Réplication et Synchronisation de BD Gestion des pannes Sécurité des communications Développement de clients Elle pose des problèmes techniques Nécessite de nombreux serveurs pour l'équilibrage de charge Nécessite une programmation complexe pour pouvoir évoluer L'ajout de nouvelles fonctionnalités pose de réels problèmes Client-serveur 4 ou n niveaux (4-tier, n-tier) Le poste de travail héberge un navigateur standard , Le serveur HTTP gère la partie présentation de l'interface homme-machine Le serveur d’applications gère les traitements Le serveur de données gère les accès aux données Architecture de collaboration Caractéristiques du modèle client-serveur Notion de service Communication par messages Requête : paramètre d'appel, spécification du service requis Réponse : résultat, indicateur d'execution/d'erreur Synchrone Structuré, Protégé (espaces d'exécution distincts), partagé Modèle client/serveur : partage Vu du client Vu du serveur Gestion des requêtes (priorité) Exécution du service (séquentielle, concurrent) Mémorisation ou non l'état du client Modèle Client-Serveur Mise en œuvre Gestion de l'état Etat du serveur (persistant ou non) Etat du client (mémorisé ou non par le serveur) Utilisation d'un service de communication par messages Gestion de l'exécution sur le serveur Serveur sans données rémanentes La requête est autonome Pas de modification persistante sur le serveur Solution facile Pour la tolérance aux pannes Pour la concurrence Exemple Serveur avec données rémanentes Les requêtes manipulent des données persistantes Exemple Serveur sans état (stateless) Le serveur ne mémorise pas d'informations d'état relatives aux opérations en cours Les appels successifs sont indépendants Pas de relations de causalité entre les requêtes L'ordre des requêtes peut ne pas être préservé (pour le serveur) Exemple Serveur avec état (stateful) Les appels successifs s'exécutent en fonction d'un état laissé par les appels antérieurs La préservation de l'ordre est indispensable Exemples Modèle Client-Serveur Gestion des processus Client et serveur exécutent des processus distincts le client est suspendu (appel synchrone) éventuellement plusieurs requêtes peuvent être traitées curremment par le serveur parallélisme réel (multiprocesseur) pseudo-parallélisme La concurrence peut prendre plusieurs formes plusieurs processus plusieurs processus légers dans le même espace virtuel Gestion des processus : algorithmes
Mise en œuvre du schéma C/S Par des opérations de "bas niveau" Utilisation des primitives du SE Par des opérations de "haut niveau » Utilisation d'un "middleware" Contexte : langage de programmation Appels de procédures à distance Contexte : objets répartis Appels de méthodes, création d'objets à distance Le Client / Serveur Avantages Mise en œuvre rapide Efficace pour un nombre réduit de clients Première infrastructure informatique pour un travail coopératif Centralisation des traitements au niveau du serveur Pas de duplication des données (état global observable) Gestion plus simple de la cohérence et de l'intégrité des données Maîtrise globale des processus (workflow) relativement élémentaire Le Client / Serveur inconvénients Relation directe C/S Pas de transparence sur la localisation Modèle rigide et figé en deux activités ? Augmentation de l'hétérogénéité Ni portable ni interopérable Coût de déploiement et de MAJ exponentiels Gestion des accès concurrents Hétérogénéité sur les bases de données Les outils techniques du système d'information Les bases de données Structuration du stockage et de l'interrogation de l'information Oracle, Informix, DB2 Les moniteurs transactionnel Les Middleware Orientés Messages Communication des applications TopEnd, MQSeries Les serveurs d'applications EJB / CORBA /DCOM Weblogic, WebSphere Dostları ilə paylaş:
