Architecture Client/Serveur l'état de l'art3kernels.free.fr/.../ipi/divers/architecture-client-serveur.pdf · ©Institut de Poly-informatique (1997) Cette page est laissée intentionnellement

Client / Serveur

© Institut de Poly-informatique (1997) CLISER.DOC 06/04/01 12:04 version 18

Architecture Client/Serveur l'état de l'art

Auteur : Dominique Vignez

© Institut de Poly-informatique (1997)

Cette page est laissée intentionnellement blanche.

Client /Serveur


Table des matières 1. INTRODUCTION ............................................................................................................................................. 1

1.1. LE CONCEPT ................................................................................................................................................. 1 1.2. LES OUTILS DES ARCHITECTURES CLIENT SERVEUR ...................................................................................... 1

2. LA TECHNOLOGIE CLIENT SERVEUR .................................................................................................... 2 2.1. INTRODUCTION............................................................................................................................................. 2

3. LA SOLUTION: LES ARCHITECTURES CLIENT SERVEUR. ............................................................... 3 3.1. LE CONCEPT................................................................................................................................................. 3 3.2. LES DIFFÉRENTS TYPES D'ARCHITECTURE CLIENT/SERVEUR......................................................................... 3

3.2.1. La présentation distribuée ou rewamping ........................................................................................... 4 3.2.2. La présentation déportée ..................................................................................................................... 5 3.2.3. Les traitements distribués .................................................................................................................... 5 3.2.4. La gestion des données distantes ......................................................................................................... 6 3.2.5. Les bases de données distribuées......................................................................................................... 7

3.3. LA COMMUNICATION CLIENT - SERVEUR...................................................................................................... 8 3.3.1. Le Middleware ..................................................................................................................................... 8

3.4. LE PROTOCOLE DE TRANSPORT..................................................................................................................... 8 3.5. LE PROTOCOLE D'ACCÈS AUX MÉDIAS........................................................................................................... 9 3.6. LES PASSERELLES DE COMMUNICATION........................................................................................................ 9

4. LE LANGAGE SQL........................................................................................................................................ 10

5. ODBC ET JDBC.............................................................................................................................................. 11 5.1. ODBC (OPEN DATABASE CONNECTIVITY)................................................................................................. 11

6. LES OUTILS DES ARCHITECTURES CLIENT SERVEUR ................................................................... 12 6.1. LES OUTILS CLIENT..................................................................................................................................... 12 6.2. LES OUTILS D'INFOCENTRE.......................................................................................................................... 12 6.3. LES OUTILS GÉNÉRALISTES MICRO .............................................................................................................. 13 6.4. LES OUTILS DE DÉVELOPPEMENT ................................................................................................................ 13 6.5. LES OUTILS POLYVALENTS ......................................................................................................................... 13

7. LES OUTILS ORIENTÉS BASES DE DONNÉES...................................................................................... 14

8. LES OUTILS SERVEURS ............................................................................................................................. 15 8.1. LES SGBD RELATIONNELS......................................................................................................................... 15

8.1.1. Les triggers ........................................................................................................................................ 15 8.1.2. Les contraintes................................................................................................................................... 15

8.2. LA SÉCURITÉ DES DONNÉES ........................................................................................................................ 15 8.3. LES MONITEURS TRANSACTIONNELS........................................................................................................... 16 8.4. LES MACHINES BASES DE DONNÉES ............................................................................................... 17 8.5. LE MIDDLEWARE........................................................................................................................................ 18 8.6. LE CLIENT/SERVEUR APPLICATIF................................................................................................................. 18

9. BIBLIOGRAPHIE .......................................................................................................................................... 20

© Institut de Poly-informatique (1997) CLISER.DOC 06/04/01 12:04 version 18

1


1. Introduction

1.1. Le concept Les différents types d'architectures Client-serveur sont :

- La présentation distribuée ( ex.le Revamping), - La présentation déportée (ex.X-Window), - Les traitements distribués (ex.RPC), - La gestion des données distantes, - Les bases de donnés distribuées, - La communication client-serveur, - Le Middleware Le protocole de transport, - Le protocole d'accès au média, - Les passerelles de communication (gateway), - Le langage SQL ODBC et IDAPI.

1.2. Les outils des architectures client serveur

- Les outils client, - Les outils généraliste micro, - Les outils de développement, les outils polyvalents, - Les outils orientés base de données, - Les outils serveurs, - les SGBD relationnels, - Les triggers, - Les contraintes, - La sécurité des données, - Les machines bases de données, - Le Middleware.

2 Client / Serveur


2. La technologie Client Serveur

2.1. Introduction Si la technologie client serveur prend autant d'importance à l'heure actuelle c'est qu'elle est la seule à répondre aux besoins formulés par les entreprises :

- désir d'intégration de l'existant et des nouvelles technologie, - globalisation des systèmes d'information, - amélioration des services proposés à l'utilisateur, - accès plus facile et plus rapide aux informations.

