Une « brève » histoire des SID

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

2. 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 » 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

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

4. 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

5. 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

6. Les familles de CS • C/S de présentation • 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 Stéphane Frenot - Département Télécommunication - SID - stephane.frenot@insa-lyon.fr

7. 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

8. 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

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

10. 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

11. 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

12. 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

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

14. 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

15. 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

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

17. 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

18. 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

19. 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

20. 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

21. Modèle Client-ServeurGestion 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

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

23. 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

24. 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

25. 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

26. 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