Architecture de Program Mat Ion

Vers une architecture n-tiers

suivant: Table des matires Table des matires Index

Vers une architecture n-tiersRmi LEBLOND ([email protected]) Oral probatoire soutenu le 02/12/1999 15h30

q

q

q

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

http://remi.leblond.free.fr/probatoire/probatoire.html (1 sur 2)18/11/2003 11:03:58

Vers une architecture n-tiers

r

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'informations

q q q

Index Bibliographie propos de ce document...

Document rdig par Rmi LEBLOND ([email protected])

http://remi.leblond.free.fr/probatoire/probatoire.html (2 sur 2)18/11/2003 11:03:58

Introduction

suivant: De l'informatique centralise au monter: Table des matires prcdent: Table des matires Table des matires Index Sous-sectionsq q q

Rappel du sujet Composition du jury Remerciements

Introduction Rappel du sujetLe client-serveur deux niveaux fut, ces dernires annes, la principale solution prconise par les constructeurs d'applications. Ayant acquis de la maturit, l'architecture n-tiers devient aujourd'hui une alternative. Aprs avoir prsent brivement les modles de type un tiers, deux tiers et trois tiers, le candidat s'attardera sur les architectures logicielles n-tiers. Il prsentera les technologies utilises et les moyens mettre en oeuvre. Il dfinira et expliquera les termes clients lgers, clients lourds et middleware. Il tudiera les avantages et les inconvnients des diffrentes architectures. Enfin, il pourra complter son probatoire par la prsentation d'une solution concrte.

Composition du juryq q q q

Prsident du jury : M. Claude KAISER, M. E. MAURICE, M. C. KLEINPETER, M. J. L. STEFFAN.

Remerciements

http://remi.leblond.free.fr/probatoire/node2.html (1 sur 2)18/11/2003 11:04:01

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 ([email protected])


De l'informatique centralise au client-serveur

suivant: Les trois niveaux d'abstraction monter: Vers une architecture n-tiers prcdent: Introduction Table des matires Index

De l'informatique centralise au clientserveurSous-sectionsq q

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

Les trois niveaux d'abstraction d'une application

suivant: L'architecture un tiers monter: De l'informatique centralise au prcdent: De l'informatique centralise au Table des matires Index

Les trois niveaux d'abstraction d'une applicationEn rgle gnrale, une application informatique peut tre dcoupe en trois niveaux d'abstraction distincts :q

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

q

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].

q

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.


Les trois niveaux d'abstraction d'une application

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

l'architecture 1-tiers2.2, l'architecture 2-tiers, l'architecture 3-tiers, les architectures n-tiers.

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 ([email protected])


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-sectionsq q q q

Prsentation Les solutions sur site central (mainframe) Les applications un tiers dployes Limitations

L'architecture un tiers PrsentationDans une application un tiers, les trois couches applicatives sont intimement lies et s'excutent sur le mme ordinateur. On ne parle pas ici d'architecture client-serveur, mais d'informatique centralise. Dans un contexte multi-utilisateurs, on peut rencontrer deux types d'architecture mettant en oeuvre des applications un tiers :q q

des applications sur site central, des applications rparties sur des machines indpendantes communiquant par partage de fichiers.

Les solutions sur site central (mainframe)Historiquement, les applications sur site central furent les premires proposer un accs multiutilisateurs. Dans ce contexte, les utilisateurs se connectent aux applications excutes par le serveur central (le mainframe) l'aide de terminaux passifs se comportant en esclaves. C'est le serveur central qui prend en charge l'intgralit des traitements, y compris l'affichage qui est simplement dport sur des terminaux passifs.



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.

Les applications un tiers dployesAvec l'arrive dans l'entreprise des premiers PC en rseau, il est devenu possible de dployer une application un tiers sur plusieurs ordinateurs indpendants.



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).

LimitationsOn 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

gestion centralise des donnes, gestion locale de l'interface utilisateur.

Ainsi est n le concept du client-serveur.



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 ([email protected])


Le schma du Gartner Group

suivant: L'architecture deux tiers monter: De l'informatique centralise au prcdent: L'architecture un tiers Table des matires Index

Le schma du Gartner GroupLe Gartner Group, un cabinet de consultants amricain, a publi un schma des diffrents types de client-serveur existants.

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 ([email protected])


L'architecture deux tiers

suivant: Les architectures distribues monter: De l'informatique centralise au prcdent: Le schma du Gartner Table des matires Index Sous-sectionsq 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

L'architecture deux tiers PrsentationDans une architecture deux tiers, encore appele client-serveur de premire gnration ou client-serveur de donnes, le poste client se contente de dlguer la gestion des donnes un service spcialis. Le cas typique de cette architecture est l'application de gestion fonctionnant sous Ms-Windows et exploitant un SGBD centralis. Ce type d'application permet de tirer partie de la puissance des ordinateurs dploys en rseau pour fournir l'utilisateur une interface riche5.1, tout en garantissant la cohrence des donnes, qui restent gres de faon centralise. La gestion des donnes est prise en charge par un SGBD centralis, s'excutant le plus souvent sur un serveur ddi. Ce dernier est interrog en utilisant un langage de requte qui, le plus souvent, est SQL5.2. Le dialogue entre client et serveur se rsume donc l'envoi de requtes et au retour des donnes correspondant aux requtes. Ce dialogue ncessite l'instauration d'une communication entre client et serveur. Nous allons tudier de quoi elle se compose.

