L'architecture client-serveur : L'architecture 2 et 3 et n tiers - middleware - les bases de données SGBD client-serveur

1-  Introduction 

2-  L'architecture client-serveur

      

      2.1-  Définition

      2.2-  Les principes généraux

      2.3-  La répartition des tâches

      2.4-  Les différents modèles  de client-serveur

            2.4.1    Le client-serveur de données.

            2.4.2    Client-serveur de présentation

            2.4.3    Le client-serveur de traitement

            2.4.4    Une synthèse des différents cas

      2.5-  Les différentes architectures

            2.5.1    L'architecture 2 tiers

            2.5.2    L'architecture 3 tiers

            2.5.3    L'architecture n-tiers

      2.6-  Les middleware

            2.6.1    Présentation

            2.6.2    Les services des middlewares

            2.6.3    Exemples de Middleware

            2.6.4    Les Middleware objet

3-  Le cas de l'Internet

 

      3.1-  Répartition des tâches

      3.2-  Le client universel

      3.3-  Les technologies coté client ou serveur

      3.4-  Le futur

  

1 Introduction 

 

Ces vingt  dernières années ont  vues une  évolution  majeure  des systèmes d'information,  à savoir le passage d'une architecture centralisée à travers de grosses machines (des Mainframe) vers une architecture distribuée basée sur l'utilisation de serveurs et de postes clients grâce à l'utilisation des PC et des réseaux. 

Cette évolution a été possible essentiellement grâce à 2 facteurs qui sont :

 

• la baisse des prix de l'informatique personnelle 

• le développement des réseaux. 

 

2  L'architecture client-serveur

 

2.1  Définition 

L'architecture  client-serveur est  un  modèle  de  fonctionnement  logiciel  qui  peut  se réaliser sur tout  type  d'architecture  matérielle  (petites  ou  grosses  machines),  à  partir du moment ou ces architectures peuvent être interconnectées. 

On parle de fonctionnement logiciel dans la mesure où cette architecture est basée sur l'utilisation  de  deux  types  de  logiciels,  à  savoir un  logiciel  serveur et  un  logiciel  client s'exécutant  normalement  sur  2  machines  différentes.  L'élément  important  dans  cette architecture est l'utilisation de mécanismes de communication entre les 2 applications. 

Le dialogue entre les applications peut se résumer par :

 

• Le client demande un service au serveur 

• Le serveur réalise ce service et renvoie le résultat au client

 

  

Un des principes fondamental est que le serveur réalise un traitement pour le client. 

2.2  Les principes généraux 

Il  n'y a pas véritablement  de définition  exhaustive de la notion  de client-serveur,  néanmoins des principes régissent ce que l'on entend par client-serveur :

• Service.

Le serveur est fournisseur de services. Le client est consommateur de services.  

• Protocole.

C'est  toujours  le  client  qui  déclenche  la  demande  de  service.  Le  serveur  attend passivement les requêtes des clients.  

• Partage des ressources.

Un  serveur  traite  plusieurs  clients  en  même  temps  et  contrôle  leurs  accès  aux ressources.  

• Localisation.

Le logiciel client-serveur masque aux clients la localisation du serveur. 

• Hétérogénéité.

Le logiciel client-serveur est indépendant des plate-formes matérielles et logicielles. 

• Redimensionnement.

Il est possible d'ajouter et de retirer des stations clientes. Il est possible de faire évoluer les serveurs. 

• Intégrité.

Les données du  serveur sont  gérées sur le serveur de façon  centralisée.  Les clients restent individuels et indépendants. 

• Souplesse et adaptabilité.

