Une « brève » histoire des SID Stéphane Frenot - Département Télécommunication - SID - stephane.frenot@insa-lyon.fr

L'Histoire Le système centralisé (70) Le Web (95) (C/S multi-tiers) 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 » Le Web (95) (C/S multi-tiers) Approche information Clients documentaires Réseau Internet Les objets distribués (00) Approche métiers Clients hétérogènes / MV Réseau haut-débits Le code mobile (05) Approche dynamique Collaboration de machines Réseaux intelligents et actifs Stéphane Frenot - Département Télécommunication - SID - stephane.frenot@insa-lyon.fr

Systèmes centralisés Terminaux caractère IBM MVS, Unix émulation de terminal IHM T D Stéphane Frenot - Département Télécommunication - SID - stephane.frenot@insa-lyon.fr

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 ? Stéphane Frenot - Département Télécommunication - SID - stephane.frenot@insa-lyon.fr

Peut on réaliser une application centralisée sur NT 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 ? Stéphane Frenot - Département Télécommunication - SID - stephane.frenot@insa-lyon.fr

Les familles de CS C/S de présentation C/S de traitement Client : gestion de la présentation Serveur : réalisation de l'ensemble des traitements C/S de traitement 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 X11 Procédures Stockées / Forms Stéphane Frenot - Département Télécommunication - SID - stephane.frenot@insa-lyon.fr

C/S de présentation Déporter l'affichage sur un réseau telnet Xwindows NTTerminal Serveur Le développement est « presque » centralisé Stéphane Frenot - Département Télécommunication - SID - stephane.frenot@insa-lyon.fr

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 » IHM T D Stéphane Frenot - Département Télécommunication - SID - stephane.frenot@insa-lyon.fr

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" IHM T D Stéphane Frenot - Département Télécommunication - SID - stephane.frenot@insa-lyon.fr

La distribution à "l'ancienne" App BD Principale Proxy Client BD de copie Service A App Service B Stéphane Frenot - Département Télécommunication - SID - stephane.frenot@insa-lyon.fr

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 Stéphane Frenot - Département Télécommunication - SID - stephane.frenot@insa-lyon.fr

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 Stéphane Frenot - Département Télécommunication - SID - stephane.frenot@insa-lyon.fr

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 IHM-D T D IHM-P Stéphane Frenot - Département Télécommunication - SID - stephane.frenot@insa-lyon.fr

Caractéristiques du modèle client-serveur Notion de service réalisé par un serveur demandé par un client définie par une interface (API) entre client et serveur 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é Stéphane Frenot - Département Télécommunication - SID - stephane.frenot@insa-lyon.fr

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 requête Client Serveur réponse Sélection requêtes Traitement réponses File des requêtes Stéphane Frenot - Département Télécommunication - SID - stephane.frenot@insa-lyon.fr

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 un ou plusieurs processus pool fixe ou création à la demande TCP/UDP Stéphane Frenot - Département Télécommunication - SID - stephane.frenot@insa-lyon.fr

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 Stéphane Frenot - Département Télécommunication - SID - stephane.frenot@insa-lyon.fr

Serveur avec données rémanentes Les requêtes manipulent des données persistantes Modification du contexte d'exécution Problème de la concurrence Problème de reprise de panne Exemple Stéphane Frenot - Département Télécommunication - SID - stephane.frenot@insa-lyon.fr

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 Stéphane Frenot - Département Télécommunication - SID - stephane.frenot@insa-lyon.fr

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 Stéphane Frenot - Département Télécommunication - SID - stephane.frenot@insa-lyon.fr

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 Stéphane Frenot - Département Télécommunication - SID - stephane.frenot@insa-lyon.fr

Gestion des processus : algorithmes 3 formes de base Stéphane Frenot - Département Télécommunication - SID - stephane.frenot@insa-lyon.fr

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 Stéphane Frenot - Département Télécommunication - SID - stephane.frenot@insa-lyon.fr

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 Stéphane Frenot - Département Télécommunication - SID - stephane.frenot@insa-lyon.fr

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 Stéphane Frenot - Département Télécommunication - SID - stephane.frenot@insa-lyon.fr

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 Découpage d'une application en transactions Gestion de la charge utilisateur Tuxedo, CISC Les Middleware Orientés Messages Communication des applications TopEnd, MQSeries Les serveurs d'applications EJB / CORBA /DCOM Weblogic, WebSphere Stéphane Frenot - Département Télécommunication - SID - stephane.frenot@insa-lyon.fr