Le dialogue client-serveurLe 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 MiddlewareDfinitionOn 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.



Figure 5.3:Positionnement du middleware entre client et serveur

Les services rendusUn middleware est susceptible de rendre les services suivants [FIA96b]:q

q

q

q

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 middlewareq

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.

q

q

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.

Limites du client-serveur deux tiers : Le client lourdL'exprience a dmontr qu'il tait coteux et contraignant de vouloir faire porter l'ensemble des traitements applicatifs par le poste client. On en arrive aujourd'hui ce que l'on appelle le client lourd, ou fat client. L'architecture client-serveur de premire gnration s'est heurte ce constat l'heure des premiers bilans :q

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.

q

q

q

q

q

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 ([email protected])


Les architectures distribues

suivant: L'architecture trois tiers monter: Vers une architecture n-tiers prcdent: L'architecture deux tiers Table des matires Index

Les architectures distribuesSous-sectionsq

q

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...


Les architectures distribues

r

r

r

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



L'architecture trois tiers

suivant: Les architectures n-tiers monter: Les architectures distribues prcdent: Les architectures distribues Table des matires Index Sous-sectionsq q 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

L'architecture trois tiers ObjectifsLes limites de l'architecture deux tiers proviennent en grande partie de la nature du client utilis :q q

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.

Les premires tentativesLes premires tentatives de mise en oeuvre d'architecture trois tiers proposaient l'introduction d'un serveur d'application centralis exploit par les postes clients l'aide dialogue RPC6.1 propritaire. Les mcanismes ncessaires la mise en place de telles solutions existent depuis longtemps :q q q

q

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 transactionCe 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.

Figure 6.1:Fonctionnement d'un moniteur transactionnel [EL97]



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 InternetIntroductionS'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.

Les standards d'InternetL'universalit du Web repose sur des standards simples et admis par tous :q q q q

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.