Grâce au client serveur, il est possible de mieux tirer parti des importants investissements consentis dans le passé par l'entreprise, aussi bien en matière de matériel (Main Frame, mini-ordinateurs) qu'en ce qui concerne l'applicatif (les milliers de lignes de code existants). Cette évolution ne peut par ailleurs être dissociée de celle des systèmes d'organisation des entreprises qui, au fil des ans, ont connu des transformations importantes. On est en effet passé d'un système d'organisation très hiérarchisé à un système décentralisé qui lui-même, dans un futur proche, devrait faire place à des organisations réparties. Quoi de plus naturel, alors, que de mettre en place des architectures informatiques adaptées, qui reflètent cette évolution de l'entreprise en étant elles aussi moins centralisées et plus réparties...

3


3. La solution: les architectures client serveur.

3.1. Le Concept Il s'agit pour application, appelée " le client" de faire appel aux services distants proposés par un programme, dit " le serveur" par l'intermédiaire d'un échange de messages. Concrètement, la mise en place d'une architecture de type client/serveur suppose l'existence d'un réseau à l'aide duquel la machine qui héberge l'application "cliente" va pouvoir dialoguer avec le programme "serveur" situé sur une autre machine. L'application "cliente", exploitée par l'utilisateur final, se charge de transmettre des requêtes (calculs à effectuer sur des données ou accès à ces données) au serveur, au travers du réseau. Le serveur, quant à lui, exécute les traitements qui lui sont demandés sur les données qu'il gère puis renvoie le résultat obtenu à l'application "cliente". Ces deux programmes sont indépendants fonctionnellement l'un de l'autres et le dialogue qui se met en place à l'initiative de l'application "cliente" pour l'utilisateur de manière transparente.

3.2. Les différents types d'architecture Client/Serveur Une architecture client/serveur est une architecture informatique dans laquelle l'application qui est en oeuvre respecte le concept de client/serveur présenté précédemment. Si l'on considère une application informatique classique, on s'aperçoit qu'elle peut se décomposer en trois parties :

- l'interface utilisateur, - les traitements, - les données.

Dès lors, il est possible de construire différents types d'architectures client/serveur selon que l'on fait résider certains de ces modules sur le poste client ou sur le poste serveur. Une classification des différents modèles de répartition de ces modules entre un poste client et un poste serveur a ainsi été réalisée par le Gartner Group (société américaine de consultants). Elle fait actuellement office de référence en ce qui concerne les différentes approches que recouvre le concept de client serveur. Les cinq types d'architectures client/serveur, parmi les plus usuelles actuellement sont :

Serveur Client - présentation distribuée avec revamping, - présentation déportée avec X-window, - logique d'application distribuée avec RPC, - gestion déportée des données avec SQL, - gestion distribuée des données avec bases de données réparties.

4 Client / Serveur


Pour construire cette typologie, Le Gartner Group est parti d'un découpage de l'application en trois parties bien distinctes. "La présentation" qui concerne tout ce qui a trait à l'interface utilisateur. "La logique applicative" qui désigne les différents types de traitements effectués par l'application(les calculs, la création de requêtes, etc.). C'est le véritable coeur de l'application. La "gestion des données" qui touche plus particulièrement au domaine de l'accès aux données et au maintien de leur intégrité.

3.2.1. La présentation distribuée ou rewamping Ce type de système s'est surtout développé dans le courant des années 80 pour satisfaire la demande en matière d'interfaces graphiques des utilisateurs travaillant avec des applications centralisées. Il s'agit en fait d'habiller une application déjà existante, conçue au départ en mode caractère, en faisant appel à des outils spécifiques d'habillage dits de rewamping (ex. Rumba/400). Dans la pratique on ne touche pas à l'application existante mais on va la doter d'une couche supplémentaire qui sera graphique. Dans le cas le plus simple, il s'agira d'intercepter uniquement les informations d'affichage utiles ( les données) provenant de l'application centralisée, puis de les replacer correctement au sein de l'interface graphique qui aura été créée. Les différents écrans exploités par l'utilisateur ne seront alors qu'une simple

5


