Documente Academic
Documente Profesional
Documente Cultură
Table des matires r Introduction s Rappel du sujet s Composition du jury s Remerciements De l'informatique centralise au client-serveur r Les trois niveaux d'abstraction d'une application r L'architecture un tiers s Prsentation s Les solutions sur site central (mainframe) s Les applications un tiers dployes s Limitations r Le schma du Gartner Group r L'architecture deux tiers s Prsentation s Le dialogue client-serveur s Le Middleware s Dfinition s Les services rendus s Exemples de middleware s Limites du client-serveur deux tiers : Le client lourd Les architectures distribues r L'architecture trois tiers s Objectifs s Les premires tentatives s Le serveur de transaction
La rvolution Internet s Introduction s Les standards d'Internet s Adaptation l'entreprise : Intranet s Rpartition des traitements s Le client lger s Prsentation s Ergonomie s Exemples de clients lgers s Le service applicatif s Prsentation s Gestion des transactions s Limitations Les architectures n-tiers s Prsentation s Que de niveaux... s Le rle de l'approche objet s L'approche objet s Les objets mtier s La communication entre objets s Principes s L'appel de procdure distantes (RMI) s Le modle CORBA s Enfin une vision cohrente du systme d'information
s
q q q
Introduction
suivant: De l'informatique centralise au monter: Table des matires prcdent: Table des matires Table des matires Index Sous-sections
q q q
Composition du jury
q q q q
Remerciements
Introduction
Je tiens remercier vivement M. Emmanuel MAURICE, qui a propos le sujet de cette tude, pour son soutien et sa disponibilit tout au long de mes recherches. Je remercie galement M. J.L. STEFFAN pour ses prcieux conseils et tous les membres du jury, MM. Claude KAISER et C. KLEINPETER pour le temps qu'ils consacrent aux tudiants du CNAM.
suivant: De l'informatique centralise au monter: Table des matires prcdent: Table des matires Table des matires Index Document rdig par Rmi LEBLOND (remi.leblond@free.fr)
suivant: Les trois niveaux d'abstraction monter: Vers une architecture n-tiers prcdent: Introduction Table des matires Index
q q
Les trois niveaux d'abstraction d'une application L'architecture un tiers r Prsentation r Les solutions sur site central (mainframe) r Les applications un tiers dployes r Limitations Le schma du Gartner Group L'architecture deux tiers r Prsentation r Le dialogue client-serveur r Le Middleware s Dfinition s Les services rendus s Exemples de middleware r Limites du client-serveur deux tiers : Le client lourd
http://remi.leblond.free.fr/probatoire/node3.html18/11/2003 11:04:03
suivant: L'architecture un tiers monter: De l'informatique centralise au prcdent: De l'informatique centralise au Table des matires Index
la couche de prsentation, encore appele IHM2.1, permet l'interaction de l'application avec l'utilisateur. Cette couche gre les saisies au clavier, la souris et la prsentation des informations l'cran. Dans la mesure du possible, elle doit tre conviviale et ergonomique. la logique applicative, les traitements, dcrivant les travaux raliser par l'application. Ils peuvent tre dcoups en deux familles : r les traitements locaux, regroupant les contrles effectus au niveau du dialogue avec l'IHM, visant essentiellement le contrle et l'aide la saisie,
r
les traitements globaux, constituant l'application elle-mme [JFG99]. Cette couche, appele Business Logic ou couche mtier, contient les rgles internes qui rgissent une entreprise donne [FAS99].
les donnes, ou plus exactement l'accs aux donnes, regroupant l'ensemble des mcanismes permettant la gestion des informations stockes par l'application.
Figure 2.1:Les trois niveaux d'une application informatique [LEF94] Ces trois niveaux peuvent tre imbriqus ou rpartis de diffrentes manires entre plusieurs machines physiques.
Le noyau de l'application est compos de la logique de l'affichage et la logique des traitements. Le dcoupage et la rpartition de ce noyau permettent de distinguer les architectures applicatives suivantes :
q q q q
Nous allons faire un rapide tour des premires architectures, en introduisant progressivement les notions utiles leur comprhension, et nous attarder ensuite plus longuement sur les architectures n-tiers.
suivant: L'architecture un tiers monter: De l'informatique centralise au prcdent: De l'informatique centralise au Table des matires Index Document rdig par Rmi LEBLOND (remi.leblond@free.fr)
L'architecture un tiers
suivant: Le schma du Gartner monter: De l'informatique centralise au prcdent: Les trois niveaux d'abstraction Table des matires Index Sous-sections
q q q q
Prsentation Les solutions sur site central (mainframe) Les applications un tiers dployes Limitations
des applications sur site central, des applications rparties sur des machines indpendantes communiquant par partage de fichiers.
L'architecture un tiers
Figure 3.1:Architecture d'une application sur site central Ce type d'organisation brille par sa grande facilit d'administration et sa haute disponibilit. Il bnficie aujourd'hui d'une large palette d'outils de conception, de programmation et d'administration ayant atteint un niveau de maturit et de fiabilit leur permettant encore de soutenir la comparaison avec des solutions beaucoup plus modernes. De plus, la centralisation de la puissance sur une seule et mme machine permet une utilisation optimale des ressources et se prte trs bien des traitements par lots3.1 (en batch). L'mergence des interfaces utilisateur de type Windows - Macintosh, dmocratises par les outils bureautiques sur micro-ordinateur, a fortement dmod les applications mainframe. Ces dernires exploitaient exclusivement une interface utilisateur en mode caractre juge obsolte par les utilisateurs, qui rclamaient alors massivement une convergence entre la bureautique et le systme d'information de l'entreprise. Le r-habillage d'application centralise, ou revamping3.2, permet de rajeunir ces dernires en leur faisant profiter d'une interface graphique moderne (GUI3.3), mais au prix d'une telle lourdeur3.4 qu'il doit tre considr comme une simple tape vers une architecture plus moderne.
L'architecture un tiers
Ce type de programme est simple concevoir et mettre en oeuvre. Il existe pour cela de nombreux environnements de dveloppement (dBase, Ms Access, Lotus Approach, Paradox... ) qui sont souvent intgrs aux principales suites bureautiques. L'ergonomie des applications mises en oeuvre, base sur celle des outils bureautiques, est trs riche. Ce type d'application peut tre trs satisfaisant pour rpondre aux besoins d'un utilisateur isol et sa mise en oeuvre dans un environnement multi-utilisateur est envisageable. Dans ce contexte, plusieurs utilisateurs se partagent des fichiers de donnes stocks sur un serveur commun. Le moteur de base de donnes est excut indpendamment sur chaque poste client. La gestion des conflits d'accs aux donnes doit tre prise en charge par chaque programme de faon indpendante, ce qui n'est pas toujours vident. Lors de l'excution d'une requte, l'intgralit des donnes ncessaires doit transiter sur le rseau et on arrive vite saturer ce dernier. De plus, la cohabitation de plusieurs moteurs de base de donnes indpendants manipulant les mmes donnes peut devenir assez instable. Il n'est pas rare de rencontrer des conflits lors de la consultation ou de la modification simultane d'un mme enregistrement par plusieurs utilisateurs. Ces conflits peuvent altrer l'intgrit des donnes. Enfin, il est difficile d'assurer la confidentialit des donnes. Ce type de solution est donc rserver des applications non critiques exploites par de petits groupes de travail (une dizaine de personnes au maximum).
Limitations
On le voit, les applications sur site central souffrent d'une interface utilisateur en mode caractres et la cohabitation d'applications micro exploitant des donnes communes n'est pas fiable au del d'un certain nombre d'utilisateurs. Il a donc fallu trouver une solution conciliant les avantages des deux premires :
q q
la fiabilit des solutions sur site central, qui grent les donnes de faon centralise, l'interface utilisateur moderne des applications sur micro-ordinateurs.
Pour obtenir cette synthse, il a fallu scinder les applications en plusieurs parties distinctes et cooprantes :
q q
L'architecture un tiers
suivant: Le schma du Gartner monter: De l'informatique centralise au prcdent: Les trois niveaux d'abstraction Table des matires Index Document rdig par Rmi LEBLOND (remi.leblond@free.fr)
suivant: L'architecture deux tiers monter: De l'informatique centralise au prcdent: L'architecture un tiers Table des matires Index
Figure 4.1:Les diffrents types de client-serveur selon la classification du Gartner Group [LEF94] [JFG99] Sur ce schma, le trait horizontal reprsente le rseau et les flches entre client et serveur, le trafic rseau gnr par la conversation entre client et serveur. Nous verrons par la suite que la vision du Gartner Group, en ne prenant en compte qu'un dcoupage en deux niveaux, est quelque peu limitative. Le Gartner Group distingue les types de client-serveur suivants, en fonction du type de service dport du coeur de l'application : 1. Prsentation distribue : Correspond l'habillage ``graphique'' de l'affichage en mode caractres d'applications fonctionnant sur site central. Cette solution est aussi appele revamping. La classification ``client-serveur'' du revamping est souvent juge abusive, du fait que l'intgralit des traitements originaux est conserve et que le poste client conserve une position d'esclave par rapport au serveur. 2. Prsentation distante : Encore appele client-serveur de prsentation. L'ensemble des traitements est excut par le serveur, le client ne prend en charge que l'affichage. Ce type
d'application prsentait jusqu' prsent l'inconvnient de gnrer un fort trafic rseau et de ne permettre aucune rpartition de la charge entre client et serveur. S'il n'tait que rarement retenu dans sa forme primitive4.1, il connat aujourd'hui un trs fort regain d'intrt avec l'exploitation des standards Internet. 3. Gestion distante des donnes : Correspond au client-serveur de donnes, sans doute le type de client-serveur le plus rpandu. L'application fonctionne dans sa totalit sur le client, la gestion des donnes et le contrle de leur intgrit sont assurs par un SGBD4.2 centralis. Cette architecture, de part sa souplesse, s'adapte trs bien aux applications de type infocentre, interrogeant la base de faon ponctuelle. Il gnre toutefois un trafic rseau assez important et ne soulage pas normment le poste client, qui ralise encore la grande majorit des traitements. 4. Traitement distribu : Correspond au client-serveur de traitements. Le dcoupage de l'application se fait ici au plus prs de son noyau et les traitements sont distribus entre le client et le(s) serveur(s). Le client-serveur de traitements s'appuie, soit un mcanisme d'appel de procdure distante, soit sur la notion de procdure stocke propose par les principaux SGBD du march. Cette architecture permet d'optimiser la rpartition de la charge de traitement entre machines et limite le trafic rseau. Par contre il n'offre pas la mme souplesse que le clientserveur de donnes puisque les traitements doivent tre connus du serveur l'avance. 5. Bases de donnes distribues : Il s'agit d'une variante du client-serveur de donnes dans laquelle une partie de donnes est prise en charge par le client. Ce modle est intressant si l'application doit grer de gros volumes de donnes, si l'on souhaite disposer de temps d'accs trs rapides sur certaines donnes ou pour rpondre de fortes contraintes de confidentialit. Ce modle est aussi puissant que complexe mettre en oeuvre. 6. Donnes et traitements distribus. Ce modle est trs puissant et tire partie de la notion de composants rutilisables et distribuables pour rpartir au mieux la charge entre client et serveur. C'est, bien entendu, l'architecture la plus complexe mettre en oeuvre. Les solutions que nous venons de dtailler sont indpendantes les unes des autres et, de ce fait, combinables volont. Prises individuellement, on peut dire que les deux premires solutions proposes ne correspondent
pas des applications client-serveur. En effet, la prsentation distribue comme l'affichage distant, dans l'application qu'en fait X-Window, ne considrent pas le client en temps que tel et ce dernier reste dans une position d'esclave par rapport au serveur. La premire solution mettre en oeuvre une relation client-serveur se retrouve au troisime niveau et correspond au client-serveur de donnes. Ce type d'application, encore appel client-serveur de premire gnration, met en oeuvre une architecture deux-tiers. Nous allons maintenant nous pencher plus en dtails sur ce type d'application.
suivant: L'architecture deux tiers monter: De l'informatique centralise au prcdent: L'architecture un tiers Table des matires Index Document rdig par Rmi LEBLOND (remi.leblond@free.fr)
suivant: Les architectures distribues monter: De l'informatique centralise au prcdent: Le schma du Gartner Table des matires Index Sous-sections
q q q
Prsentation Le dialogue client-serveur Le Middleware r Dfinition r Les services rendus r Exemples de middleware Limites du client-serveur deux tiers : Le client lourd
Le dialogue client-serveur
Le modle client-serveur met en oeuvre une conversation entre deux programmes que l'on peut opposer l'change fig ``matre-esclave'' qu'entretiennent les applications sur site central avec leurs terminaux passifs [LEF94]. Dans une conversation client-serveur, on distingue donc les deux parties suivantes :
q q
Le client, c'est le programme qui provoque le dialogue, Le serveur, c'est le programme qui se contente de rpondre au client.
Figure 5.1:A la base du dialogue, un besoin du client [LEF94] Le client provoque l'tablissement d'une conversation afin de d'obtenir des donnes ou un rsultat de la part du serveur.
Figure 5.2:Accs aux donnes en mode deux tiers Cet change de messages transite travers le rseau reliant les deux machines. Il met en oeuvre des mcanismes relativement complexes qui sont, en gnral, pris en charge par un middleware.
Le Middleware
Dfinition
On appelle middleware, littralement ``lment du milieu'', l'ensemble des couches rseau et services logiciel qui permettent le dialogue entre les diffrents composants d'une application rpartie. Ce dialogue se base sur un protocole applicatif commun, dfini par l'API5.3 du middleware. Le Gartner Group dfinit le middleware comme une interface de communication universelle entre processus. Il reprsente vritablement la clef de vote de toute application client-serveur. L'objectif principal du middleware est d'unifier, pour les applications, l'accs et la manipulation de l'ensemble des services disponibles sur le rseau, afin de rendre l'utilisation de ces derniers presque transparente.
Conversion : Service utilis pour la communication entre machines mettant en oeuvre des formats de donnes diffrents, elle est prise en charge par la FAP5.4, Adressage : Permet d'identifier la machine serveur sur laquelle est localis le service demand afin d'en dduire le chemin d'accs. Dans la mesure du possible, cette fonction doit faire appel aux services d'un annuaire. Scurit : Permet de garantir la confidentialit et la scurit des donnes l'aide de mcanismes d'authentification et de cryptage des informations. Communication : Permet la transmission des messages entre les deux systmes sans altration. Ce service doit grer la connexion au serveur, la prparation de l'excution des requtes, la rcupration des rsultats et la d-connexion de l'utilisateur.
Le middleware masque la complexit des changes inter-applications et permet ainsi d'lever le niveau des API utilises par les programmes. Sans ce mcanisme, la programmation d'une application client-serveur serait extrmement complexe et rigide.
Figure 5.4:Le middleware par rapport au modle OSI (Open Systems Interconnection)
Exemples de middleware
q
SQL*Net : Interface propritaire permettant de faire dialoguer une application cliente avec une base de donnes Oracle. Ce dialogue peut aussi bien tre le passage de requtes SQL que l'appel de procdures stockes. ODBC5.5 : Interface standardise isolant le client du serveur de donnes. C'est l'implmentation par Microsoft du standard CLI5.6 dfini par le SQL Access Group. Elle se compose d'un gestionnaire de driver standardis, d'une API s'interfaant avec l'application cliente (sous Ms Windows) et d'un driver correspondant au SGBD utilis. DCE5.7 : Permet l'appel des procdures distantes depuis une application.
Le choix d'un middleware est dterminant en matire d'architecture, il joue un grand rle dans la structuration du systme d'information. Les middleware proposs par les fournisseurs de SGBD sont trs performants et permettent de tirer profit de l'ensemble des fonctionnalits du serveur de donnes pour lequel ils ont t conus. Par contre, ils ne permettent pas, le plus souvent, l'accs d'autres sources de donnes. Pour certaines applications devant accder des services htrognes, il est parfois ncessaire de combiner plusieurs middlewares. Dans ce cas, le poste client doit connatre et mettre en oeuvre plusieurs IPC5.8, on en vient la notion de client lourd.
on ne peut pas soulager la charge du poste client, qui supporte la grande majorit des traitements applicatifs, le poste client est fortement sollicit, il devient de plus en plus complexe et doit tre mis jour rgulirement pour rpondre aux besoins des utilisateurs, la conversation entre client et serveur est assez bruyante et s'adapte mal des bandes passantes troites. De ce fait, ce type d'application est souvent cantonn au rseau local de l'entreprise, les applications se prtent assez mal aux fortes montes en charge car il est difficile de modifier l'architecture initiale, la relation troite qui existe entre le programme client et l'organisation de la partie serveur complique les volutions de cette dernire, ce type d'architecture est grandement rigidifi par les cots et la complexit de sa maintenance.
Malgr tout, l'architecture deux tiers prsente de nombreux avantages qui lui permettent de prsenter un bilan globalement positif :
q q q
elle permet l'utilisation d'une interface utilisateur riche, elle a permis l'appropriation des applications par l'utilisateur, elle a introduit la notion d'interoprabilit.
Pour rsoudre les limitations du client-serveur deux tiers tout en conservant ses avantages, on a cherch une architecture plus volue, facilitant les forts dploiements moindre cot. La rponse est apporte par les architectures distribues.
suivant: Les architectures distribues monter: De l'informatique centralise au prcdent: Le schma du Gartner Table des matires Index Document rdig par Rmi LEBLOND (remi.leblond@free.fr)
suivant: L'architecture trois tiers monter: Vers une architecture n-tiers prcdent: L'architecture deux tiers Table des matires Index
L'architecture trois tiers r Objectifs r Les premires tentatives r Le serveur de transaction r La rvolution Internet s Introduction s Les standards d'Internet s HTML (HyperText Markup Langage) s HTTP s TCP/IP (Transmission Control Protocol / Internet Protocol) s CGI (Common Gateway Interface) s Adaptation l'entreprise : Intranet r Rpartition des traitements r Le client lger s Prsentation s Ergonomie s Utilisation d'HTML s Utilisation de Java s Utilisation d'ActiveX s Exemples de clients lgers r Le service applicatif s Prsentation s Gestion des transactions r Limitations Les architectures n-tiers r Prsentation r Que de niveaux...
Le rle de l'approche objet s L'approche objet s Les objets mtier s Les Java Beans s Les EJB (Entreprise Java Beans) s Microsoft OLE-COM-ActiveX La communication entre objets s Principes s L'appel de procdure distantes (RMI) s Le modle CORBA Enfin une vision cohrente du systme d'information
suivant: Les architectures n-tiers monter: Les architectures distribues prcdent: Les architectures distribues Table des matires Index Sous-sections
q q q q
q q
Objectifs Les premires tentatives Le serveur de transaction La rvolution Internet r Introduction r Les standards d'Internet s HTML (HyperText Markup Langage) s HTTP s TCP/IP (Transmission Control Protocol / Internet Protocol) s CGI (Common Gateway Interface) r Adaptation l'entreprise : Intranet Rpartition des traitements Le client lger r Prsentation r Ergonomie s Utilisation d'HTML s Utilisation de Java s Utilisation d'ActiveX r Exemples de clients lgers Le service applicatif r Prsentation r Gestion des transactions Limitations
le frontal est complexe et non standard (mme s'il s'agit presque toujours d'un PC sous Windows), le middleware entre client et serveur n'est pas standard.
La solution rsiderait donc dans l'utilisation d'un poste client simple communicant avec le serveur par le biais d'un protocole standard. Dans ce but, l'architecture trois tiers applique les principes suivants :
q q q
les donnes sont toujours gres de faon centralise, la prsentation est toujours prise en charge par le poste client, la logique applicative est prise en charge par un serveur intermdiaire.
UNIX propose un mcanisme de RPC intgr au systme NFS, NetDDE, puis DCOM de Microsoft permettent l'instauration d'un dialogue RPC entre client et serveur, certains environnements de dveloppement facilitent la rpartition des traitements entre le poste client et le serveur, des solutions propritaires comme ForT ou Implicite permettent l'exploitation d'un serveur d'application par des clients simplement quips d'un environnement d'excution (runtime).
Cependant, l'application de ces technologies dans une architecture trois tiers est complexe et demande des comptences trs pointues, du fait du manque de standards. Malgr ses avantages techniques vidents, ce type d'application fut souvent jug trop coteux mettre en place. Ce premier essai s'est sold par un chec d en grande partie l'absence de standard et la complexit des mcanismes mis en oeuvre.
Le serveur de transaction
Ce type de serveur hberge un moniteur transactionnel qui s'occupe de la mise en relation du client avec un ensemble de serveurs de donnes. Le serveur transactionnel, interrog en utilisant une API unique, masque au client la complexit de l'organisation des serveurs de donnes.
Le moniteur transactionnel permet de garantir que toutes les transactions vrifient la rgle ACID :
q q q q
Atomicit : La transaction ne peut tre partiellement effectue, Cohrence : Une transaction fait passer la base d'un tat cohrent un autre, Isolation : Une transaction n'est pas affecte par le rsultat des autres transactions, Dure : Les modifications dues une transaction sont durablement garanties.
En fait, soit une transaction a dfinitivement eu lieu, soit elle n'a jamais exist. La notion de serveur transactionnel est cite brivement ici car elle correspond, mon avis, une architecture trois tiers puisqu'une partie des traitements applicatifs est centralise.
La rvolution Internet
Introduction
S'il est un phnomne qui a marqu le monde de l'informatique ces dernires annes, c'est bien celui d'Internet. Ce rseau mondial, cr en 1969 par l'arme amricaine, puis utilis par les chercheurs et autres scientifiques, a connu une croissance phnomnale auprs du grand public avec l'introduction du World Wide Web6.2 en 1989. Ce dernier permet de publier simplement des informations richement mises en forme et pouvant mme, par la suite, contenir des donnes multimdia. La vritable rvolution du WWW rside dans son caractre universel, rendu possible par l'utilisation de standards reconnus.
HTML, pour la description des pages disponibles sur le Web, HTTP, pour la communication entre navigateur et serveur Web, TCP/IP, le protocole rseau largement utilis par les systmes Unix, CGI6.3, l'interface qui permet de dclencher distance des traitements sur les serveurs Web.
HTTP
HTTP est un protocole rseau applicatif (dernier niveau du modle OSI) sans connexion utilis pour l'change des donnes sur le Web. En fait, une connexion HTTP est cre pour chaque requte et ne dure que pendant l'excution de cette dernire.
Figure 6.2:Le fonctionnement de base de HTTP[LEF97] Le protocole HTTP, en temps que protocole rseau applicatif, s'appuie sur un protocole de transport indpendant qui, dans le cadre d'Internet, est TCP/IP6.5.
Aucun des mcanismes mis en oeuvre par Internet n'est exempt de dfaut et il est relativement simple de trouver plus performant. En fait, la force de l'ensemble repose essentiellement dans son universalit. La notion d'Intranet est ne de l'intgration des principes d'Internet et des technologies dployes dans l'entreprise :
q q q
on utilise le rseau local de l'entreprise, les donnes sont toujours gres par un SGBD, les mcanismes utiliss pour interroger le SGBD sont toujours les mmes.
premier niveau : l'affichage et les traitements locaux (contrles de saisie, mise en forme de donnes... ) sont pris en charge par le poste client, deuxime niveau : les traitements applicatifs globaux sont pris en charge par le service applicatif, troisime niveau : les services de base de donnes sont pris en charge par un SGBD.
Figure 6.3:Le dcoupage d'une application en pavs fonctionnels indpendants Tous ces niveaux tant indpendants, ils peuvent tre implants sur des machines diffrentes, de ce fait :
q
le poste client ne supporte plus l'ensemble des traitements, il est moins sollicit et peut tre moins volu, donc moins coteux, les resources prsentes sur le rseau sont mieux exploites, puisque les traitements applicatifs peuvent tre partags ou regroups (le serveur d'application peut s'excuter sur la mme machine que le SGBD), la fiabilit et les performances de certains traitements se trouvent amliores par leur centralisation, il est relativement simple de faire face une forte monte en charge, en renforant le service applicatif.
Dans le cadre d'un Intranet, le poste client prend la forme d'un simple navigateur Web, le service applicatif est assur par un serveur HTTP et la communication avec le SGBD met en oeuvre les mcanismes bien connus des applications client-serveur de la premire gnration. Ce type d'architecture fait une distinction nette entre deux tronons de communication indpendants et dlimits par le serveur HTTP :
le premier tronon relie le poste client au serveur Web pour permettre l'interaction avec l'utilisateur et la visualisation des rsultats. On l'appelle circuit froid et n'est compos que de standards (principalement HTML et HTTP). Le serveur Web tient le rle de ``faade HTTP'', le deuxime tronon permet la collecte des donnes, il est aussi appel circuit chaud. Les mcanismes utiliss sont comparables ceux mis en oeuvre pour une application deux tiers. Ils ne franchissent jamais la faade HTTP et, de ce fait, peuvent voluer sans impacter la configuration des postes clients.
Figure 6.4:Rpartition des couches applicatives dans une architecture trois tiers
Le client lger
Prsentation
Dans l'architecture trois tiers, le poste client est communment appel client lger ou Thin Client, par opposition au client lourd des architectures deux tiers. Il ne prend en charge que la prsentation de l'application avec, ventuellement, une partie de logique applicative permettant une vrification immdiate de la saisie et la mise en forme des donnes. Il est souvent constitu d'un simple navigateur Internet. Le poste client ne communique qu'avec la faade HTTP de l'application et ne dispose d'aucune connaissance des traitements applicatifs ou de la structure des donnes exploites. Les volutions de l'application sont donc possibles sans ncessiter de modification de la partie cliente.
Par exemple, un internaute se connectant www.yahoo.fr pour effectuer une recherche provoque, sans mme le savoir, l'excution de traitements sur le serveur. Si ces traitements voluent, ce qui doit arriver relativement souvent, le client continuera utiliser le service sans se rendre compte des changements (sauf s'ils lui apportent de nouveaux services). De plus, ce mme internaute peut se connecter au serveur en utilisant tout type de poste client disposant d'un navigateur compatible HTML (PC sous Windows, Macintosh, Station Unix, WebPhone... ). On voit donc ici la force des architectures trois tiers par rapport au client-serveur de premire gnration. Le dploiement est immdiat, les volutions peuvent tre transparentes pour l'utilisateur et les caractristiques du poste client sont libres.
Ergonomie
Utilisation d'HTML
Les pages HTML, mme avec l'aide de langages de script, sont loin d'atteindre les possibilits offertes par l'environnement Windows :
q q q q q
le multi-fentrage n'est pas facile mettre en oeuvre, le droulement de l'application doit se faire squentiellement, les pages affiches sont relativement statiques, le dveloppement multi-plateforme peut tre contraignant6.8. l'ergonomie de l'application est limite aux possibilits du navigateur.
Pour ces raisons, certaines applications ne sont pas ralisables dans une architecture de type Intranet (infocentres, applications bureautiques... ). Dans les autres cas, l'appauvrissement de l'interface utilisateur est souvent le gage d'une plus grande facilit de prise en main de l'application. Il est rare en effet de devoir suivre une formation pour apprendre se servir d'un site Web particulier. La plupart du temps, une formation gnrale l'ergonomie des sites Web suffit. Cette perte de richesse peut donc se transformer en avantage, condition de respecter une charte graphique et ergonomique cohrente pour toutes les applications Intranet d'une entreprise. Il est possible d'aller au del des possibilits offertes par le langage HTML en y introduisant des applets Java ou des contrles ActiveX. Nous ne parlerons pas ici des modules d'extension du navigateur, encore appels plug-in, qui taient en vogue avant l'arrive des solutions Java et ActiveX, car cette solution est trop contraignante dployer.
Utilisation de Java
Java est un langage de dveloppement orient objet et multi-plateforme introduit par Sun en 1995. Il s'agit de l'adaptation Internet du langage OAK6.9, initialement tudi pour les environnements de petite taille. Il permet, entre autre, d'crire de petites applications, appeles applet, pouvant tre intgres des pages HTML pour en enrichir le contenu.
Le caractre multi-plateforme de Java se prte bien une utilisation sur Internet, o les caractristiques des postes clients ne sont pas matrises. Il repose sur l'utilisation d'un interprteur de pseudo-code Java, pompeusement appel ``machine virtuelle''. Les programmes Java ne sont pas compils en code machine, mais en pseudo-code Java uniquement comprhensible par la machine virtuelle. Cette dernire interprte le code et se charge de lier les modules au moment de l'excution, en les tlchargeant si ncessaire. La liaison dynamique des modules au moment de l'excution permet d'optimiser le trafic rseau, puisqu'on ne charge que le strict ncessaire. Pour ces raisons, un programme Java s'excute plus lentement que son quivalent compil. La compilation la vole des programmes Java et plus encore, la technologie d'optimisation dynamique de code HotSpot de Sun, permettent de rduire l'cart de performance avec des programmes compils. Java propose aujourd'hui une large palette de composants graphiques6.10 et multimdia qui permettent d'atteindre la richesse fonctionnelle des applications Windows. Une applet Java est aussi capable d'exploiter directement un serveur de donnes en utilisant JDBC6.11 ou de faire appel des procdures distantes en utilisant RMI6.12 ou CORBA6.13. Nous verrons ces mcanismes par la suite.
Utilisation d'ActiveX
Quand Microsoft entend parler de ``multi-plateforme'', il comprend ``fonctionnement en dehors de Windows'' et, par extension directe, ``danger''. De ce fait, il ne pouvait rester sans rponse devant le phnomne Java. Aprs avoir essay, sans succs, de confiner Java dans le rle d'un simple langage de programmation dpendant de Windows6.14, Microsoft appuie sa politique Intranet sur sa technologie ActiveX. ActiveX est une adaptation Internet des composants OCX constituant la clef de vote de l'architecture DNA6.15. Les composants ActiveX exploitent les possibilits de Windows et sont donc capables d'offrir une grande richesse fonctionnelle aux applications qui les utilisent. Ils peuvent tre intgrs une page HTML mais, la diffrence des applets Java, ils persistent sur le poste client aprs utilisation. Ils ne sont alors remplacs que si une nouvelle version du composant est utilise. Ce mcanisme permet d'optimiser les transferts de composants sur le rseau mais rappelle grandement l'installation locale d'application, avec ses effets ngatifs sur l'alourdissement du poste client. Les composants ActiveX peuvent communiquer entre eux en utilisant la technologie DCOM6.16 ou avec des bases de donnes, en utilisant ODBC. En fait, l'utilisation des composants ActiveX rend les applications dpendantes de la plateforme Windows. On se prive alors des possibilits offertes par d'autres systmes d'exploitation ou de postes clients plus simples et donc, de la possibilit de faire baisser le cot de possession des postes clients. En prenant du recul, on s'aperoit que l'utilisation d'objets ActiveX dans une application Intranet fait perdre une grande partie de l'intrt de cette architecture et rappelle fortement le client-serveur deux tiers.
un poste Windows quip d'un navigateur HTML, une station rseau du type NC6.17. Contrairement un simple terminal X, ce type de station prend en charge des traitements locaux (affichage, contrle de saisie, mise en forme de donne... ). Ce type de poste client se dmarque par un cot de possession trs largement infrieur celui d'un PC sous Windows. un terminal Windows (NetPC6.18) correspondant un PC minimal.
Le client lger souvent t prsent comme le successeur du PC sous Windows. En fait, le client lger ne prtend pas remplacer tous les PC dans l'entreprise, il se prsente plutt comme une alternative ce dernier pour certains besoins particuliers et cohabite trs bien avec l'existant.
Le service applicatif
Prsentation
Dans une architecture trois tiers, la logique applicative est prise en charge par le serveur HTTP. Ce dernier se retrouve dans la position du poste client d'une application deux tiers et les changes avec le serveur de donnes mettent en oeuvre les mcanismes dj vus dans ce type d'application. Les dveloppements mis en oeuvre sur le serveur HTTP doivent tre conus spcifiquement. Il peuvent mettre en oeuvre :
q q
CGI : le mcanisme standard et reconnu de tous, mais grand consommateur de ressources, NSAPI ou ISAPI : les API de Netscape et Microsoft permettant l'criture d'applications multithread6.19 intgres au serveur HTTP, les scripts serveur comme ASP (Active Server Page pour IIS) ou PHP (l'quivalent pour Apache) sont interprts par le serveur pour gnrer des pages dynamiquement, les servlets Java : qui appliquent le mcanisme des applets aux traitements raliss sur le serveur.
le cheminement de l'utilisateur dans l'application, les actions et saisies de l'utilisateur, l'identit de l'utilisateur, la gestion des transactions.
attribution d'un identifiant chaque tape de la transaction, stockage de l'ensemble du contexte sur le poste client.
q q q
dans un cookie6.20 dpos sur le poste client, dans une URL6.21 longue, dans des variables caches au sein de la page HTML.
Limitations
L'architecture trois tiers a corrig les excs du client lourd en centralisant une grande partie de la logique applicative sur un serveur HTTP. Le poste client, qui ne prend sa charge que la prsentation et les contrles de saisie, s'est trouv ainsi soulag et plus simple grer. Par contre, le serveur HTTP constitue la pierre angulaire de l'architecture et se trouve souvent fortement sollicit et il est difficile de rpartir la charge entre client et serveur. On se retrouve confront aux pineux problmes de dimensionnement serveur et de gestion de la monte en charge rappelant l'poque des mainframes. De plus, les solutions mises en oeuvre sont relativement complexes maintenir et la gestion des sessions est complique. Les contraintes semblent inverses par rapport celles rencontres avec les architectures deux tiers : le client est soulag, mais le serveur est fortement sollicit6.22. Le phnomne fait penser un retour de balancier. Le juste quilibrage de la charge entre client et serveur semble atteint avec la gnration suivante : les architectures n-tiers.
suivant: Les architectures n-tiers monter: Les architectures distribues prcdent: Les architectures distribues Table des matires Index Document rdig par Rmi LEBLOND (remi.leblond@free.fr)
suivant: Index monter: Les architectures distribues prcdent: L'architecture trois tiers Table des matires Index Sous-sections
q q q
Prsentation Que de niveaux... Le rle de l'approche objet r L'approche objet r Les objets mtier s Les Java Beans s Les EJB (Entreprise Java Beans) s Microsoft OLE-COM-ActiveX La communication entre objets r Principes r L'appel de procdure distantes (RMI) r Le modle CORBA Enfin une vision cohrente du systme d'information
elle permet l'utilisation d'interfaces utilisateurs riches, elle spare nettement tous les niveaux de l'application,
q q
elle offre de grandes capacits d'extension, elle facilite la gestion des sessions.
Que de niveaux...
L'appellation ``n-tiers'' pourrait faire penser que cette architecture met en oeuvre un nombre indtermin de niveaux de service, alors que ces derniers sont au maximum trois (les trois niveaux d'une application informatique). En fait, l'architecture n-tiers qualifie la distribution d'application entre de multiples services et non la multiplication des niveaux de service. Cette distribution est facilite par l'utilisation de composants ``mtier'', spcialiss et indpendants, introduits par les concepts orients objets (langages de programmation et middleware). Elle permet de tirer pleinement partie de la notion de composants mtiers rutilisables. Ces composants rendent un service si possible gnrique et clairement identifi. Ils sont capables de communiquer entre eux et peuvent donc cooprer en tant implants sur des machines distinctes. La distribution des services applicatifs facilite aussi l'intgration de traitements existants dans les nouvelles applications. On peut ainsi envisager de connecter un programme de prise de commande existant sur le site central de l'entreprise une application distribue en utilisant un middleware adapt.
Figure 7.1:Evolution des technologies utilises pour la mise en oeuvre d'applications distribues[EL97] Ainsi, les langages de programmation ont tout d'abord t trs proches de la machine (langage machine de bas niveau), puis procduraux et, enfin, orients objets. Le succs du langage Java a vritablement popularis ce mode de programmation. Les protocoles rseau ont suivi le mme type d'volution. Ils furent d'abord trs proches de la couche physique, avec les mcanismes de sockets orients octets. Ensuite, la notion de RPC a permis de faire abstraction des protocoles de communication et, ainsi, a facilit la mise en place d'application client-serveur. Aujourd'hui, l'utilisation d'ORB7.1 permet une totale transparence des appels distants et permet de manipuler un objet distant comme s'il tait local. Le flux d'informations fut donc initialement constitu d'octets, puis de donnes et, enfin, de messages. Les mthodes de conception orientes objet telles qu'UML ou OMT permettent une modlisation plus concrte des besoins et facilitent le passage de la conception la ralisation. Aucune de ces volutions ne constitue en soit une rvolution, mais elles rendent conomiquement ralisables des architectures qui n'taient jusqu' prsent que techniquement envisageables.
Java utilisant des interfaces particulires. Un Java Beans peut tre utilis indpendamment, sous la forme d'une simple applet, ou intgr un dveloppement Java. Il peut dvoiler son comportement ses futurs utilisateurs l'aide :
q q q
des proprits qu'il expose et rend accessible l'aide d'accesseurs, des mthodes qu'il permet d'invoquer, comme tout objet Java, des vnements qu'il peut gnrer pour avertir d'autres composants.
Le mcanisme d'introspection permet une analyse automatique du composant qui, ainsi, s'auto-dcrit. Les Java Beans proposent deux modes de fonctionnement :
q
le mode de configuration permettant de paramtrer l'intgration du composant l'aide d'un outil d'assemblage. Dans ce mode, le Java Beans propose un interface graphique de configuration, le mode d'excution utilis par l'application intgrant le Java Beans.
Les Java Beans sont grs comme tout objet Java, notamment ce qui concerne son cycle de vie. Ils sont livrs sous forme de fichiers JAR7.2.
ils ne comportent pas forcment de partie visible, ils prennent en charge des fonctions de scurit, de gestion des transactions et d'tat, ils peuvent communiquer avec des Java Beans ct client de faon indpendante du protocole (IIOP7.3, RMI7.4, DCOM7.5), ils s'excutent dans un environnement ``Beanstalk'' s'appuyant sur l'API Java Server et offrant des fonctionnalits de gestion de la charge d'excution, de la scurit d'accs, de communication, d'accs aux services transactionnels.
Microsoft OLE-COM-ActiveX
Le modle de communication COM permet de mettre en place une communication oriente objet entre des applications s'excutant sur une mme machine. DCOM est une extension de ce modle pour les architectures distribues. Il repose sur le modle DCE7.6 dfini par l'OSF7.7 et met en oeuvre un serveur d'objets situ sur chaque
machine. Les contrles ActiveX, anciennement dnomms OCX, sont des composants logiciels bass sur le modles COM. Ils peuvent tre intgrs des applications o des documents sous Windows.
Le modle CORBA
Le systme CORBA permet, au travers du protocole IIOP, l'utilisation d'objets structurs dans un environnement htrogne. Cette communication, orchestre par l'ORB, est indpendante des contraintes systmes des diffrentes plates-formes matrielles. Une application accde un objet distant en utilisant une tlcommande locale, appele proxy. Ce proxy lui permet de dclencher les mthodes de l'objet distant l'aide de primitives dcrites avec le langage IDL7.11. L'OMG effectue toute une srie de recommandations connues sous le nom de CORBA services visant proposer des interfaces gnriques pour chaque type de service usuel (nommage, transaction, cycle de vie, ...).
suivant: Index monter: Les architectures distribues prcdent: L'architecture trois tiers Table des matires Index Document rdig par Rmi LEBLOND (remi.leblond@free.fr)
Bibliographie
suivant: propos de ce monter: Vers une architecture n-tiers prcdent: Index Table des matires Index
Bibliographie
19999 Micromax Information Services Ltd. 1999. N-Tiers Background Articles. www.n-tiers.com, Octobre 1999. CN98 Frdric NAJMAN Cdric NICOLAS, Christophe AVARE. Java client-serveur. Eyrolles, 1998. EL97 Thierry RUIZ Emmanuel LIGNE. Corba : Objectifs et architecture. www.etu.info.unicaen.fr/ cliquet/dess/corba/doc-fr/node3.html, Avril 1997. FAS99 Will FASTIE. Du client-serveur aux architectures n-tiers. PC Expert, 1999. Adapt de l'amricain par Laurent DELATTRE. FIA96a Bernard FIAT. CORBA Objectifs et architecture. Computer channel, Septembre 1996. En collaboration avec l'AFPA. FIA96b Bernard FIAT. Le client-serveur (1) : Concepts de base. Computer channel, Septembre 1996. En collaboration avec l'AFPA. Ing98
Bibliographie
Sql Ingenierie. Formation Intranet. SQLI, 1998. INM93 William-H INMON. Le dveloppement des applications clients-serveurs. Masson, 1993. JFG99 Philippe USCLADE Jean-Franois GOGLIN. Du client-serveur au web-serveur. Herms Sciences, 1999. LEF94 Alain LEFEBVRE. L'Architecture client-serveur. Armand COLIN, 1994. LEF97 Alain LEFEBVRE. Intranet client-serveur universel. Eyrolles, 1997. MAR99a Daniel MARTIN. Architecture des applications rparties. http://worldserver2.oleane.com/, Octobre 1999. /dmartin/Architecture applications reparties.htm. MAR99b Daniel MARTIN. Les services d'un middleware. http://worldserver2.oleane.com/, Octobre 1999. dmartin/Middleware. MOR88 Pierre MORVAN. Dictionnaire de l'Informatique. Larousse, 1988. Tri96
Bibliographie
Bud Tribble. Java Computing, l'informatique Java. Sun Microsystem, octobre 1996.
propos de ce document...
monter: Vers une architecture n-tiers prcdent: Bibliographie Table des matires Index
propos de ce document...
Vers une architecture n-tiers This document was generated using the LaTeX2HTML translator Version 99.2beta8 (1.42) Copyright 1993, 1994, 1995, 1996, Nikos Drakos, Computer Based Learning Unit, University of Leeds. Copyright 1997, 1998, 1999, Ross Moore, Mathematics Department, Macquarie University, Sydney. The command line arguments were: latex2html -transparent -image_type gif -local_icons -split 3 -address '
Document rdig par Rmi LEBLOND (remi.leblond@free.fr)' probatoire.tex The translation was initiated by remi on 2001-05-10
http://remi.leblond.free.fr/probatoire/node13.html18/11/2003 11:04:12
Index
suivant: Bibliographie monter: Vers une architecture n-tiers prcdent: Les architectures n-tiers Table des matires
Index
API Dfinition applet Utilisation de Java ASP Prsentation AWT Utilisation de Java bases de donnes distribues Le schma du Gartner batch Les solutions sur site CGI Les standards d'Internet CLI Exemples de middleware client Le dialogue client-serveur client lourd Limites du client-serveur deux client-serveur de donnes | premire gnration | dialogue | conversation | deuxime gnration | distribu client-serveur:de traitements Le schma du Gartner cookie Gestion des transactions CORBA Utilisation de Java | Principes DCE Exemples de middleware | Microsoft OLE-COM-ActiveX DCOM Utilisation d'ActiveX | Les EJB (Entreprise Java
Index
DNA Utilisation d'ActiveX FAP Les services rendus Gartner Group Le schma du Gartner GUI Les solutions sur site HotSpot Utilisation de Java HTML HTML (HyperText Markup Langage) IDL Le modle CORBA IHM Les trois niveaux d'abstraction IIOP Les EJB (Entreprise Java infocentre Le schma du Gartner IPC Exemples de middleware ISAPI CGI (Common Gateway Interface) JAR Les Java Beans Java Utilisation de Java JDBC Utilisation de Java mainframe no title middleware API | API multi-thread Prsentation NC Exemples de clients lgers NC (Network Computer) Exemples de clients lgers
Index
NetPC Exemples de clients lgers NSAPI CGI (Common Gateway Interface) OAK Utilisation de Java ODBC Exemples de middleware OMG Principes ORB L'approche objet | Principes OSF Microsoft OLE-COM-ActiveX PHP Prsentation plug-in Utilisation d'HTML procdure stocke Le schma du Gartner revamping Les solutions sur site RMI Utilisation de Java | Les EJB (Entreprise Java RPC Les premires tentatives serveur Le dialogue client-serveur SGBD Le schma du Gartner SGML HTML (HyperText Markup Langage) socket L'approche objet SQL Prsentation SQL*Net Exemples de middleware SWING Utilisation de Java
Index
TCP/IP HTTP | TCP/IP (Transmission Control Protocol traitement distribu Le schma du Gartner traitement par lots Les solutions sur site URL Gestion des transactions | L'appel de procdure distantes WWW Introduction X-Window Le schma du Gartner