Choix D'une Architecture Trois-tiers

suivant: Réalisation technique de l'architecture monter: Intranet en architecture trois-tiers précédent: Intranet en architecture trois-tiers   Table des matières Sous-sections

• Trois tâches importantes
  • Stockage et accès aux données
  • Logique applicative
  • Présentation
• Architecture client-serveur
  • Avantage: technologies éprouvées
  • Inconvénients
• Architecture trois-tiers
  • Avantages de cette architecture
• Architecture multi-tiers
  • Répartition des données sur différents serveurs
  • Répartition de la logique applicative

Choix d'une architecture trois-tiers L'objectif premier d'un syst�me d'information quel qu'il soit est de permettre � plusieurs utilisateurs d'acc�der aux m�mes informations. Pour cela il faut donc regrouper les informations utilis�es par l'entreprise. En terme technique, cela se traduit par la centralisation des donn�es au sein d'une base de donn�es. L'�volution des syst�mes d'information s'est donc bas�e sur une meilleure subdivision entre les t�ches � r�aliser pour permettre l'exploitation de ces donn�es par les utilisateurs finaux. Ceci permet de structurer plus efficacement les informations ce qui entra�ne � la fois une meilleure organisation de l'entreprise et une meilleure efficacit� technique. Cette subdivision a �t� facilit�e par l'av�nement des technologies orient�es objets qui s'appliquent aussi bien au mod�le client-serveur qu'au mod�le Internet. Ces technologies permettent une s�paration entre les diff�rents composants du syst�me. Il devient alors possible de r�aliser de nouvelles architectures permettant la mise � disposition des informations sous diff�rentes formes tout en diminuant les temps de d�veloppement. Ces technologies permettent �galement de faire collaborer une grande diversit� de syst�mes. On parle alors d'architecture distribu�e. Il est ainsi possible de pr�senter des donn�es en provenance d'un mainframe m�lang�es � des donn�es en provenance d'un SGBDR, le tout �tant affich� dans un browser sur la m�me page HTML.

Trois tâches importantes

Tout syst�me d'information n�cessite la r�alisation de trois groupes de fonctions: le stockage des donn�es, la logique applicative et la pr�sentation. Ces trois parties sont ind�pendantes les unes des autres: on peut ainsi vouloir modifier la pr�sentation sans modifier la logique applicative. La conception de chaque partie doit �galement �tre ind�pendante, toutefois la conception de la couche la plus basse est utilis�e dans la couche d'au dessus. Ainsi la conception de la logique applicative se base sur le mod�le de donn�es, alors que la conception de la pr�sentation d�pend de la logique applicative.

Stockage et accès aux données

Le syst�me de stockage des donn�es a pour but de conserver une quantit� plus ou moins importantes de donn�es de fa�on structur�e. On peut utiliser pour cette partie des syst�mes tr�s vari�s qui peuvent �tre des syst�mes de fichiers, des mainframes, des syst�mes de bases de donn�es relationnelles, etc... Le point commun entre toutes ces syst�mes est qu'il permettent le partage des donn�es qu'ils contiennent via un r�seau. La m�thode d'acc�s � ces donn�es d�pendra du type d'organisation de ces donn�es. Dans le cas d'une base de donn�es relationnelle, l'acc�s peut se faire par des API qui d�pendent du langage et de l'environnement. Ainsi en JAVA l'acc�s se fait via JDBC, alors qu'en C++ il se fera � l'aide d'ODBC. Quel que soit l'API, le langage SQL est utilis�.

Logique applicative

La logique applicative est la r�alisation informatique du mode de fonctionnement de l'entreprise. Cette logique constitue les traitements n�cessaires sur l'information afin de la rendre exploitable par chaque utilisateur. Les utilisateurs peuvent avoir des besoins tr�s vari�s et �volutifs. Il devient alors n�cessaire de permettre l'�volution du syst�me sans pour autant devoir tout reconstruire. Cette partie utilise les donn�es pour les pr�senter de fa�on exploitable par l'utilisateur. Il convient donc de bien identifier les besoins des utilisateurs afin de r�aliser une logique applicative utile tout en structurant les donn�es utilis�es.

Présentation

