Rubriques

Introduction Haut de la page

Les trois patterns les plus courants sont les suivants :

Client Web léger : principalement utilisé pour les applications Internet, dans lesquelles le contrôle de la configuration client est infime. Le client requiert uniquement un navigateur Web standard (capable d'afficher des formulaires). Toute la logique métier s'exécute sur le serveur.

Client Web lourd : une quantité architecturellement importante de la logique métier est exécutée sur la machine client. Le client utilise généralement du HTML dynamique, des applets Java ou des contrôles ActiveX pour exécuter la logique métier. La communication avec le serveur est toujours assurée via HTTP.

Distribution Web : en plus de l'utilisation du protocole HTTP pour les communications client et serveur, d'autres protocoles, tels que IIOP et DCOM peuvent être employé pour prendre en charge un système objet réparti. Le navigateur Web agit principalement en tant que périphérique de distribution et conteneur pour un système objet réparti.

Cette liste ne peut pas être considérée comme complète, en particulier dans une industrie où la révolution technologique semble de produire annuellement. Elle représente, à un haut niveau, les schémas d'architecture les plus courants des applications Web. Comme avec n'importe quel pattern, il est concevable d'en appliquer plusieurs à une seule architecture.

Client Web léger Haut de la page

Le schéma d'architecture client Web léger est utile pour les applications basées sur Internet, pour lesquelles seule la configuration client minimale peut être garantie. Toute la logique métier s'exécute sur le serveur pendant que les demandes de page sont satisfaites pour le navigateur du client.

Applicabilité Haut de la page

Ce pattern est plus adapté aux applications Web basées sur Internet ou aux environnements dans lesquels le client dispose d'une puissance de calcul minimale ou d'aucun contrôle sur sa configuration.

Utilisations connues Haut de la page

La plupart des applications Internet de commerce électronique utilisent ce pattern, car il n'est pas logique d'éliminer un secteur de clients uniquement parce que sa capacité client s'avère insuffisante. Une application de commerce électronique standard tente d'atteindre le pool de clients 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.

Structure Haut de la page

Les principaux composants du schéma d'architecture client Web léger existent sur le serveur. Par de nombreux aspects, cette architecture représente l'architecture d'application Web minimale. Les principaux composants sont les suivants :

Navigateur client : tout navigateur HTLM capable d'afficher des formulaires standard. Le navigateur agit en tant que périphérique d'interface utilisateur généralisé. Lorsqu'il est utilisé dans une architecture client Web léger, le seul autre service qu'il fournit est la capacité d'accepter et de retourner des cookies. L'utilisateur de l'application se sert du navigateur pour demander des pages Web : HTML ou de serveur. La page renvoyée contient une interface utilisateur totalement formatée, contrôles du texte et des entrées, qui est rendue par le navigateur sur l'écran client. Toutes les interactions utilisateur avec le système se font via le navigateur.

Serveur Web : le point d'accès principal pour tous les navigateurs client. Les navigateurs client de l'architecture client Web léger accèdent au système uniquement via le serveur Web qui accepte les demandes pour les pages Web, de serveur ou HTML statiques. Selon la demande, le serveur Web peut initialiser un traitement côté serveur. Si la demande est celle d'une page de serveur basée sur un script, module CGI, ISAPI ou NSAPI, le serveur Web délègue le traitement à l'interpréteur de script ou au module exécutable approprié. Dans n'importe quel cas cas, le résultat est une page au format HTML, pouvant être rendue par un navigateur HTML.

Connexion HTTP : protocole le plus courant utilisé entre les navigateurs client et les serveurs Web. Cet élément d'architecture représente un type de communication sans connexion entre le client et le serveur. Chaque fois que le client ou le serveur envoie des informations à l'autre, une nouvelle connexion distincte est établie entre les deux. Une variation de connexion HTTP est une connexion HTTP sécurisée via SSL (Secure Sockets Layer). Ce type de connexion crypte les informations transmises entre le client et le serveur, à l'aide de la technologie de clé de chiffrement publique et privée.

Page HTML : une page Web avec interface utilisateur et informations de contenu qui ne passe pas par un traitement côté serveur. Généralement, ces pages contiennent un texte explicatif, tel que des instructions ou des informations d'aide, ou des formulaires d'entrée HTML. Lorsqu'un serveur Web reçoit une demande de page HTML, le serveur extrait simplement le fichier et l'envoie sans filtrage au client demandeur.

Page de serveur : pages Web qui traversent une certaine forme de traitement côté serveur. Généralement, ces pages sont implémentées sur le serveur en tant que pages basées sur des scripts (pages ASP (Active Server Pages), pages JSP (Java Server Pages), pages Cold Fusion) qui sont traitées par un filtre sur le serveur d'applications ou par des modules exécutables (ISAPI ou NSAPI). Ces pages ont potentiellement accès à toutes les ressources côté serveur, y compris des composants logiques métier, des bases de données, des systèmes hérités et des systèmes de comptabilité marchande.

Serveur d'applications : le moteur principal pour l'exécution de la logique métier côté serveur. Le serveur d'application est responsable de l'exécution du code dans les pages de serveur. Il peut se trouver 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. Le serveur d'applications est logiquement un élément d'architecture distinct, du fait qu'il est concerné uniquement par l'exécution de la logique métier et peut utiliser une technologie complètement différente du serveur Web.

La figure ci-dessous montre un diagramme de la vue logique d'architecture client Web léger.

Diagramme détaillé dans le contenu.

Architecture client Web léger minimal

Certains composants courants en option manquent dans l'architecture client Web léger. Ceux-ci se trouvent généralement dans des applications Web, le plus souvent la base de données. La plupart des applications Web utilisent une base de données pour rendre les données métier persistantes. Dans certains cas, la base de données peut être également utilisée pour stocker les pages elles-mêmes (cependant, cette utilisation d'une base de données représente un schéma d'architecture différent). Comme les applications Web peuvent faire appel à un nombre variable de technologies pour rendre des données métier persistantes, le terme le plus générique est utilisé pour libeller le composant d'architecture : persistance. Le composant Persistance inclut également l'utilisation possible d'un moniteur TPM (Transaction Processing Monitor).

Le moyen le plus simple pour connecter une base de données au système est d'accorder aux scripts des pages de serveur un accès direct au composant Persistance. Même cet accès direct utilise des bibliothèques d'accès aux données standard comme RDO, ADO, ODBC, JDBC, DBLib, etc. pour faire le sale travail. Dans ce cas, les pages de serveur sont bien documentées sur le pattern de base de données. Pour les systèmes de base de données relationnelle, ils construisent et exécutent les instructions SQL nécessaires pour obtenir l'accès aux données de la base. Dans les applications Web plus petites et moins compliquées, ceci peut être suffisant. Pour les systèmes plus grands et plus robustes cependant, l'utilisation d'une couche objets métier complète est préférable.

Un composant objet métier encapsule la logique métier. Ce composant est généralement compilé et exécuté sur le serveur d'applications. L'un des avantages que représente le fait d'avoir un composant d'architecture objet métier est que d'autres systèmes client-serveur ou Web peuvent utiliser les mêmes composants pour invoquer la même logique métier. Par exemple, une vitrine de magasin sur Internet peut utiliser des pages de serveur et le schéma d'architecture client Web léger pour toutes les activités client. Cependant, le service de facturation peut nécessiter un accès plus sophistiqué aux données et à la logique métier et préférer utiliser un système client-serveur plutôt qu'un système basé sur le Web. Le système du service de facturation peut utiliser les mêmes composants métier sur le même serveur d'applications que la vitrine Web, et cependant utiliser son propre logiciel client plus sophistiqué.

Comme les bases de données relationnelles sont le type le plus courant de base de données dans l'essentiel des entreprises, un composant d'architecture supplémentaire est généralement présent entre le serveur d'applications et la base de données. Il fournit un service de mappage entre les objets et les bases de données relationnelles. Cette couche de mappage elle-même peut être implémentée de nombreuses façons. Une discussion détaillée de ce composant dépasse la portée de cette page.

D'autres options communément ajoutées à ce schéma d'architecture sont l'intégration à des systèmes existants et pour les applications de commerce électronique, un système de comptabilité marchand. Les deux sont accédés via les objets métier (ou le serveur d'applications pour les systèmes sans composant objet métier formel). Les systèmes existants peuvent représenter un système de comptabilité ou un système de planification de fabrication. Le système de comptabilité marchande permet à une application Web située sur Internet d'accepter et de traiter les paiements par carte de crédit. De nombreux systèmes de comptabilité marchande sont disponibles pour les petites entreprises souhaitant pénétrer le marché en ligne. Pour les entreprises plus grandes, ce composant serait probablement une interface avec un système existant, capable de traiter les demandes de carte de crédit.

