Les trois patterns les plus courants sont les suivants :
Client Web léger - Utilisé généralement pour les applications Internet, avec peu de contrôle de la configuration
du client. Le client nécessite uniquement un navigateur Web standard, qui prend en charge les formulaires. Toute la
logique métier est exécutée sur le serveur.
Client Web lourd - Une part importante de la logique métier est exécutée sur le client. Généralement, le client
utilise du HTML dynamique, des applets Java ou des contrôles ActiveX pour exécuter la logique métier. La communication
avec le serveur se fait via HTTP.
Diffusion Web - Outre le protocole HTTP pour la communication entre le client et le serveur, d'autres protocoles
(comme IIOP ou DCOM) peuvent être utilisés dans le cadre d'un système d'objets distribués. Le navigateur Web agit comme
un périphérique conteneur et de diffusion pour un système d'objets distribués.
Cette liste n'est bien évidemment pas exhaustive, surtout dans un domaine où la technologie évolue sans cesse.
Toutefois, elle présente les patterns d'architecture les plus courants pour les applications Web. Il est également
possible d'appliquer plusieurs patterns à une même architecture.
Le pattern d'architecture Client Web léger est utile pour les applications Internet, pour lesquelles seule une
configuration client minimale peut être garantie. Toute la logique métier est exécutée sur le serveur lors du
traitement des requêtes de page pour le navigateur client.
Ce pattern est utile pour les applications Web basées sur Internet ou pour les environnements dans lesquels le client
possède peu de puissance de traitement ou aucun contrôle sur sa configuration.
La plupart des applications Internet de commerce électronique utilisent ce pattern, car il ne serait pas judicieux
d'évincer une partie de la clientèle uniquement parce qu'elle ne dispose pas de suffisamment de capacités client. Par
définition, une application de commerce électronique cherche à avoir un public le plus large possible : après tout,
l'argent d'un utilisateur Commodore Amiga a autant de valeur que celui d'un utilisateur Windows NT.
Les principaux composants d'une architecture Client Web léger se trouvent sur le serveur. En fait, il s'agit de
l'architecture d'application Web minimale. Les principaux composants sont les suivants :
Navigateur client - N'importe quel navigateur HTML standard, prenant en charge les formulaires. Le
navigateur fait office de périphérique d'interface utilisateur généralisée. Lorsqu'il est utilisé dans une
architecture Client Web léger, le seul autre service offert par le navigateur est la faculté d'accepter et de
renvoyer des cookies. L'application utilise le navigateur pour demander des pages Web : HTML ou serveur. La page
renvoyée contient une interface utilisateur entièrement mise en forme (texte et contrôles d'entrée), qui est rendue
par le navigateur sur l'écran du client. Toutes les interactions entre l'utilisateur et le système se font via le
navigateur.
Serveur Web - Le principal point d'accès pour tous les navigateurs client. Dans une architecture Client
Web léger, les navigateurs client accèdent au système uniquement par l'intermédiaire du serveur Web, qui
accepte les requêtes de pages Web (pages HTML statiques ou pages serveur). En fonction de la requête, le
serveur Web peut lancer certains traitements côté serveur. Si la requête de page concerne une page de script
serveur ou un module CGI, ISAPI ou NSAPI, le serveur Web délègue le traitement au module exécutable ou à
l'interpréteur de script approprié. Dans tous les cas, le résultat obtenu est une page au format HTML,
affichable dans un navigateur HTML.
Connexion HTTP - Le protocole le plus utilisé entre un navigateur client et un serveur Web.
Cet élément de l'architecture représente un type de communication sans connexion entre le client et le serveur.
Chaque fois que le client et le serveur s'envoient mutuellement des informations, une nouvelle connexion
distincte est établie entre eux. Il est également possible d'utiliser une connexion HTTP sécurisée via Secure
Sockets Layer (SSL). Ce type de connexion crypte les informations transmises entre le client et le serveur, à
l'aide d'une technologie de clé de cryptage publique/privée.
Page HTML - Une page Web avec une interface utilisateur et un contenu, qui ne subit aucun traitement
côté serveur. Ces pages contiennent généralement un texte explicatif (par exemple, des instructions ou de
l'aide) ou des formulaires de saisie HTML. Lorsqu'un serveur Web reçoit une requête pour une page HTML, il
récupère le fichier correspondant et l'envoie, sans aucun filtrage au niveau du client à l'origine de la
requête.
Page serveur - Une page Web qui subit un traitement côté serveur. Généralement, ces pages sont
implémentées sur le serveur en tant que pages de script (pages Active Server Pages, pages Java Server Pages,
pages Cold Fusion), qui sont traitées par un filtre sur le serveur d'application ou par des modules exécutables
(ISAPI ou NSAPI). Ces pages ont potentiellement accès à toutes les ressources côté serveur, y compris les
composants de logique métier, les bases de données, les systèmes traditionnels et les systèmes de compte
fournisseur.
Serveur d'applications - Le principal moteur d'exécution de la logique métier côté serveur. Le serveur
d'applications est chargé de l'exécution du code contenu dans les pages serveur. Il peut être hébergé sur la
même machine que le serveur Web, et peut même s'exécuter dans le même espace de processus que le serveur Web.
D'un point de vue logique, le serveur d'applications est un élément architectural à part, car il se charge
uniquement de l'exécution de la logique métier et peut utiliser une technologie différente de celle du serveur
Web.
La figure ci-dessous montre un diagramme de la vue logique de l'architecture Client Web léger.
Architecture minimale Client Web léger
L'architecture minimale Client Web léger ne dispose pas de certains composants optionnels courants que l'on trouve
généralement dans les applications Web. Notamment, elle n'a pas de base de données. La plupart des applications Web
utilisent une base de données pour le stockage permanent des données métier. Dans certains cas, la base de données peut
également être utilisée pour stocker les pages elles-mêmes (toutefois, cette utilisation de la base de données relève
d'un autre pattern d'architecture). Etant donné que les applications Web peuvent utiliser différentes technologies pour
le stockage permanent des données, ce composant de l'architecture est connu sous un nom plus générique : Persistance.
Le composant Persistance inclut également l'utilisation potentielle d'un moniteur TPM (Transaction Processing Monitor).
Pour connecter une base de données au système, le moyen le plus simple consiste à permettre aux scripts des pages
serveur d'accéder directement au composant Persistance. Ce mécanisme d'accès direct utilise des bibliothèques d'accès
aux données standard comme RDO, ADO, ODBC, JDBC, DBLib, etc. Dans ce cas, les pages serveur sont connues du schéma de
base de données. Pour les systèmes de base de données relationnelle, elles créent et exécutent les instructions SQL
nécessaires pour accéder aux données de la base de données. Pour les applications Web simples et peu volumineuses, cela
peut suffire. Toutefois, pour les systèmes plus robustes et plus vastes, il est préférable d'utiliser une couche
d'objets métier à proprement parler.
Un composant d'objet métier encapsule la logique métier. Ce composant est généralement compilé et exécuté sur le
serveur d'applications. Un des avantages du composant architectural d'objet métier réside dans le fait que les autres
systèmes client/serveur ou Web peuvent utiliser les mêmes composants pour appeler la même logique métier. Par exemple,
un magasin virtuel Internet peut utiliser des pages serveur et le pattern d'architecture Client Web léger pour toutes
les activités liées à l'achat, mais le service de facturation peut nécessiter un accès plus sophistiqué aux données et
à la logique métier et donc utiliser un système client/serveur plutôt qu'un système Web. Le système du service de
facturation peut utiliser les mêmes composants métier sur le même serveur d'applications que le magasin virtuel, tout
en ayant sont propre logiciel client plus sophistiqué.
Etant donné que la base de données relationnelle est le type de base de données le plus courant dans les entreprises
modernes, on trouve généralement un composant architectural supplémentaire entre le serveur d'applications et la base
de données. Ce composant fournit un service de mappage entre les objets et les bases de données relationnelles. Cette
couche de mappage peut être implémentée de différentes manières. Toutefois, nous n'entrerons pas ici dans une
description détaillée de ce composant.
D'autres options souvent ajoutées à ce pattern d'architecture sont l'intégration avec les systèmes traditionnels et,
pour les applications de commerce électronique, un système de compte commercial. Ces deux composants sont accessibles
via les objets métier (ou le serveur d'applications pour les systèmes qui n'ont pas de composant d'objet métier
formel). Un système traditionnel peut être un système de comptabilité ou un système de planification de production. Le
système de compte commercial permet à l'application Web Internet d'accepter et de traiter les paiements par carte de
crédit. De nombreux systèmes de compte commercial sont disponibles sur le marché pour les petites entreprises qui
souhaitent se lancer dans le commerce électronique. Pour les plus grosses entreprises, ce composant prend plutôt la
forme d'une interface avec un système existant capable de traiter les requêtes de carte de crédit.
Avec ces composants facultatifs, la vue logique du pattern d'architecture Client Web léger devient plus complète. Cette
vue logique est illustrée dans la figure ci-dessous.
Vue logique du Client Web léger
La plupart des composants serveur d'une application Web sont également présents dans une application qui n'est pas
basée sur le Web. La conception et l'architecture du système back-end d'une application Web n'est pas sans rappeler la
conception d'un système mainframe ou client/serveur. Web applications employ the use of databases and transaction
processing monitors (TPM) for the same reasons that other systems do. Les EJB (Enterprise Java Beans) et le serveur MTS
(Microsoft Transaction Server) sont de nouveaux outils qui ont été initialement conçus pour les applications Web, mais
qui conviennent également à d'autres architectures applicatives.
L'architecture et la conception des composants serveur d'une application Web sont envisagées de la même manière que
pour n'importe quel système client/serveur. Etant donné que ce pattern d'architecture est conçu pour le Web et les
composants spécifiques aux applications Web, nous n'entrerons pas ici dans une description détaillée des différentes
architectures serveur back-end possibles.
Le principe sous-jacent sur lequel repose la dynamique de ce pattern d'architecture peut se résumer ainsi : la logique
métier est exécutée uniquement en réponse à une demande de page Web émise par le client. Les clients utilisent le
système en demandant des pages Web au serveur Web via le protocole HTTP. Si la page demandée est un fichier HTML qui se
trouve dans le système de fichiers du serveur Web, ce dernier le récupère et l'envoie au client.
S'il s'agit d'une page de script, c'est-à-dire une page contenant du code interprétable qui nécessite un traitement
avant transmission au client, le serveur Web délègue cette action au serveur d'applications. Le serveur d'applications
interprète la page et, si nécessaire, interagit avec des ressources côté serveur, par exemple des bases de données, des
services de messagerie électronique, des systèmes traditionnels, etc. Le code de script a accès, via le serveur Web et
le serveur d'applications, à des informations spécifiques accompagnant la demande de page. Ces informations incluent
notamment des valeurs de champ de formulaire entrées par l'utilisateur, ainsi que des paramètres ajoutés à la demande
de page. Le résultat final est une page HTML correctement mise en forme, prête à être envoyée au client.
La page demandée peut également être un module exécutable, par exemple une DLL ISAPI ou NSAPI. Une DLL, ou bibliothèque
de liens dynamiques, est une bibliothèque compilée qui peut être chargée et exécutée par le serveur d'applications. Le
module a accès aux mêmes informations concernant la demande de page (valeurs de champ de formulaire et paramètres)
qu'une page de script.
Le principe même du comportement dynamique de ce pattern est que la logique métier est uniquement appelée lors du
traitement de la demande de page. Une fois que la demande de page a été traitée, le résultat est envoyé au client
demandeur, et la connexion entre le client et le serveur est rompue. Dans certains cas, le processus métier se poursuit
après exécution de la demande, mais ce n'est pas courant.
Ce type d'architecture convient surtout aux applications pour lesquelles la réponse serveur peut être obtenue dans le
délai raisonnable attendu par l'utilisateur (et avant expiration du délai d'attente configuré sur le navigateur
client). Généralement, ce délai est de l'ordre de quelques secondes. Ce pattern d'architecture n'est donc pas le mieux
adapté pour une application qui doit permettre à l'utilisateur de démarrer et de surveiller un processus métier
susceptible de durer un certain temps. Toutefois, l'utilisation de technologies dites 'push' peut permettre au client
de surveiller des processus longs. En effet, ces technologies reposent sur une interrogation périodique du serveur.
Une autre caractéristique essentielle de ce pattern d'architecture est l'impossibilité de proposer des interfaces
utilisateur sophistiquées. Etant donné que le navigateur est le seul support d'interface utilisateur, tous les objets
fenêtre et contrôles d'interface doivent être disponibles via le navigateur. Or, dans la plupart des navigateurs et en
raison des spécifications HTML, cette interface se limite à quelques boutons et zones de saisie. Toutefois, cette
interface utilisateur réduite à son strict minimum peut également constituer un avantage. En effet, avec une interface
utilisateur très simple, les développeurs ne sont pas tentés de perdre leur temps à créer des "gadgets" alors que des
options d'interface plus standard suffisent.
Le pattern d'architecture Client Web lourd est plus complet que celui du Client Web léger car il utilise des scripts
côté client et des objets personnalisés (par exemple, des contrôles ActiveX et des applets Java). Le pattern Client Web
lourd tire son nom du fait que le client peut exécuter une partie de la logique métier du système, et constitue donc
davantage qu'un simple conteneur d'interface utilisateur générique.
Le pattern d'architecture Client Web lourd convient parfaitement aux applications Web pour lesquelles une certaine
configuration client et une certaine version de navigateur existent, ou pour lesquelles une interface utilisateur
sophistiquée est souhaitée et/ou pour lesquelles une certaine partie de la logique métier peut être exécutée sur le
client. La principale différence entre le client Web léger et le client Web lourd réside dans le rôle du navigateur en
termes d'exécution de la logique métier du système.
Les deux principaux avantages du client Web lourd sont les suivants : une interface utilisateur élaborée et la
possibilité pour le client d'exécuter une partie de la logique métier. Une interface utilisateur sophistiquée peut
permettre par exemple d'afficher et de modifier des modèles 3D, ou d'animer un graphique financier. Dans certains cas,
les contrôles ActiveX peuvent permettre de communiquer avec les dispositifs de surveillance côté client. Par exemple,
un équipement médical capable de mesurer la pression artérielle, la glycémie et d'autres indicateurs vitaux pourrait
être utilisé par un établissement chargé de surveiller de manière quotidienne et à distance des patients éloignés
géographiquement, et qui souhaite se limiter à deux visites à domicile par semaine.
Dans certains cas, la logique métier ne peut être exécutée que côté client. Toutes les données nécessaires à
l'exécution du processus doivent alors être disponibles côté client. Cette logique peut simplement consister à valider
des données entrées. Par exemple, le système peut vérifier l'exactitude des dates, ou les comparer à d'autres dates
(par exemple, la date de naissance ne doit pas être antérieure à la date de la première hospitalisation). En fonction
des règles métier du système, certaines zones sont activées ou non selon les valeurs entrées.
L'utilisation la plus évidente des scripts, applets, contrôles et plug-ins côté client reste l'application Internet,
sous la forme d'interfaces utilisateur sophistiquées. Les scripts java sont souvent utilisés pour changer la couleur ou
l'image associée à un bouton ou à une option de menu sur une page HTML. Les applets Java et les contrôles ActiveX
permettent de créer des contrôles sophistiqués pour les arborescences hiérarchiques.
Le plug-in et le contrôle ActiveX Shockwave est l'un des composants d'interface utilisateur les plus couramment
utilisés sur Internet aujourd'hui. Il permet de créer des animations interactives et de dynamiser les sites Internet
grâce à un graphisme attractif, mais il est également utilisé pour visualiser des simulations ou surveiller des
événements sportifs.
Le contrôle d'agent Microsoft est utilisé par de nombreux sites Internet pour accepter des commandes vocales et
exécuter des actions dans le navigateur, afin d'aider l'utilisateur à naviguer dans le site Web.
En dehors d'Internet, un éditeur de logiciels médicaux a développé une application Web intranet pour gérer les dossiers
des patients et la facturation. L'interface utilisateur basée sur le Web utilise de façon intensive les scripts côté
client pour valider les données et aider l'utilisateur à naviguer sur le site. Outre les scripts, l'application utilise
un certain nombre de contrôles ActiveX pour gérer le contenu XML, principal schéma de codage pour les informations.
Comme pour le pattern Client Web léger, toutes les communications entre le client et le serveur se font via le
protocole HTTP. Etant donné qu'il s'agit d'un type de protocole "sans connexion", il n'y a la plupart du temps pas de
connexion entre le client et le serveur. Le client envoie des informations uniquement lors des demandes de pages. Cela
signifie que les scripts, les contrôles ActiveX et les applets Java côté client ne peuvent interagir qu'avec les objets
qui résident sur le client.
Le pattern Client Web lourd utilise certaines fonctionnalités de navigateur comme les contrôles ActiveX ou les applets
Java, pour exécuter la logique métier sur le client. Les contrôles ActiveX sont des programmes exécutables binaires
compilés qui peuvent être téléchargés vers le client via HTTP, et appelés par le navigateur. Etant donné que les
contrôles ActiveX sont généralement des objets COM, ils ont un contrôle total sur les ressources côté client. Ils
peuvent interagir avec le navigateur, mais aussi avec le système client lui-même. Pour cette raison, les contrôles
ActiveX, surtout sur Internet, sont généralement "authentifiés" par une tierce partie sécurisée.
Les versions récentes des navigateurs HTML classiques prennent également en charge les scripts côté client. Les pages
HTML peuvent donc être incorporées dans des scripts en Java Script ou VB Script. Cette fonctionnalité permet au
navigateur d'exécuter lui-même (ou plutôt, d'interpréter) du code appartenant peut-être à la logique métier du système.
Le terme "peut-être" est utilisé ici pour prendre en compte le fait que souvent, les scripts client contribuent
uniquement à des aspects extérieurs à l'interface utilisateur, et ne font donc pas partie de la logique métier.
Toutefois, quel que soit le cas de figure, les pages HTML peuvent contenir des éléments de grande importance
architecturale (c'est-à-dire, des scripts) qui doivent être repérés comme tels.
Etant donné que le pattern Client Web lourd constitue une extension par rapport au pattern Client Web léger, la plupart
des éléments significatifs d'un point de vue architectural sont les mêmes. Les éléments supplémentaires introduits par
le pattern Client Web lourd sont les suivants :
Script client - Script JavaScript ou Microsoft VirtualBasic incorporé dans une page au format HTML. Le
navigateur interprète le script. Le W3C (organisme de normalisation Internet) a défini le code HTML et
l'interface DOM (Document Object Model) que le navigateur offre aux scripts client.
Document XML - Document au format XML (eXtensible Markup Language). Les documents XML représentent un
contenu (données) sans mise en forme avec interface utilisateur.
Contrôle ActiveX - Objet COM qui peut être référencé dans un script client et "téléchargé" vers le
client si nécessaire. Comme tout objet COM, le contrôle ActiveX bénéficie d'un accès total à toutes les
ressources client. L'authentification et la signature constituent le principal mécanisme de sécurité pour la
protection des machines client. Les navigateurs Internet peuvent être configurés pour ne pas accepter le
téléchargement des contrôles ActiveX vers le client, ou pour prévenir l'utilisateur. Le mécanisme
d'authentification et de signature se contente d'établir l'identité de l'auteur du contrôle, via une tierce
partie sécurisée.
Applet Java - Composant autonome et compilé qui s'exécute dans le contexte d'un navigateur. Pour des
raisons de sécurité, ce composant a un accès limité aux ressources côté client. Les applets Java sont utilisées
en tant qu'éléments sophistiqués d'interface utilisateur, mais aussi à des fins non liées à l'interface
utilisateur, par exemple pour l'analyse de documents XML ou pour l'encapsulation d'une logique métier complexe.
Java Bean - Composant Java qui implémente un certain nombre d'interfaces lui permettant d'être incorporé
facilement à des systèmes plus vastes et complexes. Le terme "bean" (fève ou grain) fait référence à la petite
taille de ce type de composant, et à son objectif unique. Il faut plusieurs grains pour obtenir une tasse de
café. ActiveX est l'équivalent du Java Bean dans les architectures Microsoft.
La figure ci-dessous montre un diagramme de la vue logique de l'architecture Client Web lourd.
Vue logique du pattern d'architecture Client Web lourd
La dynamique du pattern Client Web lourd reprend celle du Client Web léger, à laquelle il faut ajouter la capacité à
exécuter la logique métier sur le client. Comme pour le pattern Client Web léger, toutes les communications entre le
client et le serveur se font lors des demandes de pages. Toutefois, la logique métier peut être exécutée partiellement
sur le client par le biais de scripts, de contrôles et d'applets.
Une page Web envoyée à un navigateur client peut contenir des scripts, des contrôles et des applets. Ces éléments
peuvent être utilisés simplement pour améliorer l'interface utilisateur, mais ils peuvent aussi contribuer à la logique
métier. L'utilisation la plus simple de la logique métier est la validation de zones. Des scripts client peuvent être
utilisés pour vérifier la validité des entrées, non pas dans une seule zone, mais dans toutes les zones d'une page Web
donnée. Par exemple, une application de commerce électronique permettant aux utilisateurs de configurer leurs propres
systèmes informatiques peut utiliser des scripts pour éviter la spécification d'options incompatibles.
Pour utiliser des applets Java et des contrôles ActiveX, il faut les spécifier dans le contenu de la page HTML. Ces
contrôles et ces applets peuvent fonctionner indépendamment des scripts de cette page, ou au contraire être dirigés par
les scripts de la page. Les scripts d'une page HTML peuvent répondre à des événements spéciaux envoyés par le
navigateur. Ces événements peuvent indiquer que le navigateur vient de terminer le chargement de la page Web, ou que la
souris de l'utilisateur vient de s'arrêter sur une zone spécifique de la page.
Ces éléments ont accès à l'interface DOM (Document Object Model) du navigateur. Cette interface est un standard W3C
permettant aux scripts, aux contrôles et aux applets d'accéder au navigateur et au contenu HTML des pages.
L'implémentation de ce modèle pour Microsoft et Netscape est le DHTML (Dynamic HTML). Toutefois, le DHTML représente
davantage qu'une simple implémentation de l'interface DOM : en particulier, le DHTML contient des événements qui, à
l'heure où nous rédigeons cette rubrique, ne sont pas inclus dans la spécification DOM Niveau 1.
Le modèle DOM implémente un certain nombre d'interfaces capables de traiter les documents XML. Le XML est un langage
souple qui permet aux concepteurs de créer leurs propres balises pour un usage spécifique. Par l'intermédiaire d'une
interface DOM, les scripts client peuvent accéder aux documents XML.
L'utilisation du XML comme mécanisme d'échange d'informations entre le client et le serveur nécessite un certain nombre
de composants spéciaux côté client. Des contrôles ActiveX ou des applets Java peuvent être placés sur le client pour
demander et envoyer des documents XML de manière indépendante. Par exemple, une applet Java incorporée dans une page
HTML peut émettre une requête HTTP concernant un document XML, à partir du serveur Web. Le serveur Web identifie et
traite les informations demandées et renvoie un document au format XML (et non HTML). L'applet exécutée dans la page
HTML sur le client accepte alors le document XML, l'analyse et interagit avec le document HTML en cours dans le
navigateur afin d'afficher le contenu pour l'utilisateur. L'intégralité de cette séquence se déroule dans le contexte
d'une même page HTML dans le navigateur client.
Le principal avantage de ce pattern reste la portabilité entre différentes implémentations de navigateur. Tous les
navigateurs HTML ne prennent pas en charge Java Script ou VirtualBasic Script. En outre, seuls les clients Microsoft
Windows peuvent utiliser des contrôles ActiveX. Et même si vous utilisez une seule marque de navigateur client, il
existe des différences subtiles entre chaque implémentation du modèle DOM.
En cas d'utilisation de scripts, de contrôles ou d'applets côté client, l'équipe de test doit exécuter tous les
scénarios de test possibles pour chaque configuration client à prendre en charge. Etant donné que le client exécute de
la logique métier, il doit avoir un comportement cohérent et satisfaisant avec tous les navigateurs concernés. Il ne
faut jamais partir du principe que tous les navigateurs fonctionnent de la même manière. Deux navigateurs différents
peuvent se comporter différemment face au même code source et, pour pousser ce raisonnement encore plus loin, il est
même possible qu'un même navigateur exécuté sur deux systèmes d'exploitation différents présente des différences
de comportement.
Le pattern d'architecture Diffusion Web est ainsi dénommé parce que le Web est utilisé comme principal mécanisme de
diffusion pour un système client/serveur distribué traditionnel. On peut considérer que ce type d'application est en
fait une application client/serveur distribuée qui comprend un serveur Web et un navigateur client parmi ses principaux
composants architecturaux. Qu'il s'agisse d'une application Web avec des objets distribués ou d'un système distribué
avec des éléments Web, le résultat est le même. Etant donné qu'on obtient le même système dans les deux cas et que les
systèmes distribués demandent une modélisation minutieuse, il est évident que les applications Web doivent être
modélisées et conçues de la même manière que n'importe quel autre système logiciel.
Le pattern d'architecture Diffusion Web est particulièrement adapté pour les cas où le contrôle sur les configurations
client et réseau est important. En revanche, il ne convient pas bien aux applications Internet, pour lesquelles le
contrôle sur les configurations client est limité. Ce pattern est également à éviter en cas de communication réseau peu
fiable.
Le principal atout de cette architecture est sa capacité à utiliser des objets métier existants dans le contexte d'une
application Web. Avec une communication directe et permanente entre le client et le serveur, les limites des deux
patterns précédents peuvent être dépassées. Le client peut alors être utilisé pour exécuter une part encore plus
importante de la logique métier.
Ce pattern d'architecture est rarement utilisé seul. Il est généralement combiné à l'un des patterns précédents, voire
aux deux. Le système utilise alors l'un des deux premiers patterns d'architecture (ou les deux) pour les parties qui ne
nécessitent pas une interface utilisateur sophistiquée, ou dans les cas où les configurations client ne peuvent pas
prendre en charge une application volumineuse.
Le site Web CNN Interactive est l'un des sites d'actualités les plus consultés. Dans la plupart des cas, les accès
publics se font via des navigateurs traditionnels, en HTML 3.2. Toutefois, ce site Web comprend un réseau sophistiqué
de navigateurs, de serveurs et d'objets distribués CORBA. Une étude de cas à ce sujet a été publiée dans Distributed
Computing.
Un éditeur de logiciels médicaux a créé une application Web pour gérer les patients, les dossiers médicaux et la
facturation. Le module de facturation du système est utilisé par une petite partie de la communauté globale
d'utilisateurs. La plupart des systèmes de facturation existants ont été écrits en FoxPro. Le nouveau système Web a
donc utilisé le code FoxPro existant et, grâce à des utilitaires de conversion, des documents ActiveX ont été créés
pour l'interface utilisateur et la logique métier. Le résultat est une application Web de type Client Web lourd pour
les dossiers médicaux et la gestion des patients, intégrée à une application Web de type Diffusion Web pour les
opérations de facturation.
La principale différence entre la Diffusion Web et les deux autres patterns d'architecture réside dans le mode de
communication entre le client et le serveur. Les deux premiers patterns utilisent un mécanisme de communication HTTP,
protocole sans connexion qui limite considérablement le concepteur en matière d'interactivité entre l'utilisateur et le
serveur. Les éléments architecturalement significatifs du pattern Diffusion Web sont les mêmes que ceux du Client Web
léger, avec en plus les éléments suivants :
DCOM - Distributed COM est le protocole d'objet distribué de Microsoft. Il permet aux objets d'une
machine d'interagir avec des objets situés sur une autre machine, et d'appeler des méthodes sur ces objets.
IIOP - Le protocole IIOP (Internet Inter-Orb Protocol) est le protocole CORBA d'OMG pour l'interaction
avec des objets distribués sur Internet (ou sur n'importe quel réseau de type TCP/IP).
RMI (JRMP) - La méthode RMI (Remote Method Invocation) permet l'interaction avec des objets situés sur
d'autres machines, dans un environnement Java. Le protocole JRMP (Java Remote Method Protocol) est le protocole
natif pour la méthode RMI, mais il ne s'agit pas nécessairement du seul protocole qu'il est possible
d'utiliser. La méthode RMI peut également être implémentée via le protocole IIOP CORBA.
La figure ci-dessous montre un diagramme de la vue logique de l'architecture Diffusion Web.
Vue logique du pattern architectural Diffusion Web
La principale caractéristique du pattern architectural Diffusion Web est l'utilisation du navigateur dans un système
d'objets distribués. Le navigateur contient une interface utilisateur et certains objets métier qui communiquent,
indépendamment du navigateur, avec des objets sur la couche serveur. Les communications entre le client et le serveur
se font via le protocole IIOP, RMI ou DCOM.
Le principal avantage de l'utilisation d'un navigateur Web dans un système client/serveur distribué réside dans le fait
que le navigateur comprend des fonctionnalités intégrées permettant de télécharger automatiquement les composants
nécessaires à partir du serveur. Ainsi, un ordinateur nouvellement connecté au réseau a simplement besoin d'un
navigateur Web compatible pour commencer à utiliser l'application. Vous n'aurez pas à installer manuellement un
logiciel spécifique sur le client, puisque le navigateur prend cela en charge. Les composants sont fournis et installés
sur le client au fur et à mesure des besoins. Des applets Java et des contrôles ActiveX peuvent être envoyés
automatiquement et mis en cache sur le client. Lorsque ces composants sont activés (lors du chargement de la page Web
appropriée), ils peuvent établir une communication asynchrone avec les objets serveur.
Le principal avantage de ce pattern reste la portabilité entre différentes implémentations de navigateur. Toutefois,
l'utilisation de ce pattern nécessite un réseau robuste. Les connexions entre les objets client et serveur durent
beaucoup plus longtemps que les connexions HTTP et par conséquent, les coupures réseau sporadiques, qui sont sans
conséquence pour les deux autres architectures, posent de sérieux problèmes avec ce pattern.
|