La pr�sentation est la partie la plus imm�diatement visible pour l'utilisateur. Elle a donc une importance primordiale pour rendre attrayante l'utilisation de l'informatique. Son �volution a �t� tr�s importante depuis les d�buts de l'informatique. Depuis les terminaux en mode texte connect�s � des mainframes jusqu'au HTML de nos jours en passant par les applications graphiques d�velopp�es en client serveur, il y a eu beaucoup de chemin parcouru. Diff�rents types d'interfaces demeurent int�ressantes. En effet l'ergonomie d'un site Intranet HTML n'est pas forc�ment id�al pour tous les types d'applications. Il peut �tre int�ressant de proposer plusieurs types d'interface pour une seule logique applicative. Par exemple une entreprise disposant d'un site de commerce �lectronique peut proposer un acc�s � la liste de ses produits sur Internet en HTML mais disposer d'une interface d'administration r�alis�e � l'aide d'une applet graphique.

Architecture client-serveur

Les architectures client-serveur constituent une �tape importante dans l'�volution des syst�mes d'informations. Ce type d'architecture est constitu� uniquement de deux parties: un client qui g�re la pr�sentation et la logique applicative, un serveur qui stocke les donn�es de fa�on coh�rente et g�re �ventuellement une partie de la logique applicative. L'interface entre ces deux parties est classiquement le langage SQL (dans sa version normalis� ou dans une version propri�taire). Dans ce type d'architecture on constate une certaine ind�pendance du client par rapport au serveur. La programmation du client peut s'effectuer sans se pr�occuper de la mise en place de la base de donn�es. En particulier, les questions concernant l'administration des donn�es ne concerneront pas le d�veloppeur du client (dimensionnement des disques, r�partition des donn�es sur le syst�me, optimisation des acc�s aux donn�es, sauvegarde des donn�es,...). Un des objectifs des architectures multi-tiers sera de g�n�raliser ce type de fractionnement en �l�ments logiciels ind�pendants les uns des autres. La qualit� de ce type d'architecture est bas� sur deux technologies �prouv�es: la notion de base de donn�es relationnelle et le langage SQL. Toutefois on peut �galement constater deux inconv�nients � cette technologie: elle poss�de une s�curit� limit�e et surtout son d�ploiement demeure long et laborieux.

Avantage: technologies éprouvées

Le mod�le relationnel a �t� introduit par E. Codd en 1970. Il s'appuie sur des consid�rations th�oriques formul�es sous la forme de 12 r�gles formant le cahier des charges initial. Ce mod�le est bas� sur la notion de relation. Une relation est un ensemble de n-uplet (n est fixe) qui correspondent chacun � une propri�t� de l'objet � d�crire. Ce mod�le permet la gestion pr�cise de contraintes d'int�grit� qui garantissent la coh�rence des donn�es. Les syst�mes de gestion de base de donn�es relationnel (SGBDR) sont interfac�s � l'aide d'un langage unique: le SQL (Structured Query Language). Ce langage permet d'effectuer l'ensemble des op�rations n�cessaires sur la base de donn�es. Ce langage permet �galement la gestion de transaction. Une transaction est d�finie par quatre propri�t�s essentielles: Atomicit�, Coh�rence, Isolation et Durabilit� (ACID). Ces propri�t�s garantissent l'int�grit� des donn�es dans un environnement multi-utilisateurs. L'Atomicité permet � la transaction d'avoir un comportement indivisible; soit toutes les modifications sur les donn�es effectu�es dans la transaction sont effectives, soit aucune n'est r�alis�e. On comprend l'int�r�t de ce concept dans l'exemple simple d'une transaction d�bitant un compte A et cr�ditant un autre compte B : il est clair que la transaction n'a de sens que si les deux op�rations sont men�es � leur terme; L'atomicit� de la transaction garantit que la base de donn�e passera d'un �tat coh�rent � un autre �tat coh�rent. La Cohérence des donn�es de la base est donc permanente. L'Isolation des transactions signifie que les modifications effectu�es au cours d'une transaction ne sont visibles que par l'utilisateur qui effectue cette transaction. Au cours de la transaction, l'utilisateur pourra voir des modifications en cours qui rendent la base apparemment incoh�rente, mais ces modifications ne sont pas visibles par les autres et ne le seront qu'� la fin de la transaction si celle-ci est correcte (elle ne rend pas la base incoh�rente). La Durabilité garanti la stabilit� de l'effet d'une transaction dans le temps, m�me en cas de probl�mes graves tel que la perte d'un disque. L'ensemble de ces notions sont � la base des syst�mes d'information actuels. Les technologies supportant ces notions (en particulier les SGBDR) forment l'aboutissement des recherches des 30 derni�res ann�es. Des syst�mes comme Oracle offrent d�sormais des performances int�ressantes y compris sur de grosses bases de donn�es. Ces performances ont �t� obtenues sans faire de compromis sur les concepts th�oriques sur lesquels ils se basent (mod�le relationnel). Ces syst�mes servent donc tout naturellement de base aux futurs syst�mes d'information utilisant les nouvelles technologies Internet.