Avec ces composants en option en place, la vue logique du schéma d'architecture client Web léger devient plus complète. La vue logique est illustrée à la figure ci-dessous.

Diagramme détaillé dans le contenu.

Vue logique de client Web léger

Un grand nombre des composants serveur d'une application Web se trouvent également dans des applications non basées sur le Web. La conception et l'architecture d'un dorsal d'application Web ne sont pas différentes de la conception d'un grand système ou d'un système client-serveur. Les applications Web utilisent des bases de données et des moniteurs TPM pour les mêmes raisons que d'autres systèmes le font. Les Enterprise JavaBeans (EJB) et Transaction Server (MTS) de Microsoft sont des outils et des technologies qui ont été introduites dans les esprits avec les applications Web, mais sont également adaptés à une utilisation dans d'autres architectures d'application.

L'architecture et la conception des composants côté serveur d'une application Web sont traitées exactement comme celles de n'importe quel système client-serveur. Comme ce schéma d'architecture met l'accent sur le Web et les composants spécifiques au Web, une révision détaillée des architectures de serveur dorsaux possibles est au-delà de la portée de ce pattern.

Dynamique Haut de la page

Le principe sous-jacent de la dynamique de ce schéma d'architecture est que la logique métier n'est exécutée qu'en réponse à une demande de page Web émanant du client. Les clients utilisent le système en demandant des pages Web du serveur Web avec le protocole HTTP. Si la page demandée est un fichier HTML dans le système de fichiers du serveur Web, il va simplement la chercher et la renvoie au client demandeur.

