une « brève » histoire des sid

Stéphane Frenot - Département Télécommunication - SID - [email protected]

I - Histoire 1

Une « brève » histoire des SID


I - Histoire 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


I - Histoire 3

• Systèmes centralisés– Terminaux caractère

IBM MVS, Unixémulation de terminal

IHM T D


I - Histoire 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 ?


I - Histoire 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 ?


I - Histoire 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


I - Histoire 7

C/S de présentation

• Déporter l'affichage sur un réseau– telnet– Xwindows– NTTerminal Serveur

• Le développement est « presque » centralisé


I - Histoire 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


I - Histoire 9

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 DT


I - Histoire 10

BDde copie

La distribution à "l'ancienne"

Client Proxy

App

App Service A

Service B

BDPrincipale


I - Histoire 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


I - Histoire 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


I - Histoire 13

• 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 DIHM-P


I - Histoire 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é


I - Histoire 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

Client Serveurrequête

réponse

requêtesFile des requêtes

Traitement

Sélection

réponses


I - Histoire 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


I - Histoire 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


I - Histoire 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


I - Histoire 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


I - Histoire 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


I - Histoire 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


I - Histoire 22

Gestion des processus : algorithmes

• 3 formes de base


I - Histoire 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


I - Histoire 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


I - Histoire 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


I - Histoire 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

une « brève » histoire des sid

Documents