Inconvénients

L'architecture client-serveur poss�de toutefois des inconv�nients. Ce sont ces inconv�nients qui poussent les entreprises � utiliser d'autres technologies. Les deux inconv�nients principaux sont la difficult� � g�rer correctement les questions de s�curit� et le co�t du d�ploiement. La s�curit� d'un syst�me en architecture client-serveur est g�r�e au niveau du SGBDR. Celui-ci contr�le l'acc�s aux donn�es en attribuant des autorisations d'acc�s aux diff�rents utilisateurs du syst�me. Le probl�me vient du fait que cette attribution de droit ne peut pas tenir compte des sp�cificit�s du logiciel r�alis�. Pour pouvoir g�rer les droits d'acc�s de cette fa�on il faut accorder � chaque utilisateur des droits sur un grand nombre de tables, ce qui devient vite laborieux. En pratique il est souvent plus rapide de ne cr�er qu'un utilisateur sur le SGBDR avec lequel tous les utilisateurs se connectent. Cette approche ne permet aucune gestion de la s�curit�. Il suffit de conna�tre le login et le mot de passe d'acc�s � la base pour acc�der � l'ensemble des donn�es sans aucune restriction. L'autre probl�me est souvent consid�r� comme beaucoup plus important par les entreprises car il est beaucoup plus visible. Il s'agit des dur�es et co�ts de d�ploiement des logiciels. En effet un logiciel classique, d�velopp� en architecture client-serveur, n�cessite une installation et une �ventuelle configuration sur chaque poste utilisateur. Le d�placement d'un technicien co�te d�j� tr�s cher aux entreprises. Mais ce qui reste le plus laborieux est la n�cessit� de mettre � jour r�guli�rement le logiciel. Dans une architecture client-serveur, chaque mise � jour du logiciel n�cessite un nouveau d�ploiement accompagn� de nombreux co�ts.

Architecture trois-tiers

Le principe d'une architecture trois-tiers est relativement simple: il consiste � s�parer la r�alisation des trois parties vues pr�c�demment (stockage des donn�es, logique applicative, pr�sentation). Nous avons d�j� pu entrevoir la possibilit� de s�parer la conception de ces trois subdivisions, ici il s'agit de s�parer leur implantation. Tout comme dans le client-serveur cette s�paration signifie qu'il est possible de d�ployer chaque partie sur un serveur ind�pendant, toutefois cela n'est pas obligatoire. La mise en place de ce type d'architecture permet dans tous les cas une plus grande �volutivit� du syst�me. Il est ainsi possible de commencer par d�ployer les deux serveurs sur la m�me machine, puis de d�placer le serveur applicatif sur une autre machine lorsque la charge devient excessive. Les �l�ments permettant la r�alisation classique d'un syst�me en architecture trois tiers sont les suivants:

• système de base de donnée relationnel (SGBDR) pour le stockage des données
• serveur applicatif pour la logique applicative
• navigateur web pour la présentation

Il est important de remarquer que l'essentiel du travail de d�veloppement sera implant� au niveau du serveur applicatif. Le SGBDR n�cessitera un travail d'administration surtout dans le cas d'une quantit� de donn�es importante. Le travail de conception de la base de donn�e sera la pierre angulaire du syst�me. En effet l'ensemble du d�veloppement s'appuiera sur cette conception. Le navigateur web n�cessitera la programmation de code sp�cifique permettant de g�rer l'affichage par ce navigateur. Ce code sera plac� sur le serveur applicatif pour permettre une mise � jour sans n�cessiter de nouveaux d�ploiements.

