L'architecture deux tiers

Présentation

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 l'application de gestion fonctionnant sous Ms-Windows 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, le 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. Ce dialogue nécessite l'instauration d'une communication entre client et serveur. Nous allons étudier de quoi elle se compose.

Le dialogue client-serveur

Le modèle client-serveur met en oeuvre une conversation entre deux programmes que l'on peut opposer à l'échange figé ``maître-esclave'' qu'entretiennent les applications sur site central avec leurs terminaux passifs.

Dans une conversation client-serveur, on distingue donc les deux parties suivantes :

• Le client, c'est le programme qui provoque le dialogue,
• Le serveur, c'est le programme qui se contente de répondre au client.

Le client provoque l'établissement d'une conversation afin de d'obtenir des données ou un résultat de la part du serveur.

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

Le Middleware

Définition

On appelle middleware, 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.

Les services rendus

Un middleware est susceptible de rendre les services suivants :

• Conversion : Service utilisé pour la communication entre machines mettant en oeuvre des formats de données différents, elle est prise en charge par la FAP,
• 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, cette fonction doit faire appel aux services d'un annuaire.
• 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 extrêmement complexe et rigide.

Exemples de middleware

• SQL* : 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 : Interface standardisée isolant le client du serveur de données. C'est l'implémentation par Microsoft du standard CLI 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 : Permet l'appel à des procédures distantes depuis une application.

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.

Les middleware proposés par les fournisseurs de SGBD sont très performants et permettent de tirer profit de l'ensemble des fonctionnalités du serveur de données pour lequel ils ont été conçus. Par contre, ils ne permettent pas, le plus souvent, l'accès à d'autres sources de données.

Pour certaines applications devant accéder à des services hétérogènes, il est parfois nécessaire de combiner plusieurs middlewares. Dans ce cas, le poste client doit connaître et mettre en oeuvre plusieurs IPC, on en vient à la notion de client lourd.

Limites du client-serveur deux tiers : Le client lourd

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, ou fat client.

L'architecture client-serveur de première génération s'est heurtée à ce constat à l'heure des premiers bilans :

• 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,
• la conversation entre client et serveur est assez bruyante et s'adapte mal à des bandes passantes étroites. De ce fait, ce type d'application est souvent cantonné au réseau local de l'entreprise,
• 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.