Si la page est une page de script, autrement dit une page comportant un code interprétable devant être traité avant d'être envoyé au client, le serveur Web délègue alors cette action au serveur d'applications. Le serveur d'applications interprète les scripts de la page, et s'il y est invité, interagit avec des ressources côté serveur telles que des bases de données, des services de messagerie, des systèmes existants, etc. Le code basé sur un script a accès, via l'application et le serveur Web, aux informations spéciales accompagnant la demande de page. Ces informations incluent des valeurs de champs de formulaire saisies par l'utilisateur et des paramètres ajoutés à la demande de page. Le résultat final est une page HTML correctement formatée pour le renvoi au client.

La page peut être également un module exécutable, comme une DLL ISAPI ou NSAPI. Une DLL ou bibliothèque de liaison dynamique est une bibliothèque compilée qui peut être chargée et exécutée au moment de l'exécution par le serveur d'applications. Le module a accès aux mêmes détails relatifs à la demande de page (valeurs de champs de formulaire et paramètres) que les pages basées sur un script.

Le point clé du comportement dynamique de ce pattern est que la logique métier n'est invoquée qu'au cours du traitement d'une demande de page. Une fois la demande de page remplie, le résultat est renvoyé au client demandeur et la connexion entre le client et le serveur prend fin. Il est possible pour un processus métier de persister une fois la demande remplie, mais ce n'est pas la norme.

Conséquences Haut de la page

Ce type d'architecture est mieux adapté aux applications dont la réponse du serveur peut être complétée dans le délai de réponse acceptable attendu par l'utilisateur (et dans la valeur de délai autorisée par le navigateur client). C'est généralement de l'ordre de quelques secondes. Il se peut que ce schéma d'architecture ne soit pas le plus approprié si l'application doit permettre à l'utilisateur de démarrer et de contrôler un processus métier qui dure longtemps. L'utilisation de technologies de distribution personnalisée peut cependant être employée pour permettre au client de contrôler des processus de longue durée. Dans la plupart des cas, les technologies de distribution personnalisée font usage d'une interrogation périodique du serveur.

Une autre conséquence majeure de ce schéma d'architecture est la capacité limitée des interfaces utilisateur sophistiquées. Le navigateur agissant comme mécanisme de distribution de l'interface utilisateur complète, tous les widgets et commandes de l'interface utilisateur doivent être disponibles via le navigateur. Dans les navigateurs les plus courants et dans les spécifications HTML, ils se limitent à quelques champs de saisie et boutons. D'un autre côté, certains diront qu'une interface utilisateur aussi réduite est un plus. Rares sont les offres d'interface utilisateur qui empêchent l'équipe de développement de placer leurs efforts sur des interfaces "attrayantes" et "claires", alors que des interfaces plus simples seraient suffisantes.