Avantages de cette architecture

Cette architecture se d�veloppe actuellement au sein des entreprises gr�ce aux nombreux avantages qu'elle pr�sente. Malgr� la diff�rence �vidente entre une architecture trois tiers et un syst�me client-serveur (l'apparition d'un serveur pour la logique applicative), le syst�me reste bas� sur les technologies �prouv�es d�taill�es pr�c�demment (aspect relationnel et transaction). La logique applicative est d�plac�e au niveau du serveur d'application mais reste programm�e � l'aide des m�mes technologies li�es aux bases de donn�es relationnelles. En particulier l'utilisation du langage SQL reste jusqu'� pr�sent la solution la plus int�ressante au niveau de la qualit� logicielle. Elle pr�sente � la fois une grande fiabilit�, une bonne disponibilit�, une excellente �volutivit�,... Toutefois il faut prendre en compte deux facteurs importants: d'une part le choix du SGBDR (ils n'ont pas tous les m�me qualit�s), d'autre part la qualit� des programmes utilisant la base de donn�es (aussi bien au niveau de la conception que de la programmation). L'avantage principal d'une architecture multi-tiers est la facilit� de d�ploiement. L'application en elle m�me n'est d�ploy�e que sur la partie serveur (serveur applicatif et serveur de base de donn�es). Le client ne n�cessite qu'une installation et une configuration minime. En effet il suffit d'installer un navigateur web compatible avec l'appication pour que le client puisse acc�der � l'application, ce navigateur �tant par ailleurs souvent install� par d�faut sur toutes les machines. Cette facilit� de d�ploiement aura pour cons�quence non seulement de r�duire le co�t de d�ploiement mais aussi de permettre une �volution r�guli�re du syst�me. Cette �volution ne n�cessitera que la mise � jour de l'application sur le serveur applicatif. Ceci est tr�s important car cette �volutivit� est un des probl�mes majeurs de l'informatique. Le troisi�me avantage est l'am�lioration de la s�curit�. Dans un syst�me client-serveur tous les clients acc�daient � la base de donnn�es ce qui la rendait vuln�rable. Avec une architecture multi-tiers l'acc�s � la base n'est effectu� que par le serveur applicatif. Ce serveur est le seul � connaitre la fa�on de se connecter � cette base. Il ne partage aucune des informations permettant l'acc�s aux donn�es, en particulier le login et le password de la base. Il est alors possible de g�rer la s�curit� au niveau de ce serveur applicatif, par exemple en maintenant la liste des utilisateurs avec leurs mots de passe ainsi que leurs droits d'acc�s aux fonctions du syst�me. On peut m�me am�liorer encore la s�curit� par la mise en place d'une architecture r�seau interdisant totalement l'acc�s au serveur de base de donn�es pour les utilisateurs finaux. La mise en place de firewall correctement configur� permettra ceci. Dans le cas de la mise en place d'un workflow au sein de l'entreprise Kallisto, l'avantage le plus int�ressant est sans aucun doute l'�volutivit� du syst�me. En effet les besoins actuels sont relativement vastes, toutefois la r�alisation totale semble relativement longue et difficile � r�aliser d'un seul coup. De plus des probl�mes risquent de n�cessiter une mise � jour r�p�t�e du syst�me. Un autre aspect int�ressant est la possibilit� d'utiliser le syst�me en Extranet, ce qui chez Kallisto permettra de faciliter la communication entre le si�ge social situ� � Lyon et l'agence de Paris.

Architecture multi-tiers

Nous avons vu ce qu'�tait une architecture trois-tiers, une architecture multi-tiers va plus loin dans le d�coupage de l'application sur diff�rents serveurs. Une architecture multi-tiers est �galement appel� architecture distribu�e du fait de la distribution des traitements et des donn�es sur diff�rents serveurs. Le d�coupage de base du syst�me reste toujours le m�me: une partie gestion de donn�es, une partie gestion de la logique applicative et bien entendu le client assurant la pr�sentation. Toutefois les deux parties d�velopp�es cot� serveur vont pouvoir �tre d�ploy�es chacune sur plusieurs serveurs. L'objectif g�n�ral de ce type d'architecture est de permettre l'�volutivit� du syst�me sous plusieurs aspects: la quantit� de donn�es stock�e, la disponibilit� du serveur, le nombre d'utilisateurs,... Il faut �galement bien comprendre qu'un syst�me con�u en architecture multi-tiers n'est pas forc�ment d�ploy� sur plusieurs machines d�s le d�part. Toutefois son mode de programmation doit permettre de modifier le d�ploiement du syst�me en cours d'exploitation par un administrateur. Le d�veloppeur doit donc rendre le syst�me ind�pendant du serveur sur lequel il s'�x�cute. Il existe deux types de r�partition possibles dans une architecture distribu�e. Il est possible de r�partir les donn�es et de r�partir la logique applicative. Chacune de ces deux r�partitions permet de r�soudre des probl�mes de natures diff�rentes. Elles peuvent donc �tre mises en place soit s�par�ment soit en parall�le sur le m�me syst�me.

Répartition des données sur différents serveurs

Il s'agit d'utiliser plusieurs sources de donn�es dans une m�me application. Chaque source poss�de sa propre structure de donn�es. Chaque serveur de donn�es peut �tre g�r� de fa�on tr�s diff�rente. Toutefois une interface de programmation commune � toutes les sources doit pouvoir exister. Il peut exister des relations entre les donn�es des diff�rents serveurs, il sera alors n�cessaire de g�rer des transactions distribu�es entre des diff�rents serveurs de donn�es. Cette r�partition de donn�es correspond � la notion de base de donn�es distribu�s. Les bases de donn�es distribu�es permettent de r�soudre deux types de probl�mes. La premi�re est la performance du syst�me: la r�partition des donn�es permet d'augmenter la disponibilit� des donn�es. Toutefois il est n�cessaire de bien penser cette r�partition afin de ne pas d�multiplier le nombre de transactions distribu�es n�cessaires. Ceci aurrait pour effet de diminuer la performance plus que de l'augmenter. Le deuxi�me type de probl�mes est la r�utilisation des syst�mes �xistants. En effet de nombreux syst�mes informatiques stockent actuellement une grande quantit� de donn�es. Toutefois ces syst�mes ne sont pas toujours bien coordonn�s entre eux. Ceci risque d'entra�ner des redondances dans les donn�es et des incoh�rences entre plusieurs sources de donn�es. L'objectif est donc de r�utiliser ces syst�mes dans une m�me application afin de restructurer le syst�me d'information sans pour autant repartir de z�ro (ce qui est non seulement un non sens mais est aussi impossible). Les syst�mes r�utilis�s sont bien souvent h�t�roclites (mainframe, SGBDR,...) et n�cessitent d'�tre r�unis en utilisant diverses technologies (moniteurs transactionnels, serveurs d'applications,...).

Répartition de la logique applicative

La r�partition de la logique applicative permet de distribuer les traitements sur diff�rentes machines. Cette distribution est facilit�e par l'utilisation de la programmation orient�e objet et plus particuli�rement de ce qu'on appelle les composants. Un composant poss�de entre autre la caract�ristique d'�tre accessible � travers le r�seau. Un composant peut ainsi �tre instanti� puis utilis� au travers du r�seau. Il est �galement possible de trouver un serveur permettant l'utilisation d'un composant, ce qui permet une forte �volutivit� ainsi qu'une r�sistance aux pannes importantes (le service sera toujours disponible sur un serveur m�me si une machine tombe en panne). La r�alisation de ce type de r�partition n�cessite l'utilisation de technologies sp�cifiques. D'une part il faut permettre la communication entre les diff�rents �l�ments de l'application (RMI), d'autre part le d�ploiement et l'�volution du syt�me doivent pouvoir �tre assur�s (JNDI + fichiers XML). Certaines technologies proposent une architecture coh�rente pour la mise en place des diff�rentes technologies intervenant sur un syst�me distribu� (EJB). Les buts recherch�s lors de la mise en place de ce type d'architecture sont la performance, l'�volutivit�, la maintenabilit�... suivant: Réalisation technique de l'architecture monter: Intranet en architecture trois-tiers précédent: Intranet en architecture trois-tiers   Table des matières cedric Babault 2002-01-20