Architecture client serveur l`état de l`art

Transcription

Client / Serveur
Architecture Client/Serveur
l'état de l'art
Auteur : Dominique Vignez
© Institut de Poly-informatique (1997)
CLISER.DOC 06/04/01 12:04 version 18
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
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, miniordinateurs) 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

Architecture client serveur l`état de l`art

Transcription

Documents pareils

[ INFORMATIQUE CYCLE PROBATOIRE

Fiche examen 2

Le système de bases de données du futur

Les données et l`as400 le SGBDR DB2/400

Darty met en place un plan de continuité d`activité sur ses entrepôts

Le Mexique - Chambre de commerce du Montréal métropolitain

2.Objectifs et Architecture

CC30 Certificat de compétence Conception, développement

Plan Directeur Informatique - Le Centre jeunesse Gaspésie / Les Îles

AE1_Corriges_FR3 - Le coin du français

Bases de Données Réparties - LP GSR 2007/2008