Client Web lourd Haut de la page

Le schéma d'architecture de client Web lourd étend le pattern de client Web léger par l'utilisation d'objets personnalisés et basés sur des scripts côté client, tels que des contrôles ActiveX et des applets Java. Le pattern de client Web lourd tient son nom du fait que le client peut réellement exécuter une partie de la logique métier du système et ainsi, devenir plus qu'un simple conteneur d'interface utilisateur généralisé.

Applicabilité Haut de la page

Le schéma d'architecture client Web lourd est plus adapté aux applications Web dans lesquelles une certaine configuration client et une version de navigateur peuvent être présumées, lorsqu'une interface utilisateur sophistiquée est souhaitée et/ou une certaine quantité de logique métier peut être exécutée sur le client. La distinction entre les patterns de client Web léger et client Web lourd réside dans le rôle joué par le navigateur dans l'exécution de la logique métier du système.

La capacité d'une interface évoluée et l'exécution client de la logique métier sont deux fortes motivations pour une utilisation de client Web lourd. Une interface utilisateur sophistiquée peut être utilisée pour afficher et modifier des modèles en trois dimensions ou animer un graphique financier. Dans certains cas, le contrôle ActiveX peut être utilisé pour communiquer avec un équipement de contrôle côté client. Par exemple, un équipement de soins médicaux pouvant mesurer la pression artérielle, le taux de sucre ou d'autres signes vitaux peut être utilisé par une agence devant contrôler des patients géographiquement éloignés sur une base quotidienne ainsi réduire les visites personnelles à deux par semaine.

Dans certains cas, la logique métier peut être exécutée sur le client seul. Alors, toutes les données requises pour exécuter le processus doivent être disponibles sur le client. La logique peut être aussi simple que de valider une date saisie. La précision des dates peut être vérifiée ou comparée à d'autres (par exemple, la date de naissance doit être antérieure à celle de la première admission à l'hôpital). En fonction des règles métier du système, certains champs peuvent ou ne peuvent pas être activés, selon les valeurs saisies.

Utilisations connues Haut de la page

Les utilisations les plus évidentes des scripts côté client, des applets, des contrôles et des plug-ins sont sur Internet sous forme d'interfaces évoluées. Les scripts Java sont souvent utilisés pour modifier la couleur ou l'image d'un bouton ou d'une option de menu dans des pages HTML. Les applets Java et les contrôles ActiveX sont souvent utilisés pour créer des contrôles de vue arborescente hiérarchique sophistiquée.

Le contrôle Shockwave ActiveX est l'un des composants d'interface utilisateur les plus courants, utilisés sur Internet aujourd'hui. Il permet des animations interactives et est utilisé principalement pour relever les sites Internet grâce à des graphiques attractifs, mais est également utilisé pour afficher des simulations et surveiller des événements sportifs.

Microsoft Agent Control est utilisé par plusieurs sites Internet pour accepter des commandes vocales et exécuter des actions dans le navigateur qui assistent l'utilisateur navigant dans le site Web.

En dehors d'Internet, un cabinet médical a développé une application intranet basée sur le Web pour gérer les enregistrements des patients et la facturation. L'interface utilisateur basée sur le Web fait un lourd usage des scripts côté client pour effectuer des validations de données et assister l'utilisateur dans la navigation sur le site. Outre les scripts, l'application utilise plusieurs contrôles ActiveX pour gérer le contenu XML qui est utilisé comme principal schéma de codage des informations.

Structure Haut de la page

Toutes les communications entre client et serveur, comme dans le pattern client Web léger, sont réalisées via HTTP. Comme HTTP est un type de protocole "sans connexion", la plupart du temps il n'y a pas de connexion entre le client et le serveur. Le client n'envoie des informations que lors des demandes de page. Ceci signifie que les scripts côté client, les contrôles ActiveX et les applets Java sont limités à l'interaction avec des objets uniquement sur le client.

Le pattern de client Web lourd utilise certaines capacités du navigateur, tels que des contrôles ActiveX ou des applets Java pour exécuter la logique métier sur le client. Les contrôles ActiveX sont compilés, exécutables binaires pouvant être téléchargés au client via HTTP, et invoqués par le navigateur. Du fait que les contrôles ActiveX sont essentiellement des objets COM, ils règnent complètement sur les ressources côté client. Ils peuvent interagir à la fois avec le navigateur, ainsi que le système client lui-même. Pour cette raison, les contrôles ActiveX, en particulier ceux sur Internet, sont généralement "authentifiés" par un tiers digne de confiance.