On peut modifier le module serveur sans toucher au module client. La réciproque est vraie.  Si  une station  est  remplacée par un  modèle plus récent,  on  modifie le module client (en améliorant l'interface, par exemple) sans modifier le module serveur.

2.3   La répartition des tâches 

Dans l'architecture client-serveur, une application est constituée de trois parties :

• l'interface utilisateur

• la logique des traitements

• la gestion des données. 

Le client  n'exécute que l'interface utilisateur (souvent  un  interfaces graphique) ainsi  que la logique  des traitements (formuler la  requête),  laissant  au  serveur de  bases de  données la gestion complète des manipulations de données. 

La liaison  entre le client  et  le serveur correspond  à tout  un  ensemble complexe de logiciels appelé middleware qui se charge de toutes les communications entre les processus. 

2.4  Les différents modèles  de client-serveur 

En fait, les différences sont essentiellement liées aux services qui sont assurés par le serveur.

On distingue couramment :

2.4.1 Le client-serveur de donnée.

Dans ce  cas,  le  serveur assure  des tâches de  gestion,  stockage  et  de  traitement  de données.  C'est  le cas le plus connu  de client-serveur est  qui  est  utilisé par tous les grands SGBD :

La base de données avec tous ses outils (maintenance, sauvegarde …) est installée sur un poste serveur. 

Sur les clients, un logiciel d'accès est installé permettant d'accéder à la base de données du serveur. 

Tous les traitements sur  les données sont  effectués sur le  serveur qui  renvoie  les informations demandées (souvent à travers une requête SQL) par le client 

2.4.2 Client-serveur de présentation

Dans ce cas la présentation des pages affichées par le client est intégralement prise en charge  par le  serveur.  Cette  organisation  présente  l'inconvénient  de  générer un  fort  trafic réseau. 

2.4.3 Le client-serveur de traitement 

Dans ce cas, le serveur effectue des traitements à la demande du client. Il peut s'agir de traitement particulier sur des données, de vérification de formulaires de saisie, de traitements d'alarmes … 

Ces traitements peuvent  être  réalisés par des programmes installé  sur des serveurs mais également  intégrés dans des bases de données (triggers,  procédures stockées),  dans ce cas, la partie donnée et traitement sont intégrés. 

2.4.4 Une synthèse des différents cas 

Cette synthèse s'illustre par un schéma du Gartner Group qui représente les différents modèles ainsi que la répartition des tâches entre serveur et client.

 

 

Sur ce schéma, le trait horizontal représente le réseau et les flèches entre client et serveur, le trafic réseau généré par la conversation entre client et serveur. 

Nous verrons par la suite que la vision  du  Gartner Group,  en  ne prenant  en  compte qu'un découpage en deux niveaux, est quelque peu limitatif.  

Le Gartner Group distingue les types de client-serveur suivants, en fonction du type de service déporté du cœur de l'application :

1. Présentation  distribuée : Correspond  à  l'habillage  ``graphique' de  l'affichage  en mode caractères d'applications fonctionnant  sur site central.  Cette solution  est  aussi appelée revamping. La classification ``client-serveur' du revamping est souvent jugée abusive, du fait que l'intégralité des traitements originaux est conservée et que le poste client conserve une position d'esclave par rapport au serveur. 

2. Présentation distante : Encore appelée client-serveur de présentation. L'ensemble des traitements est exécuté par le serveur, le client ne prend en charge que l'affichage. Ce type  d'application  présentait  jusqu'à  présent  l'inconvénient  de  générer un  fort  trafic réseau et de ne permettre aucune répartition de la charge entre client et serveur. 

S'il n'était que rarement retenu dans sa forme primitive, il connaît aujourd'hui un très fort regain d'intérêt avec l'exploitation des standards Internet. 

3. Gestion distante des données : Correspond au client-serveur de données, sans doute le type de client-serveur le plus répandu. L'application fonctionne dans sa totalité sur le client,  la gestion  des données et  le contrôle de leur intégrité sont  assurés par un SGBD centralisé. 

Cette architecture, de part sa souplesse, s'adapte très bien aux applications de type info centre,  interrogeant  la base de façon  ponctuelle.  Il  génère toutefois un  trafic réseau assez important  et  ne soulage pas énormément  le poste client,  qui  réalise encore la grande majorité des traitements. 

4. Traitement distribué : Correspond au client-serveur de traitements. Le découpage de l'application se fait ici au plus près de son noyau et les traitements sont distribués entre le client et le(s) serveur(s).

Le  client-serveur de  traitements s'appuie,  soit  un  mécanisme  d'appel  de  procédure distante, soit sur la notion de procédure stockée proposée par les principaux SGBD du marché. 

Cette architecture permet  d'optimiser la répartition  de la charge de traitement  entre machines et limite le trafic réseau. Par contre il n'offre pas la même souplesse que le client-serveur de  données puisque les traitements doivent  être  connus du  serveur à l'avance. 

5. Bases de  données distribuées : Il  s'agit  d'une variante du client-serveur de données dans laquelle une partie de données est  prise en  charge par le client.  Ce modèle est intéressant  si  l'application  doit  gérer de  gros volumes de  données,  si  l'on  souhaite disposer de temps d'accès très rapides sur certaines données ou  pour répondre à de fortes contraintes de confidentialité. 

Ce modèle est aussi puissant que complexe à mettre en œuvre. 

6. Données et traitements distribués.  Ce modèle est  très puissant  et  tire partie de la notion  de composants réutilisables et  distribuables pour répartir au  mieux  la charge entre client et serveur. 

C'est, bien entendu, l'architecture la plus complexe à mettre en œuvre. 

2.5       Les différentes architectures 

2.5.1 L'architecture 2 tiers 

Dans une architecture deux tiers, encore appelée client-serveur de première génération ou client-serveur de données, le poste client se contente de déléguer la gestion des données à un  service  spécialisé.  Le  cas typique  de  cette  architecture  est  une  application  de  gestion fonctionnant sous Windows ou Linux et exploitant un SGBD centralisé.

Ce type d'application permet de tirer partie de la puissance des ordinateurs déployés en réseau pour fournir à l'utilisateur une interface riche, tout en garantissant la cohérence des données, qui restent gérées de façon centralisée. 

La  gestion  des  données est  prise  en  charge  par un  SGBD  centralisé,  s'exécutant  le  plus souvent sur un serveur dédié. Ce dernier est interrogé en utilisant un langage de requête qui, plus souvent, est SQL. Le dialogue entre client et serveur se résume donc à l'envoi de requêtes et au retour des données correspondant aux requêtes.

  

 

Cet échange de messages transite à travers le réseau reliant les deux machines. Il met en œuvre des mécanismes relativement complexes qui sont, en général, pris en charge par un middleware.

L'expérience a démontré qu'il était coûteux et contraignant de vouloir faire porter l'ensemble des traitements applicatifs par le poste client. On en arrive aujourd'hui à ce que l'on appelle le client lourd, avec un certain nombre d'inconvénients : 

• On ne peut pas soulager la charge du poste client, qui supporte la grande majorité des traitements applicatifs,

• Le poste client est fortement sollicité, il devient de plus en plus complexe et doit être mis à jour régulièrement pour répondre aux besoins des utilisateurs,

• Les applications se prêtent assez mal aux fortes montées en charge car il est difficile de modifier l'architecture initiale,

• La relation  étroite qui  existe entre le programme client  et  l'organisation  de la partie serveur complique les évolutions de cette dernière,

• Ce  type  d'architecture  est  grandement  rigidifié  par les coûts et  la  complexité  de  sa maintenance. 

Malgré tout,  l'architecture deux  tiers présente de nombreux  avantages qui  lui  permettent  de présenter un bilan globalement positif :

• Elle permet l'utilisation d'une interface utilisateur riche,

• Elle a permis l'appropriation des applications par l'utilisateur,

• Elle a introduit la notion d'interopérabilité. 

Pour résoudre les limitations du client-serveur deux tiers tout en conservant ses avantages, on a cherché une architecture plus évoluée,  facilitant  les forts déploiements à moindre coût.  La réponse est apportée par les architectures distribuées. 

2.5.2 L'architecture 3 tiers 

Les limites de l'architecture deux  tiers proviennent  en  grande partie de la nature du  client utilisé :

• le frontal est complexe et non standard (même s'il s'agit presque toujours d'un PC sous Windows),

• le middleware entre client et serveur n'est pas standard (dépend de la plate-forme, du SGBD …). 

La solution  résiderait  donc dans l'utilisation  d'un  poste client  simple communicant  avec le serveur par le biais d'un protocole standard. 

Dans ce but, l'architecture trois tiers applique les principes suivants :

 

• Les données sont toujours gérées de façon centralisée,

• La présentation est toujours prise en charge par le poste client,

• La logique applicative est prise en charge par un serveur intermédiaire. 

Cette architecture trois tiers,  également  appelée client-serveur de deuxième génération    ou client-serveur distribué sépare l'application  en  3  niveaux de services distincts,  conformes au principe précédent :

• Premier  niveau : l'affichage et  les traitements locaux  (contrôles de saisie,  mise en forme de données...) sont pris en charge par le poste client,

• Deuxième  niveau :  les  traitements applicatifs globaux  sont  pris  en  charge  par le service applicatif,

• Troisième niveau : les services de base de données sont pris en charge par un SGBD.

 

 

Tous ces niveaux étant indépendants, ils peuvent être implantés sur des machines différentes, de ce fait :

• Le poste client ne supporte plus l'ensemble des traitements, il est moins sollicité et peut être moins évolué, donc moins coûteux,

• Les ressources présentes sur le réseau  sont  mieux  exploitées,  puisque les traitements applicatifs peuvent être partagés ou regroupés (le serveur d'application peut s'exécuter sur la même machine que le SGBD),

• La fiabilité et les performances de certains traitements se trouvent améliorées par leur centralisation,

• Il est relativement simple de faire face à une forte montée en charge, en renforçant le service applicatif. 

Dans l'architecture trois tiers,  le poste client  est  communément  appelé client  léger ou  Thin Client, par opposition au client lourd des architectures deux tiers. Il ne prend en charge que la présentation  de  l'application  avec,  éventuellement,  une  partie  de  logique  applicative permettant une vérification immédiate de la saisie et la mise en forme des données.

le  serveur de traitement  constitue la pierre angulaire de l'architecture et  se trouve  souvent fortement sollicité. Dans ce type d'architecture, il est difficile de répartir la charge entre client et  serveur.  On  se retrouve confronté aux épineux problèmes de dimensionnement  serveur et de gestion de la montée en charge rappelant l'époque des mainframes. 

De plus, les solutions mises en œuvre sont relativement complexes à maintenir et la gestion des sessions est compliquée. 

Les contraintes semblent inversées par rapport à celles rencontrées avec les architectures deux tiers : le client est soulagé, mais le serveur est fortement sollicité.

2.5.3 L'architecture n-tiers

L'architecture n-tiers a été pensée pour pallier aux  limitations des architectures trois tiers et  concevoir des applications puissantes et  simples à maintenir.  Ce type d'architecture permet  de distribuer plus librement  la logique applicative,  ce qui  facilite la répartition  de la charge entre tous les niveaux. 

Cette évolution des architectures trois tiers met en œuvre une approche objet pour offrir une plus grande souplesse d'implémentation et faciliter la réutilisation des développements. 

Théoriquement,  ce  type  d'architecture  supprime  tous  les  inconvénients  des  architectures précédentes :

• Elle permet l'utilisation d'interfaces utilisateurs riches,

• Elle sépare nettement tous les niveaux de l'application,

• Elle offre de grandes capacités d'extension,

• Elle facilite la gestion des sessions. 

L'appellation  ``n-tiers' pourrait  faire penser que cette architecture met  en  œuvre un  nombre indéterminé de niveaux de service,  alors que ces derniers sont  au  maximum  trois (les trois niveaux d'une application  informatique).  En  fait,  l'architecture n-tiers qualifie la distribution d'application entre de multiples services et non la multiplication des niveaux de service. 

Cette  distribution  est  facilitée  par  l'utilisation  de  composants  ``métier',  spécialisés  et indépendants,  introduits  par les  concepts  orientés  objets  (langages  de  programmation  et middleware).  Elle  permet  de  tirer pleinement  partie  de  la  notion  de  composants  métiers réutilisables. 

Ces composants rendent  un  service  si  possible  générique  et  clairement  identifié.  Ils sont capables de  communiquer entre  eux  et  peuvent  donc  coopérer en  étant  implantés sur des machines distinctes. 

La distribution des services applicatifs facilite aussi l'intégration de traitements existants dans les nouvelles applications.  On  peut  ainsi  envisager de connecter un  programme de prise de commande existant  sur le site central  de l'entreprise à une application  distribuée en  utilisant un middleware adapté. 

Ces  nouveaux  concepts  sont  basés  sur  la  programmation  objet  ainsi  que  sur  des communications standards entre application. Ainsi est né le concept de Middleware objet. 

2.6 Les middleware

2.6.1 Présentation

On appelle middleware (ou logiciel médiateur en français), littéralement ``élément du milieu', l'ensemble  des  couches  réseau  et  services  logiciel  qui  permettent  le  dialogue  entre  les différents  composants  d'une  application  répartie.  Ce  dialogue  se  base  sur  un  protocole applicatif commun, défini par l'API du middleware.

Le Gartner Group définit le middleware comme une interface de communication universelle entre  processus.  Il  représente  véritablement  la  clef de  voûte  de  toute  application  client-serveur. 

L'objectif  principal  du  middleware  est  d'unifier,  pour  les  applications,  l'accès  et  la manipulation de l'ensemble des services disponibles sur le réseau, afin de rendre l'utilisation de ces derniers presque transparente. 

 

 

2.6.2 Les services des middlewares

Un middleware est susceptible de rendre les services suivants :

• Conversion : Service utilisé pour la communication entre machines mettant en œuvre des formats de données différents 

• Adressage : Permet d'identifier la machine serveur sur laquelle est localisé le service demandé afin d'en déduire le chemin d'accès. Dans la mesure du possible

• Sécurité :  Permet  de garantir la confidentialité et  la sécurité des données à l'aide de mécanismes d'authentification et de cryptage des informations. 

• Communication : Permet la transmission des messages entre les deux systèmes sans altération. Ce service doit gérer la connexion au serveur, la préparation de l'exécution des requêtes, la récupération des résultats et la déconnexion de l'utilisateur. 

Le middleware masque la complexité des échanges inter-applications et permet ainsi d'élever le niveau des API utilisées par les programmes. Sans ce mécanisme, la programmation d'une application client-serveur serait complexe et difficilement évolutive.

2.6.3 Exemples de Middleware : 

• SQL*Net : Interface propriétaire permettant de faire dialoguer une application cliente avec  une  base  de  données Oracle.  Ce  dialogue  peut  aussi  bien  être  le  passage  de requêtes SQL que l'appel de procédures stockées. 

• ODBC  :  (Object  Data  Base  Connexion) Interface  standardisée  isolant  le  client  du serveur de données.  C'est  l'implémentation  par Microsoft  d'un  standard  défini  par le SQL  Access Group.  Elle se compose d'un  gestionnaire de driver standardisé,  d'une API  s'interfaçant  avec  l'application  cliente  (sous  Ms  Windows)  et  d'un  driver correspondant au SGBD utilisé.

• DCE  :  (Distributions  Computing  environment)  Permet  l'appel  à  des  procédures distantes  depuis  une  application.  Correspond  à  RPC  (Remote  Procedure  Call) qui permet d'exécuter des procédures distantes. 

Le choix d'un middleware est déterminant en matière d'architecture, il joue un grand rôle dans la structuration du système d'information. 

Pour certaines applications devant accéder à des services hétérogènes, il est parfois nécessaire de combiner plusieurs middlewares. On en vient à la notion de client lourd.

2.6.4 Les Middleware objet 

Pour permettre la répartition d'objets entre machines et l'intégration des systèmes non objets,  il  doit être possible d'instaurer une communication entre tous ces éléments.  Ainsi  est né  le  concept  de  middleware  objet  qui  a  donné  naissance  à  plusieurs spécifications,  dont l'architecture CORBA 5common Object Request Broker Architecture) préconisée par l'OMG (Object Management Group) et DCOM  développée par Microsoft. 

Ces middlewares sont  constitués d'une  série  de  mécanismes permettant  à  un  ensemble  de programmes d'inter opérer de  façon  transparente.  Les services offerts par les applications serveurs sont  présentés aux clients sous la forme d'objets.  La localisation et  les mécanismes mis en œuvre pour cette interaction sont cachés par le middleware. 

La communication  entre objets gomme la différence entre ce qui  est  local  ou  distant.  Les appels de méthodes d'objet à objet sont traités par un mécanisme se chargeant d'aiguiller les messages vers les objets (locaux ou distants).  

3  Le cas de l'Internet

Dans le  cadre  d'un  Intranet  ou  d'un  Extranet,  le  poste  client  prend  la  forme  d'un  simple navigateur Web,  le service applicatif est  assuré par un  serveur HTTP  et  la communication avec le SGBD met en œuvre les mécanismes bien connus des applications client-serveur de la première génération. 

3.1 Répartition des tâches

Ce  type  d'architecture  fait  une  distinction  nette  entre  deux  tronçons  de  communication indépendants et délimités par le serveur HTTP :

• le premier tronçon  relie le poste client  au  serveur Web  pour permettre l'interaction avec l'utilisateur et la visualisation des résultats. Ce premier tronçon n'est composé que de standards (principalement  HTM L  et  HTTP) et  est  basé sur un  simple navigateur Web. Le serveur Web tient le rôle de ``frontal HTTP',

• le  deuxième  tronçon  permet  la  collecte  des données.  Les mécanismes utilisés sont comparables à ceux mis en œuvre pour une application deux tiers. Ils ne franchissent jamais  la  façade  HTTP  et,  de  ce  fait,  peuvent  évoluer  sans  influence  sur  la configuration des postes clients. 

 

 

3.2  Le client universel

Ce type d'architecture est définie par certain comme le client-serveur universel dans la mesure où il s'appuie sur des standards existant sur toutes les plate-formes. 

De plus, dans la même approche, on peut dire au vu de l'explosion des architectures Internet que le navigateur Web est le client universel, puisque de plus en plus utilisé pour tout type de développement, ou d'interface. 

L'avantage de ce client universel est qu'il est aujourd'hui présent sur tout type de machine :

• Postes de bureau

• Portables

• Pockets PC

• Téléphones portables 

De  plus,  tous  les  constructeurs  de  produits  embarqués  embarquent  dans  leurs applicatifs un serveur http qui permet d'administrer facilement à distance leurs machines. 

3.3  Les technologies coté client ou serveur 

Pour revenir aux architectures 3 tiers de l'Internet, cette solution peut s'appuyer sur toutes les nouvelles technologies,  et  permet  de  répartir en  fonction  des besoins les traitements coté client ou coté serveur. 

  

 

• Les technologies coté client font appel à :

• du javascript 

• des applets JAVA 

• des composants ACTIVEX (Microsoft)

• Coté serveur, toutes les techniques permettant de faire du Web dynamique à savoir :

• des scripts CGI (Perl, C, C++

• des servlets écrit en JAVA : JSP (Java Server Pages)

• des traitements en ASP (Active Server Pages ) - technologie Microsoft

• du code PHP 

3.4 Le futur 

Le futur appelé par certains Web 2.0 s'oriente néanmoins vers des clients plus riche afin  de pouvoir bénéficier d'interfaces plus conviviaux,  tout  en  gardant  le  coté universel  du  poste client. Un exemple en est donné aujourd'hui à travers certains clients de messagerie (Yahoo,MSN). 

Alors, si vous voulez rester à la page, suivez de prés ces nouvelles technologies…