HTML (HyperText Markup Langage)HTML est le langage de description de pages hypertexte utilis par le World Wide Web, il est issu de SGML6.4. Une page HTML est compose de son contenu propre (du texte plus ou moins richement mis en forme) et de rfrences statiques vers d'autres sources d'informations (images, liens vers d'autres documents... ). La consultation d'une page HTML n'implique donc que trs rarement le chargement du seul fichier dcrivant la page, il s'accompagne en gnral de celui de nombreux fichiers annexes. Ces chargements mettent en oeuvre le protocole HTTP.



HTTPHTTP 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.

TCP/IP (Transmission Control Protocol / Internet Protocol)TCP/IP est un protocole rseau de niveau trois et quatre (rseau et transport) qui s'est largement impos sur les systmes Unix, puis sur Internet, et fait aujourd'hui figure de standard universel. Si le fonctionnement de TCP/IP s'adapte bien la topologie et la qualit de service du rseau Internet, on ne peut en dire autant du mariage avec le protocole HTTP. En effet, TCP/IP utilise un mcanisme de ``dmarrage lent'' afin d'viter les engorgements du rseau. Ce mcanisme permet la machine mettrice d'ouvrir progressivement une fentre de congestion en doublant le nombre de paquets mis chaque aller-retour. En gnral, la courte dure des changes HTTP ne permet pas la fentre de congestion d'atteindre la largeur de bande fournie par le rseau local [LEF97].

CGI (Common Gateway Interface)CGI est un standard permettant d'crire des extensions compatibles avec la grande majorit des serveurs HTTP. Ces extensions permettent l'excution d'une action par le serveur la demande d'un client. Ce mcanisme relativement simple, voire mme rustique, entrane l'excution d'un processus propre chaque invocation, ce qui est trs consommateur de ressources. De ce fait, des extensions comme ISAPI6.6, NSAPI6.7 ou les servlets Java sont souvent prfrs au standard CGI.

Adaptation l'entreprise : Intranet



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.

Rpartition des traitementsL'architecture trois tiers, encore appele client-serveur de deuxime gnration ou client-serveur distribu, spare l'application en trois niveaux de service distincts :q

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.

q

q

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.

q

q

q

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 :



q

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.

q

Figure 6.4:Rpartition des couches applicatives dans une architecture trois tiers

Le client lgerPrsentationDans 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.

ErgonomieUtilisation d'HTMLLes 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 JavaJava 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'ActiveXQuand 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.

Exemples de clients lgersLe client lger peut prendre plusieurs formes :



q

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.

q

q

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 applicatifPrsentationDans 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

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.

Gestion des transactionsComme le protocole HTTP n'assure pas de gestion d'tats, les applications transactionnelles doivent grer elles-mmes le contexte utilisateur afin de contrler :q q q q

le cheminement de l'utilisateur dans l'application, les actions et saisies de l'utilisateur, l'identit de l'utilisateur, la gestion des transactions.

Il existe diffrentes mthodes de gestion de contexte :q q

attribution d'un identifiant chaque tape de la transaction, stockage de l'ensemble du contexte sur le poste client.

Ces mthodes ncessitent le stockage d'informations 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.

LimitationsL'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 ([email protected])


Les architectures n-tiers

suivant: Index monter: Les architectures distribues prcdent: L'architecture trois tiers Table des matires Index Sous-sectionsq q 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

Les architectures n-tiers PrsentationL'architecture n-tiers a t pense pour pallier aux limitations des architectures trois tiers et concevoir des applications puissantes et simples maintenir. Ce type d'architecture permet de distribuer plus librement la logique applicative, ce qui facilite la rpartition de la charge entre tous les niveaux. Cette volution des architectures trois tiers met en oeuvre une approche objet pour offrir une plus grande souplesse d'implmentation et faciliter la rutilisation des dveloppements. Thoriquement, ce type d'architecture supprime tous les inconvnients des architectures prcdentes [CN98] :q q

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.

Le rle de l'approche objetL'approche objetLes volutions successives de l'informatique permettent de masquer la complexit des mcanismes mis en oeuvre derrire une approche de plus en plus conceptuelle.



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.

Les objets mtierLes Java BeansSelon les spcifications de Sun, un Java Beans est un composant logiciel rutilisable qui peut tre manipul par un outil d'assemblage. Cette notion assez large englobe aussi bien un simple bouton qu'une application complte. Concrtement, les Java Beans sont des classes



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

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.

Les EJB (Entreprise Java Beans)Les Enterprise Java Beans sont des Java Beans destins s'excuter ct serveur :q q q

q

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-ActiveXLe 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.

La communication entre objetsPrincipesPour permettre la rpartition d'objets entre machines et l'intgration des systmes non objets, il doit tre possible d'instaurer une communication entre tous ces lments. Ainsi est n le concept de middleware objet qui a donn naissance plusieurs spcifications, dont l'architecture CORBA7.8 prconise par l'OMG7.9 et DCOM dveloppe par Microsoft. Ces middlewares sont constitus d'une srie de mcanismes permettant un ensemble de programmes d'interoprer de faon transparente. Les services offerts par les applications serveurs sont prsents aux clients sous la forme d'objets. La localisation et les mcanismes mis en oeuvre pour cette interaction sont cachs par le middleware. La communication entre objets gomme la diffrence entre ce qui est local ou distant. Les appels de mthodes d'objet objet sont traits par un ORB7.10 se chargeant d'aiguiller les messages vers les objets (locaux ou distants). Il est possible d'encapsuler des applications ``non objet'' existantes pour les rendre accessibles via le middleware objet. Ainsi, on prserve l'existant sans alourdir les nouveaux dveloppements, qui ne voient que l'interface de l'application encapsule. La vision du systme s'effectue ainsi de manire unifie, chaque composant tant accessible via le middleware. Un client peut dsormais accder de la mme faon un EJB ou une transaction sur mainframe.

L'appel de procdure distantes (RMI)RMI permet une application Java, s'excutant sur une machine virtuelle, d'invoquer les mthodes d'un objet hberg par une machine distante. Pour cela, le client utilise une reprsentation locale de l'interface de l'objet serveur. Cette reprsentation locale est appele stub et reprsente l'interface de l'objet serveur, appele skeleton. Un objet distribu se caractrise par son interface et son adresse (URL). La mise en relation des objets est assure par un serveur de noms.



Le modle CORBALe 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, ...).

Enfin une vision cohrente du systme d'informationAvec les applications n-tiers, on dispose enfin d'une vision cohrente du systme d'information. Tous les services sont reprsents sous la forme d'objets interchangeables qu'il est possible d'implanter librement, en fonction des besoins. Le potentiel de ce type d'application est trs important et permettrait enfin l'utilisation d'objets mtiers rutilisables. Serions-nous en prsence de l'architecture parfaite, nous permettant de mettre en oeuvre les applications les plus ambitieuses au moindre cot et de les faire voluer librement en fonction des besoins ? Si, sur le papier, on pourrait rpondre par l'affirmative, l'exprience des prcdentes ``rvolutions'' de l'informatique nous pousse plus de modration. L'architecture n-tiers propose effectivement un potentiel norme, reste voir comment il sera utilis, quel cot et, surtout, comment sera gre la transition depuis les environnements actuels.

suivant: Index monter: Les architectures distribues prcdent: L'architecture trois tiers Table des matires Index Document rdig par Rmi LEBLOND ([email protected])


Bibliographie

suivant: propos de ce monter: Vers une architecture n-tiers prcdent: Index Table des matires Index

Bibliographie19999 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 ([email protected])' 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

IndexAPI 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



Documents

Architecture de Program Mat Ion