retransposition graphique des écrans déjà existants, sans que de nouvelles fonctionnalités viennent s'y rajouter. Une forme plus évoluée de rewamping peut aussi être mise en place de manière à modifier plus en profondeur l'application à laquelle sera confronté l'utilisateur final. Pour ce faire, on s'attachera à développer une nouvelle application dont le contenu et l'enchaînement des écrans de travail pourront ne pas être limités à ceux existant au sein de l'application centralisée. Les outils de développement permettent ici de créer une application graphique capable de transmettre toute une série d'opérations à l'application centralisée, et capable également d'intercepter puis de traiter les flux d'informations qui en proviennent. Grâce à cette technique, il est possible d'incorporer des éléments désormais banalisés tels que des boutons ou des listes déroulantes, qui sont susceptibles de déclencher des traitements particuliers. Toutefois, ce dernier type de développement reste intimement lié au fonctionnement de l'application originelle. En effet, celle-ci n'ayant pas été modifiée, c'est elle qui impose au développeur les séquences d'opérations qu'il sera autorisé à transmettre. Signalons enfin que la technique du rewamping génère d'importants débits d'informations sur le réseau. La technique du browser Internet peut également faire partie du rewamping en cas d'émulation de terminal avec transcodage "on the fly" des pages écran en pages HTML. 3.2.2. La présentation déportée Afin de réaliser ce type d'architecture (ex: X-WINDOW) il faut disposer d'un environnement graphique qui soit doté d'un gestionnaire de fenêtres capable de communiquer à partir du poste client avec l'application située sur le poste serveur, via le réseau. C'est le cas du gestionnaire de fenêtres X Window (sous UNIX) que l'on retrouve entre autres dans des interfaces graphiques comme motif, Open Look ou Decwindows X Window se charge, sur le poste client, de mettre en forma les résultats qui lui sont transmis par l'application à partir du poste serveur, et de gérer les fenêtres (dimensionnement et positionnement à l'écran). Lorsque l'utilisateur déclenche un événement tel que la sélection d'une option, X WINDOW envoie un message à l'application située sur le poste serveur. Cette dernière prend alors en compte ce choix effectué, les traitements qui lui sont associés, puis transmet un message demandant au poste client d'afficher le résultat. Tout comme les modèles de présentation distribuée, la présentation déportée entraîne une augmentation importante de la densité du trafic d'informations au niveau du réseau. 3.2.3. Les traitements distribués Dans ce type d'architecture (EX:RPC), le coeur de l'application c'est à dire le module ou s'effectuent les traitements se trouve scindé en deux. Ici les traitements associés à l'application sont répartis entre le poste client et le poste serveur.

6 Client / Serveur


En réalité, ce type de fonctionnement dépend étroitement du type d'application que l'on souhaite développer. Il est particulièrement bien adapté aux applications qui font appel de manière régulière à un même ensemble de traitements. Ainsi, si l'on considère les opérations les plus utilisées, il est intéressant de les stocker sous forme de procédures au sein même du poste serveur. Elles pourront alors être directement exécutées sur le serveur par un module dédié. Le poste client se voit dès lors déchargé d'une partie des traitements qu'il avait à effectuer, et le bénéfice est immédiat : les performances du système s'en trouvent améliorées, aussi bien en ce qui concerne le trafic réseau que du point de vue de la rapidité d'exécution. L'utilisation des RPC (Remote Procédure Call ou appel de procédures à distance) constitue un exemple de ce type de fonctionnement. Dans ce cas de figure l'application cliente va faire appel à une procédure distante en envoyant un message au serveur. Ce message contient toutes les informations nécessaires à l'exécution de la procédure par le serveur, à savoir le nom de la procédure, les paramètres qui doivent lui être transmis ainsi que les informations permettant au serveur de vérifier que l'utilisateur possède bien les autorisations nécessaires. Le serveur prend alors en compte le message et exécute la procédure. Une fois les traitements réalisés, il transmet le résultat à l'application cliente qui pourra alors poursuivre l'exécution des opérations. Il Y a donc bien distribution du travail. Sans passer par l'utilisation des RPC, l'exploitation des dernières versions des systèmes de gestion de bases de données (SGBDR) tels que Ingres, Oracle, DB2 ou encore SQL Server de Sybase, permettent aussi de construire des architectures faisant appel aux traitements distribués. Dans ce cas précis, les procédures sont directement stockées et cataloguées au sein du SGBDR. 3.2.4. La gestion des données distantes Dans cette solution, l'ensemble de l'application est exécutée sur le poste client. Le poste serveur, pour sa part, abrite le SGBD (système de gestion de bases de données) chargé de la gestion des données et de leur intégrité. C'est le cas de figure le plus courant : la plupart des SGBD actuels peuvent fonctionner selon ce mode et il existe, en outre, de nombreux outils et applications capables de communiquer avec ces produits. Dans la pratique, lorsque l'utilisateur exécute une fonction au niveau de l'application, cette dernière crée une requête qu'elle transmet ensuite au SGBD via réseau. La requête y est alors prise en compte, et les traitements qui lui sont associés sont effectués. Troisième temps de l'opération, le résultat obtenu est envoyé par le SGBD à l'application cliente, à charge pour elle de mettre en forme et d'afficher les informations reçues. Prenons par exemple, le cas d'un utilisateur souhaitant visualiser, parmi les clients de sa Société, ceux qui ont acheté pour plus d'un million de francs de matériel. Pour y parvenir, il doit soit construire la requête à l'aide de son application, soit lancer directement cette requête si elle est prédéfinie. Dans un cas comme dans l'autre, l'application transmet ladite requête au

7


SGBD qui sélectionne les enregistrements concernés au sein de la base de données. Ce résultat est envoyé à l'application qui affiche alors les informations reçues (ex. PCS/AS400, Show CASE/VISTA). 3.2.5. Les bases de données distribuées Dans ce cas de figure (DRDA IBM), les données sont réparties entre le poste client et plusieurs serveurs. Une requête envoyée en direction d'un serveur peut parfaitement être transmise à tous les serveurs susceptibles d'y apporter une réponse. Ce type d'architecture est celle qui est le plus rarement mise en oeuvre. Cela tient, d'une part, à la complexité des développements que suppose ce type d'application et, d'autre part, aux problèmes que pose la répartition des données. Ici, en effet, il faut impérativement assurer la cohérence, la sécurité et l'intégrité des données qui se trouvent disséminées sur plusieurs systèmes. La difficulté augmente encore, lorsque les différents serveurs sont de marques différentes et fonctionnent sous des systèmes d'exploitation différents. Par exemple, lorsque l'utilisateur souhaite effectuer une transaction comprenant des mises à jour sur les données qui sont réparties, il faut pouvoir être sur que toutes ces opérations ont bien été effectuées correctement. Pour ce faire, on a recours à un mécanisme appelé "commit à deux phases" qui consiste à opérer les modifications associées à la transaction mais à ne valider ces opérations que lorsqu'elles auront toutes pu être exécutées. Dans le cas contraire, ce mécanisme permet de revenir à l'état antérieur à la transaction.

8 Client / Serveur


3.3. La communication Client - Serveur La mise en place d'une architecture client/serveur n'est possible qu'à partir du moment où l'on peut faire dialoguer l'application situé sur le poste client avec le serveur placé géographiquement à un endroit différent. Trait d'union entre le client et le serveur, le réseau joue ce rôle d'intermédiaire sans lequel aucune communication ne serait envisageable. Ce dialogue fait intervenir divers acteurs qui sont le Middleware, le protocole de transport et le protocole d'accès au média, aux quels il faut parfois ajouter des passerelles de communications (gateway). 3.3.1. Le Middleware Il s'agit en fait d'une couche logicielle, située entre l'application et le réseau, qui permet d'établir et de maintenir le dialogue entre l'application cliente et le serveur. Lorsque l'application cliente envoie un message, c'est cette couche logicielle qui le capte. Le Middleware se charge alors de transmettre le message au serveur à travers le réseau, en opérant les conversions de protocoles nécessaires, c'est lui également qui retournera le résultat à l'application client. Pour que cet échange soit possible, il faut que le dialogue puisse être synchronisé entre l'application cliente et le serveur, mais aussi que les informations transmises soient reconnues par le réseau afin qu'il soit en mesure de les communiquer correctement à leur destinataire. Toutes ces opérations sont assurées par le protocole de communication ou FAP ( format and protocols) comme SNA, TCP/IP ou UDP/IP. Le dialogue entre l'application cliente et le protocole de communication fait appel, quand à lui, à une autre couche intermédiaire appelée API (Application Programme Interface). L'API est une interface de programmation située du côté de l'application client (ex. routeur de PCS/AS400), qui contient les fonctions qui seront utilisées pour faire appel aux services proposés par le serveur. C'est l'ensemble API FAP qui constitue le Middleware. Il est tout à fait possible d'utiliser également des moyens de communication asynchrones qui permettent de garantir l'acheminement des informations quelque soit l'état du réseau. Ce type de communication est mis en œuvre par le produit d'IBM appelé MQ Series disponible sur de nombreuses plates-formes d'Operating System.( IBM et non IBM).

3.4. Le protocole de transport Le rôle des protocoles de transport, tels TCP/IP ou Netbios, c'est de créer des segments qui contiennent les messages transmis par le Middleware et les informations nécessaires à leur bon acheminement à travers le réseau. (cf. Booklet Réseaux)

9


3.5. Le protocole d'accès aux médias Il se charge de la circulation effective sur le réseau des segments créés par le protocole de transport, segments qui sont ici agencés en paquets. Le protocole d'accès au média gère les collisions susceptibles d'intervenir entre les différents paquets circulant sur le réseau. ( cf. Booklet réseaux)

3.6. Les passerelles de communication IL s'agit ici de faire dialoguer l'application cliente avec un serveur qui ne possède pas le même protocole de communication. Dans ce cas de figure, on a recours à un composant intermédiaire qui vient s'intégrer a ceux déjà décrits: la passerelle de communication. Cette dernière se charge de la conversion des protocoles de communication et de la transcription des données afin qu'elles soient exploitables par le serveur et l'application cliente. (cf. Booklet Réseaux)

10 Client / Serveur


4. Le langage SQL De nos jours, le langage SQL ( Structured Query Langage) est un élément essentiel en matière de bases de données et d'architectures client serveur. Il fut choisi par le comité de la norme ANSI (American national standard institute) qui était chargé de définir un standard en matière de langage de bases de données relationnelles. Les travaux de ce comité qui ont débuté en 1982, ont abouti en 1986 lorsque le langage SQL fur adopté officiellement par l'ANSI puis agréé norme ISO moins d'un an plus tard par le comité de l'ISO (international Standard Organisation). SQL fut logiquement choisi par l'ANSI car de nombreux SGBD intégraient déjà à l'époque ce langage (ex: Oracle). Il bénéficiait par ailleurs du soutien d'un important acteur dans le domaine des bases de données, en l'occurrence IBM. Toutefois, le langage SQL ainsi normalisé était déjà dépassé à sa sortie puisqu'entre temps certains éditeurs de SGBD avaient fait évaluer le langage SQL qu'ils utilisaient dans leurs produits. Ils l'avaient considérablement étoffé en matière d'algèbre ensembliste, d'administration de données ou encore en ajoutant des extensions au langage de type procédural. Les membres du comité de normalisation se sont donc remis au travail et une nouvelle norme ANSI concernant le langage SQL a vu le jour : SQL89, plus communément appelée SQL ANSI niveau 2. Par rapport à cette norme, force est de constater que les SGBD commercialisés qui font appel au langage SQL utilisent chacun une version propre du langage, dont la norme ne constitue que le plus petit dénominateur commun... Mais l'ISO a sorti en février 93 une nouvelle norme appelée SQL/2 qui intègre désormais les principales avancées qu'ont connu les SGBD, notamment l'aspect procédural que présentent les langages utilisés. Ce nouveau standard qui est maintenant complet, devrait rapidement être adopté par les acteurs principaux de ce marché, à savoir les éditeurs de gestionnaires de bases de données relationnelles qui exploitent SQL.

11


5. ODBC ET JDBC Si le langage SQL est devenu un standard de fait, il n’existe pas de standard en ce qui concerne la communication entre applications micro et serveurs de bases de données. Ou plutôt deux solutions sont proposées :

- ODBC par Microsoft - JDBC par Sun.

Ce sont deux interfaces de programmation qui présentent une base commune retenue par le SQL Access Group au niveau de l'interface des appels de fonctions CLI (Call Level interface). ODBC et JDBC tendent à devenir deux standards de fait. L’un n’est pas mieux ou plus fonctionnel que l’autre. Ils sont adaptés à deux contextes de développement différents. ODBC est plus ancien et plus adapté à l’environnement Microsoft, tandis que JDBC est mieux adapté à Java. Ils répondent chacun à une logique environnementale différente. ODBC est parfaitement adapté à un environnement COM ou COM+, alors que JDBC est plus adapté à une environnement CORBA.

5.1. ODBC (Open Database Connectivity) ODBC est une interface de programmation au niveau applicatif (API) destinée la communication entre une application sous Windows et un ou plusieurs gestionnaires de bases de données. Elle se compose d'une bibliothèque de fonctions, de drivers et d'un gestionnaire de drivers. La bibliothèque de fonctions est fournie sous forme d'une DLL pour Windows. Ces fonctions sont utilisées par l'application afin de se connecter à une base de données locale ou distante, envoyer des données et en recevoir ainsi que se déconnecter à la fin du dialogue. Les drivers sont développés séparément et assurent les échanges entre l'application et les gestionnaires de bases de données. Ils se chargent par exemple de convertir la syntaxe SQL d'ODBC afin qu'elle soit adaptée au serveur avec lequel l'application va dialoguer. Le gestionnaire de drivers met à la disposition de l'application la liste des sources de données accessibles et des drivers disponibles. Il s'occupe aussi de charger dynamiquement en mémoire les drivers et de "gérer la transmission des paramètres et des états de la base". Toutefois si une application Windows peut accéder directement à une base de données locale, par exemple au format de Dbase, lorsque l'on veut dialoguer avec des gestionnaires de base de données distants il faudra d'abord installer les protocoles de communication qui leur sont associés (par exemple SQL*Net pour Oracle ou les Net Lib pour SQL Server).

12 Client / Serveur


6. Les outils des architectures Client Serveur Le marché du client serveur connaît ces dernières années un développement sans commune mesure par rapport aux années précédentes. Pour preuve, les centaines de produits actuellement commercialisés qui intègrent dans leur fonctionnement des capacités pouvant être exploitées dans un contexte d'architecture client serveur. Ce développement touche plus particulièrement les composantes logicielles plutôt que matérielles de ce type d'architectures. En effet à part les terminaux X et les machines bases de données, il n'existe pas de matériel spécifiquement conçu pour une exploitation en environnement client serveur. Cette offre de produits s'articule autour des trois principaux éléments qui composent les architectures client serveur : la partie cliente, la partie serveur et le Middleware qui permet le dialogue entre les deux. Le problème qui se pose alors est celui du choix des produits en fonction des besoins précis de l'entreprise. Différentes solutions sont en effet envisageables et il est donc important de connaître les diverses catégories de produits qui existent et d'en maîtriser les concepts avant de construire une architecture de type client serveur.

6.1. Les outils Client C'est essentiellement cette catégorie de produits qui a connu le plus fort développement au niveau de l'offre. Il s'agit soit d'applications qui dialoguent directement avec le système de gestion de base d'outils permettant de développer cette partie cliente de l'application.

6.2. Les outils d'infocentre Utilisés principalement pour des applications de type décisionnel, les outils d'infocentre sont destinés à l'interrogation des serveurs de bases de données. Dépourvus de langage de programmation, ils proposent tout au plus un langage de Macro commandes susceptible d'automatiser certaines opérations de consultation que l'on souhaite effectuer régulièrement (ex. EXCEL via Show Case/VISTA). Ces outils sont aussi dits du type OLAP. Du point de vue de l'utilisateur, l'accès aux bases de données se voit considérablement simplifié puisqu'il n'est nul besoin de connaître le langage d'interrogation (généralement SQL ) spécifique au système de gestion de bases de données (SGBD) avec lequel on veut dialoguer. Ce type de produit propose souvent tout une panoplie d'outils facilement exploitables par un néophyte afin d'extraire les informations qui l'intéresse : un éditeur graphique de requête, un générateur de rapports ou encore un éditeur de graphiques. Plusieurs de ces produits ont connu une grande diffusion, notamment Q + E Editor de Q + Software qui est livré avec le tableur Excel de Microsoft. Parmi les principaux acteurs dans ce domaine on peut citer Quest et Gupta, Business Objects de la société du même nom, QBE Vision de Channel Computing, impromptu de Cognos ou encore GQL de Andyne.

13


6.3. Les outils généralistes micro Cette catégorie regroupe des logiciels conçus au départ pour des besoins de type Bureautique et non pas en vue d'un fonctionnement de type client serveur. Il s'agit de certains tableurs et gestionnaires de fichiers auxquels on a ajouté une interface SQL leur permettant d'accéder à des serveurs de bases de données. On retrouve ici de nombreux tableurs présents sur le marché tels que Excel, Lotus, Quattro Pro et bien d'autres, ainsi que les principaux SGBD micro: Paradox Access, Omnis, Dataease, Foxpro, Superbase, SuperDB etc ...

6.4. Les outils de développement Dans cette catégorie on trouve des produits dont le choix est étroitement lié au type de développement client/serveur que l'on souhaite réaliser.

6.5. Les Outils polyvalents Bien qu'il ne soient pas au départ conçus dans une optique client/serveur, ces outils permettent d'améliorer la productivité au niveau du développement de la partie cliente de l'application. On pourra par exemple avoir recours à des outils de programmation visuelle qui permettent d'accélérer considérablement le développement de ce type d'application, notamment en ce qui concerne l'interface utilisateur. Ces outils intègrent souvent des mécanismes adaptés au concept client/serveur, tels que le dialogue avec des serveurs de bases de données, l'habillage des applications existantes (rewamping) et parfois l'appel aux services d'un moniteur transactionnel. Le dialogue entre l'application cliente ainsi développée et les gestionnaires de bases de données se fera la plupart du temps en utilisant une couche logicielle intermédiaire faisant appel aux fonctions d'une interface de programmation telle que ODBC de Microsoft ou en servant d'un Middleware tel que Sequelink. Parmi ces produits on peut citer Visual Basic, qui connaît un franc succès dans ce domaine, mais aussi CA Réaliser ou des langages de programmation tels que Borland C ++ ou Microsoft Visual C ++.

14 Client / Serveur


7. Les outils orientés bases de données Conçus dès le départ comme des systèmes de développement d'applications graphiques client serveur, ces produits offrent des fonctions étendues en ce qui concerne l'accès aux bases de données et la conception de projets de taille moyenne ou importante. On trouvera dans ces produits des outils destinés à améliorer la productivité des développements des générateurs d'interfaces graphiques et des langages de développements complets. Dans certains cas, l'application pourra être conçue à partir d'un environnement de programmation visuelle facilitant la conception des écrans, des formulaires et des objets de l'application. Ces types d'environnement offrent généralement une palette complète d'outils de dessin et de personnalisation ainsi que des outils puissants permettant d'automatiser la récupération, la visualisation et la mise à jour des données. Le dialogue avec les principaux SGBD relationnels du marché est largement supporté grâce à l'utilisation d'interfaces adaptées particulièrement au gestionnaire de bases de données auquel on souhaite accéder. Ceci permet souvent une amélioration des performances mais aussi une prise en compte des spécificités des serveurs de bases de données. On pourra par exemple exploiter les messages d'erreurs envoyés par les SGBD relationnels, faire appel aux procédures stockées ou encore effectuer une gestion améliorée des curseurs associés aux requêtes SQL. Le développement en équipe est souvent facilité grâce à des fonctionnalités telles que la gestion et le reporting des projets ou des outils favorisant le partage, la maintenance et la réutilisation des composants des applications. D'autres fonctions telles que la gestion des configurations, la génération automatique d'applications ou le contrôle sécurisé des versions et du code source sont particulièrement précieuses dans ce contexte de développement. Dans cette catégorie de produits on pourra trouver des outils tels que Object View de Matesys, PowerBuilder de Powersoft, Delphi de Borland ou SQL Windows de Gupta.

15


8. Les outils serveurs

8.1. Les SGBD Relationnels Chargés de répondre aux requêtes formulés par les utilisateurs à partir du poste client, les SGBD relationnels sont au coeur du système d'information. Outre la gestion des données, ils se chargent de maintenir l'intégrité de ces données. Lorsque les utilisateurs effectuent des mises à jour dans la base de données, il faut vérifier que les modifications qui vont être réalisées sont bien conformes avec le fonctionnement attendu de l'application. Les principaux SGBD du marché proposent tous des mécanismes permettant d'effectuer ce type de contrôles, notamment par la mise en place de triggers (appelés aussi déclencheurs) et/ou de contraintes. 8.1.1. Les triggers Les triggers sont des portions de code qui s'exécutent automatiquement en fonction du type d'opération de mise à jour qui a été demandé (insertion, modification ou suppression d'enregistrements). Ainsi, si l'utilisateur envoie une requête procédant à la modification de certaines données d'une table, le trigger concerné par cette opération va s'activer automatiquement et s'exécuter. Si les conditions définies au niveau du trigger sont vérifiées, les modifications liées à la requête sont alors effectivement apportées à la base de données. Dans le cas contraire, l'opération est annulée et un message sera envoyé à l'utilisateur pour l'informer de l'échec associé à sa requête. 8.1.2. Les contraintes Les contraintes sont aussi utilisées pour vérifier la conformité des opérations de mise à jour des bases de données. Contrairement aux triggers, les contraintes sont définies en même temps que les tables constituant la base de données et prennent souvent la forme de règles. L'utilisation des contraintes est principalement liée au problème de l'intégrité référentielle. Il s'agit de vérifier lorsqu'on effectue une mise à jour que des conditions liées à l'opération et portant sur d'autres données stockées sont bien vérifiées. Par exemple, il se sera pas possible de créer une facture si le client à qui elle est destinée n'existe pas dans la base de données.

8.2. La sécurité des données L'architecture client serveur nécessites particulièrement une gestion poussée de la sécurité des données associées à l'application. En effet, ces réservoir communs d'informations que sont les bases de données, sont exploités généralement par de multiples utilisateurs. Dès lors, on peut facilement concevoir l'ampleur que pourraient prendre des problèmes touchant directement au fonctionnement du système et à la manipulation des données. Dans ce domaine, les principaux systèmes de gestion de bases de données relationnelles du marché proposent tous une panoplie de fonctions destinées à éviter les différents cas de figure pouvant se poser:

16 Client / Serveur


- identification et authentification des utilisateurs, - techniques élaborées permettant de répondre aux multiples cas de pannes possibles au niveau :

. du système lui-même;

. des supports physiques de stockage;

. de l'exécution valide des transactions lorsque le système client serveur travaille dans un contexte transactionnel.

Dans une architecture client serveur il est important de bien distribuer les traitements de l'application entre les porte cliente et la partie serveur si l'on veut obtenir de bonnes performances de la part du système. Les serveurs de bases de données ont connu des améliorations en la matière notamment en ce qui concerne l'utilisation de procédures stockées, qui peuvent se charger d'une partie plus importante des traitements sur le poste serveur, mais aussi grâce au support du multiprocessing. Parmi les facteurs de développement des architectures client serveur, il y a la prise en compte de l'existant. Les éditeurs de SGBDR l'on bien compris et se sont attachés au développement de moyens d'accès et d'intégration vers les technologies bien implantées ( exemple des passerelles vers d'autres SGBD tels que DB2 RDB et bien d'autres) qu'ils proposent en complément de leur moteur relationnel. De même, l'intéropérabilité et la portabilité sous divers environnements constituent aujourd'hui des facteurs importants du développement des SGBD. La gestion d'objet complexes favorisera quant à elle le développement d'applications de CAO et le multimédia.

8.3. Les moniteurs transactionnels Les moniteurs transactionnels sont d'abord des outils qui permettent de palier les imitations des SGBDR dans un contexte de transactionnel intensif. En effet, lorsque de nombreux utilisateurs ( plus d'une centaine en général) envoient simultanément des demandes de transaction, il arrive un moment où le gestionnaire de base de données ne répond plus et que le système s'écroule. Les fréquentes mises à jour apportées sur les données sont à l'origine de ces situations car dans ce cas de figure, le SGBDR passe une grande partie de son temps à gérer les conflits provoqués par ces requêtes. Les premiers moniteurs transactionnels sont apparus sur des systèmes propriétaires (CICS, ACMS, 5250). Sur ce type de système tout est centralisé et le moniteur transactionnels se charge de recevoir les demandes de transactions émanant des utilisateurs et de les rediriger vers les applications concernées. Le concept mis en oeuvre dans les architectures client serveur fait appel à des notions plus larges que celles des systèmes centralisés : la distribution et la localisation. Pour répondre à ces besoins il fallait des outils adaptés à ce nouveau contexte les moniteurs transactionnels distribuées.

17


Place entre le ou les serveurs de bases de données relationnels et les applications clientes, le moniteur transactionnel distribué joue le rôle de fédérateur au sein de l'architecture client/serveur. Il se charge d'optimiser la gestion des requêtes et des files d'attentes afin d'empêcher tout blocage lié au nombre important de transactions devant être traitées par les SGBDR. Il transmet les requêtes aux serveurs concernés ( gestion de la localisation) et lorsque ces derniers ne sont pas du même type (cas d'un architecture hétérogène.). Il assure le transcodage des données et des requêtes afin qu'elles soient compréhensibles par les serveurs de bases de données et par les applications clientes. La gestion de la sécurité est aussi assurée par les moniteurs transactionnels distribués, notamment en ce qui concerne la tolérance aux pannes, l'identification et l'authentification des utilisateurs, la gestion de la redondance des données ainsi que le traitement des erreurs. Dans le cas d'une architecture distribuée, l'intégrité des données est assurée grâce à l'utilisation du mécanisme de commit à deux phases. Le moniteur transactionnel présente ici un intérêt tout particulier dans le cadre d'une architecture hétérogène. Si les principaux gestionnaires de bases de données relationnels proposent aujourd'hui ce mécanisme, il n'est souvent utilisable que dans le cas d'une architecture homogène faisant intervenir le même SGBDR sur différents serveurs de bases de données. En effet, la gestion du commit à deux phases est alors assurée par l'un des serveurs de bases de données. Dans le cas d'une architecture distribuée hétérogène, c'est généralement le moniteur transactionnel qui se charge de la gestion du mécanisme de commit à deux phases. Il va par exemple transmettre les requêtes de mise à jour aux différents SGBDR. Si l'opération s'effectue correctement sur les différents serveurs, il leur envoi un message afin que les modifications soient validées définitivement. Dans le car contraire un ordre d'annulation est transmis aux SGBDR concernés afin que les bases de données retrouvent leur état précédent.

8.4. LES MACHINES BASES DE DONNÉES Actuellement on assiste à l'apparition de plusieurs machines spécialement conçues pour la gestion d'importantes bases de données. Ce sont des systèmes parallèles multiprocesseurs qui sont destinés à être utilisé comme serveur spécialisé avec un gestionnaire de bases de données. Leur apparition est en partie liée aux limites des solutions traditionnelles avec un SGBDR en matière de gestion des données (50 à 60 gigaoctets). Ces machines peuvent en effet gérer l'accès à des centaines, voire des milliers de gigaoctets ou même des téraoctets de données et offrent aussi d'importantes capacités au niveau transactionnel car elles peuvent assurer de forts débits d'informations. De plus en plus de constructeurs proposent ce type de machines ( Tandem, ICL,SEQUENT? NCR, TERADATA, etc,) avec souvent le support de plusieurs milliers de processeurs. Certains constructeurs du monde scientifique ( Thinking Machine, Ncube, Meiko) ont aussi réagi en sortant de nouvelles générations de machines orienté bases de données avec souvent Oracle comme SGBDR. Du côté des éditeurs de SGBDR ( Oracle, Ingres, ou Sybase), on

18 Client / Serveur


constate une plus grande disponibilité de leur produit sur une plus large gamme de ces matériels. Même des sociétés comme IBM ayant pour DB2 une offre sur une machine conçue spécialement pour supporter une base de donnée comme l'AS400, portent leur SGBD sur de nombreuses plates-formes dont ils ne sont pas les fabricants.

8.5. Le Middleware Faute de standard, le monde du Middleware ne cesse de s'enrichir de produits venant combler le vide existant entre produits clients et produits serveurs. L'intégration de l'existant est un des facteurs à prendre en compte lorsqu'on souhaite mettre en place une architecture client/serveur. Dès lors, le choix des produits sera lié à leur ouverture et aux possibilités de dialogue qu'ils offrirons vis à vis des outils déjà existants au sein de l'entreprise et ceux à venir. Certains éditeurs tels IBI ou Techgnosis se sont spécialisés dans le développement de Middleware. Leurs produits (EDA/SQL et Sequelink respectivement) assurent la communication entre frontaux et serveurs au départ incompatibles. Microsoft avec ODBC et Borland, IBM, Novell et Wordperfect avec IDAPI proposent chacun une solution en matière de dialogue entre applications micros et serveurs de bases de données. L'offre des éditeurs de gestionnaires de bases de données relationnelles est actuellement la plus riche. Le Middleware est ici lié au SGBDR vendu par chaque éditeur et a pour but de permettre le dialogue entre l'application cliente et le SGBDR mais aussi d'offrir une connectivité accrue avec les autres SGBD susceptibles d'être intégrés au sein de l'architecture client/serveur utilisée. Certains constructeurs proposent aussi des outils de ce type mais cette offre s'insère plus généralement au sein d'une solution globale en matière d'architecture client/serveur.

8.6. Le client/serveur applicatif L’architecture client/Serveur est omniprésente, y compris dans l’architecture applicative. Des éléments logiciels se comportent comme serveur, c’est à dire rendant des services, tandis que d’autres éléments logiciels se comportent en clients. La programmation orientée objets favorise ce type d’architecture logicielle permettant une grande réutilisation de certains composants. Là encore deux environnements existent. L’environnement COM DCOM, rebaptisé COM+ pour Windows2000 et l’environnement CORBA pour tout ce qui n’est pas Windows. Ces normes se situent au niveau API des objets et différent par le nombre et le nom des méthodes standard devant être disponibles ainsi que par les propriétés des interfaces à réaliser pour être conforme à la norme. Le WEB n’échappe pas à la règle. Entre le serveur WEB et le client Browser, nous sommes bien en présence d’un client et d’un serveur. Là aussi les normes vont bon train et se scindent encore une fois entre le monde Microsoft et les autres. La nuance ici est beaucoup lpus importante qu’ailleurs car l’usage de l’une ou l’autre a des répercussions importantes sur les performances des serveurs et sur la capacité d’un serveur à fournir des temps de réponses

19


acceptables à un grand nombre de sollicitations. Des deux côtés des solutions sont disponibles pour répondre aux besoins, mais les répercussions financières en matière d’investissements matériels et en licences ainsi que sur la taille des équipes d’exploitations ne sont pas neutres. L’environnement Microsoft, VB, ASP permet un développement plus léger avec des techniques et des outils « relativement » simples, rapides et bons marchés, mais demande un surinvestissement en machines et en exploitation. L’environnement JAVA, EJB, JSP demande une plus grande organisation au départ, plus de moyens, mais résiste beaucoup mieux à la montée en charge.

20 Client / Serveur


9. Bibliographie

- L'architecture client serveur, aspects techniques, enjeux stratégiques Auteur : Alain Lefevre Éditeur: Armand Colin

Documents

Architecture Client/Serveur l'état de l'art3kernels.free.fr/.../ipi/divers/architecture-client-serveur.pdf · ©Institut de Poly-informatique (1997) Cette page est laissée intentionnellement