Les versions les plus récentes des navigateurs HTML courants permettent également les scripts côté client. Des pages HTML peuvent être imbriquées avec les scripts écrits en Java Script ou VB Script. Cette capacité de script permet au navigateur lui-même d'exécuter (ou plutôt d'interpréter) le code qui peut faire partie de la logique métier du système. Le terme "peut" est utilisé du fait qu'il est très courant que les scripts client contribuent uniquement aux aspects externes de l'interface utilisateur, et ne fasse pas réellement partie de la logique métier. Dans l'un ou l'autre cas, des éléments potentiellement architecturalement importants (c'est-à-dire des scripts) imbriqués dans des pages HTML qui doivent être exprimées comme tel.

Comme le pattern de client Web lourd n'est réellement qu'une extension au pattern de client Web léger, la plupart des éléments architecturalement importants sont les mêmes. Les éléments supplémentaires introduits par le pattern de client Web lourd sont les suivants :

Script client : script JavaScript ou Microsoft VirtualBasic imbriqué dans des pages HTML. Le navigateur interprète le script. Le corps de normalisation Internet W3C a défini l'interface du modèle DOM (Document Object Model) et HTML que le navigateur offre aux scripts client.

Document XML : document formaté avec le langage XML (eXtensible Markup Language). Les documents XML représentent le contenu (données) sans formatage de l'interface utilisateur.

Contrôle ActiveX : un objet COM qui peut être référencé dans un script client et "téléchargé" au client si nécessaire. Comme tout objet COM, il dispose d'un accès complet aux ressources client. Le mécanisme de sécurité pour la protection des machines client est assuré par l'authentification et la signature. Des navigateurs Internet peuvent être configurés pour ne pas accepter, ou avertir l'utilisateur lorsque des contrôles ActiveX sont sur le point d'être téléchargés sur le client. Les mécanismes d'authentification et de signature établissent simplement l'identité de l'auteur du contrôle via un tiers digne de confiance.

Applet Java : composant autonome et compilé qui s'exécute dans le contexte d'un navigateur. Pour des raisons de sécurité, son accès aux ressources côté client est limité. Les applets Java sont utilisés comme éléments d'interface utilisateur sophistiquée et pour les tâches d'interface non utilisateur, comme l'analyse de documents XML ou pour encapsuler une logique métier compliquée.

Bean Java : composant Java qui implémente un certain ensemble d'interfaces qui lui permettent d'être facilement intégré dans des systèmes plus grands et plus complexes. Le terme bean reflète la petite nature et l'objectif unique que le composant doit avoir. Une tasse de café pleine nécessite généralement plusieurs grains (bean). ActiveX est le comparse du Java bean dans les architectures centralisées Microsoft.

La figure ci-dessous montre un diagramme de la vue logique d'architecture client Web lourd.

Diagramme détaillé dans le contenu.

Vue logique du schéma d'architecture de client Web lourd

Dynamique Haut de la page

La dynamique du pattern de client Web lourd inclut celle du pattern de client Web léger, plus la capacité d'exécuter la logique métier sur le client. Comme dans le pattern de client Web léger, toutes les communications entre le client et le serveur sont réalisées lors des demandes de pages. La logique métier, cependant peut être partiellement exécutée sur le client avec des scripts, des contrôles ou des applets.

Lorsqu'une page est envoyée au navigateur client, elle peut contenir des scripts, des contrôles et des applets. Ils peuvent être utilisés simplement pour améliorer l'interface utilisateur ou contribuer à la logique métier. Les utilisations de logique métier les plus simples sont des validations de champs. Les scripts client peuvent être utilisés pour vérifier la validité des éléments saisis, non seulement dans un seul champ, mais sur tous les champs d'une page Web donnée. Par exemple, une application de commerce électronique qui permet aux utilisateurs de configurer leurs propres systèmes informatiques peut utiliser des scripts pour empêcher des options incompatibles d'être spécifiées.

Pour pouvoir utiliser des applets Java Applets et des contrôles ActiveX, ils doivent être spécifiés dans le contenu de la page HTML. Ces contrôles et ces applets peuvent fonctionner indépendamment des scripts de la page ou être gérés par ceux-ci. Les scripts contenus dans 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 juste de terminer le chargement de la page Web ou que la souris de l'utilisateur vient de se déplacer sur une région spécifique de la page.

Ils ont accès à l'interface du modèle DOM du navigateur. Cette interface est une norme W3C accordant aux scripts, aux contrôles et aux applets un accès au navigateur et au contenu HTML des pages. L'implémentation Microsoft et Netscape de ce modèle est Dynamic HTML (DHTML). DHTML est bien plus que l'implémentation de l'interface DOM, elle inclut en particulier des événements DHTML qui au moment de la rédaction de ce document ne font pas partie de la spécification DOM de niveau 1.

Au centre du modèle DOM se trouve un ensemble d'interfaces qui traite spécifiquement des documents XML. XML est un langage flexible qui permet aux concepteurs de créer leurs propres balises. L'interface DOM permet aux scripts client d'accéder aux documents XML.

L'utilisation d'XML comme mécanisme standard d'échange d'informations entre client et serveur est activée par l'utilisation de composants spéciaux sur le client. Des contrôles ActiveX ou des applets Java peuvent être placés sur le client pour demander et envoyer indépendamment des documents XML. Par exemple, un applet Java imbriqué dans une page HTML peut constituer une demande HTTP du serveur Web pour un document XML. Le serveur Web trouve et traite les informations demandées et ne renvoie pas de document HTML, mais un document au format XML. L'applet toujours en cours d'exécution dans la page HTML sur le client accepte le document XML, l'analyse et interagit avec le document HTML courant du navigateur pour afficher son contenu à l'utilisateur. La séquence complète commence dans le contexte d'une simple page HTML dans le navigateur client.

Conséquences Haut de la page

De loin, la conséquence la plus importante de ce pattern est la portabilité sur des implémentations de navigateur. La totalité des navigateurs HTML ne prennent pas en charge les scripts Java ou VirtualBasic. en outre, seuls les clients Microsoft Windows peuvent utiliser des contrôles ActiveX. Même lorsqu'une marque spécifique de navigateur client est exclusivement utilisée, il existe des différences subtiles dans les implémentations du modèle DOM.

Lorsque des scripts client, des contrôles ou des applets sont utilisés, l'équipe de testeurs doit implémenter la gamme complète des scénarios de test pour chaque configuration client à prendre en charge. Du fait qu'une logique métier sensible est exécutée sur le client, il est important qu'elle se comporte de manière cohérente et correcte pour tous les navigateurs impliqués. Ne présumez jamais que tous les navigateurs se comportent de la même façon. Non seulement, il est possible que des navigateurs différents se comportent différemment avec le même code source, mais le même navigateur s'exécutant sur des systèmes d'exploitation différents peut montrer un comportement anormal.

Distribution Web Haut de la page

Le schéma d'architecture Distribution Web s'appelle ainsi du fait que le Web est principalement utilisé comme mécanisme de distribution pour un système client-serveur d'objets distribués traditionnel. D'un certain point de vue, ce type d'application est réellement une application client-serveur d'objets distribués qui inclut un serveur Web et un navigateur client comme éléments importants de l'architecture. Qu'un tel système soit une application Web avec des objets distribués ou un système réparti orienté objets avec des éléments Web, le système final est le même. Le fait que ces deux points de vue soient du même système et que les systèmes répartis orientés objets ont toujours été perçus comme des systèmes nécessitant une modélisation particulière, accentue le fait que les applications Web doivent être modélisées et conçues comme tout autre système logiciel.

Applicabilité Haut de la page

Le schéma d'architecture Distribution Web est plus approprié lorsque le contrôle sur les configurations client et réseau est important. Ce pattern n'est pas particulièrement bien adapté aux applications basées sur Internet, dans lesquelles il y a peu ou pas de contrôle sur les configurations client, ou lorsque les communications réseau ne sont pas fiables.

La plus grande force de cette architecture est sa capacité à utiliser des objets métier existants dans le contexte d'une application Web. Avec des communications directes et persistantes possibles entre client et serveur, les limites des deux précédents patterns d'application Web peuvent être dépassées. Le client peut être utilisé pour effectuer une importante logique métier à un degré encore plus élevé.

Il est peu probable que ce schéma d'architecture soit utilisé isolément. Ce pattern, sera plus vraisemblablement associé à un ou plusieurs des patterns précédents. Le système typique utilise un ou plusieurs schémas d'architecture pour ces parties du système qui ne nécessitent pas d'interface utilisateur sophistiquée, ou lorsque les configurations client ne sont pas assez puissantes pour prendre en charge une large application client.

Utilisations connues Haut de la page

Le site Web CNN Interactive est l'un des nouveaux sites les plus occupés sur le Net. La plupart de ses accès publics sont réalisés par des navigateurs conventionnels et au format HTML 3.2 simple. Cependant, derrière le site Web se trouve un réseau sophistiqué de navigateurs, de serveurs et d'objets distribués basés sur CORBA. Une étude de cas de ce système a été publiée Distributed Computing.

Un centre médical a créé une application pour gérer les patients, les enregistrements médicaux et la facturation. Les aspects de facturation du système sont utilisés uniquement par une infime proportion de la communauté globale des utilisateurs. De nombreux systèmes de facturation existants ont té écrits dans FoxPro. Le nouveau système basé sur le Web a utilisé l'ancien code FoxPro existant et via l'utilisation de certains utilitaires de conversion a généré des documents ActiveX pour l'interface utilisateur et la logique métier. Le système résultant est une application Web basée sur un client Web lourd pour les patients et les enregistrements médicaux, intégrée à une application Web basée sur le pattern Distribution Web pour les opérations de facturation.

Structure Haut de la page

La différence la plus importante entre la Distribution Web et les autres schémas d'architecture d'application Web est la méthode de communication entre le client et le serveur. Dans d'autres patterns, le principal mécanisme était HTTP, un protocole sans connexion qui limite grandement le concepteur lorsqu'il en arrive à l'activité interactive entre l'utilisateur et le serveur. Les éléments architecturalement importants dans le pattern Distribution Web incluent tous ceux spécifiés dans le modèle de client Web léger, auxquels s'ajoutent les éléments suivants :

DCOM : (Distributed COM) protocole d'objets distribués Microsoft. Il permet aux objets d'une machine d'interagir et d'invoquer des méthodes sur des objets d'une autre machine.

IIOP : (Internet Inter-Orb Protocol) protocole CORBA du groupe OMG permettant d'interagir avec des objets distribués sur Internet (ou tout réseau TCP/IP).

RMI (JRMP) : (Remote Method Invocation) méthode Java permettatn d'interagir avec des objets sur d'autres machines. JRMP (Java Remote Method Protocol) est le protocole natif pour RMI, mais pas nécessairement le seul protocole pouvant être utilisé. RMI peut être implémenté avec le protocole IIOP de CORBA.

La figure ci-dessous montre un diagramme de la vue logique pour le schéma d'architecture Distribution Web.

Diagramme détaillé dans le contenu.

Vue logique du schéma d'architecture Distribution Web

Dynamique Haut de la page

La dynamique du schéma d'architecture Distribution Web est l'utilisation du navigateur pour fournir un système réparti orienté objets. Le navigateur est utilisé pour contenir une interface utilisateur et des objets métier permettant de communiquer indépendamment du navigateur avec les objets au niveau serveur. Les communications entre les objets client et serveur se produisent avec des protocoles IIOP, RMI et DCOM.

Le principal avantage de l'utilisation d'un navigateur Web dans ce système sinon client-serveur d'objets distribués est que le navigateur dispose de capacités intégrées lui permettant de télécharger automatiquement les composants nécessaires du serveur. Un ordinateur complètement nouveau pour le réseau nécessite uniquement un navigateur Web compatible pour commencer à utiliser l'application. Plusieurs logiciels ne nécessitent pas d'installation manuelle sur le client, du fait que le navigateur gère cela pour l'utilisateur. Les composants sont distribués et installés sur le client selon requis. Des applets Java et des contrôles ActiveX peuvent être automatiquement envoyés et mis en cache sur le client. Lorsque ces composants sont activés (suite au chargement de la page Web appropriée), ils peuvent engager une communication asynchrone avec des objets serveur.

Conséquences Haut de la page

De loin, la plus grosse conséquence de ce pattern est la portabilité sur les implémentations de navigateur. L'utilisation de ce pattern requiert un réseau solide. Les connexions entre les objets client et serveur durent plus longtemps que des connexions HTTP et engendrent ainsi une perte sporadique du serveur, ce qui n'est pas un problème avec les deux autres architectures en est un sérieux à traiter dans ce pattern.



RUP (Rational Unified Process)   2003.06.15