Concepts : Infrastructures des applications Web

Rubriques d'aide

 

Introduction To top of page

L'utilisation d'une infrastructure présente de nombreux avantages lors de l'implémentation d'une application logicielle. Une infrastructure fournit en effet un cadre applicatif réutilisable, capable de gérer un grand nombre d'informations communes à de multiples applications, facilitant ainsi la résolution des problèmes d'implémentation les plus courants. En outre, une infrastructure repose le plus souvent sur un modèle de programmation qui optimise la création d'applications spécifiques. Les infrastructures basées sur le schéma de conception MVC (Modèle Vue Contrôleur), Struts étant la plus connue d'entre elles, sont considérées comme les plus performantes pour les applications Web Java 2 Enterprise Edition (J2EE). Récemment, le comité de normalisation J2EE a publié la spécification JavaServer Faces (JSF) qui fournit une infrastructure MVC offrant des avantages supplémentaires.

Ce document décrit les avantages du schéma de conception MVC et présente les infrastructures Struts et JSF. Il examine leur objectif, énumère leurs avantages et inconvénients, et fournit quelques conseils pour réaliser un choix. Pour finir, il étudie l'intégration des technologies complémentaires Service Data Objects (SDO) et Enterprise JavaBeans (EJB) au sein d'une architecture basée sur ces infrastructures.

 

Schéma de conception MVC (Modèle Vue Contrôleur) To top of page

Le schéma de conception MVC (Modèle Vue Contrôleur) sépare l'interface utilisateur d'une application de sa logique métier en divisant l'architecture applicative en trois couches : le modèle, la vue et le contrôleur. La figure 1 illustre l'architecture MVC des applications Web.

Figure 1 : Architecture MVC des applications Web

Modèle

Le modèle représente l'état de l'application et définit les actions métier qui le modifient (données persistantes et logique métier). Il est possible de vérifier son état (généralement via la vue) et de le modifier (généralement via le contrôleur). Le modèle ne dispose d'aucune information sur la vue ou le contrôleur.

Vue

La vue fournit la présentation du modèle. Elle permet de visualiser l'apparence de l'application, c'est-à-dire son interface utilisateur. C'est la vue qui présente et collecte des données auprès de l'utilisateur. La vue permet de connaître l'état du modèle, mais pas de le modifier.

Contrôleur

Le contrôleur réagit aux entrées de l'utilisateur et informe le modèle qu'il doit changer son état en conséquence. Il traite les requêtes utilisateur entrantes en les distribuant aux fonctions logiques métier appropriées (dans le modèle) et en sélectionnant la réponse renvoyée à l'utilisateur (la vue) en fonction du résultat.

Avantages

La séparation de la présentation et de la logique métier dans le schéma de conception MVC offre les avantages suivants :

  • Maintenabilité améliorée

    Les couches Vue et Modèle étant découplées, il est possible de modifier l'interface utilisateur indépendamment des règles métier et vice-versa. Cela permet de minimiser l'impact des modifications.

  • Réutilisabilité du modèle

    Vous pouvez créer plusieurs vues du même modèle. Si, par exemple, votre application doit prendre en charge différents types de périphérique client (tels que des téléphones cellulaires et des assistants électroniques de poche), vous pouvez créer de nouvelles vues spécifiques de chaque technologie en réutilisant le même modèle.

  • Séparation des responsabilités

    Les rôles de développement peuvent être séparés, permettant ainsi aux différents membres de l'équipe de développement de se concentrer sur leur domaine de compétence. Les concepteurs de pages Web, par exemple, travailleront sur la couche Vue, tandis que les développeurs Java se focaliseront sur l'implémentation des couches Contrôleur et Modèle.

 

Struts To top of page

Struts est une infrastructure qui permet de créer des applications Web dynamiques à l'aide du schéma de conception MVC. Elle regroupe un ensemble de classes Java coopérantes, de servlets et de bibliothèques de balises JavaServer Page (JSP) pouvant servir de base à l'implémentation MVC d'une application basée sur l'architecture Sun J2EE Model 2 :

  • La couche Contrôleur est implémentée par les servlets.
  • La couche Vue est implémentée à l'aide des JSP.
  • La couche Modèle est généralement implémentée à l'aide de Java Beans ou d'Enterprise JavaBeans.

Architecture To top of page

La figure 2 illustre l'implémentation de l'architecture MVC dans Struts ainsi que le flux de traitement d'une requête client.

Figure 2 : Architecture MVC implémentée dans Struts et flux de traitement des requêtes

Composants du contrôleur

Dans une infrastructure Struts, la couche Contrôleur se compose principalement d'un servlet contrôleur frontal, l'ActionServlet, ainsi que des classes ActionForm et Action.

  • ActionServlet

L'ActionServlet reçoit une requête HTTP, appelle les actions demandées sur le modèle et sélectionne la vue suivante à afficher. Il s'agit du composant central de Struts. Une instance de la classe ActionServlet réceptionne toutes les requêtes entrantes. L'ActionServlet définit l'état d'une classe ActionForm à l'aide des champs correspondants de la requête HTTP. Il peut demander à la classe de s'autovalider avant de la diriger vers une classe Action mappée. Les requêtes sont mappées avec les classes Action appropriées à l'aide d'un fichier de configuration (struts-config.xml).

  • ActionForm

La classe ActionForm représente les données de formulaire. L'instance ActionServlet utilise les valeurs provenant du formulaire d'entrée pour remplir automatiquement les propriétés de cette classe, avant de la diriger vers la classe Action demandée. La classe ActionForm est également utilisée pour conserver les données dynamiques du modèle devant être affichées par la vue.

  • Action

La classe Action contient la logique permettant d'appeler la couche Modèle. Lorsqu'elle est exécutée par l'ActionServlet, la classe Action appelle les objets Modèle pour exécuter la logique métier, puis indique au contrôleur ActionServlet la prochaine étape à suivre.

Modèle

Struts ne spécifie pas la technologie à utiliser pour le modèle. Le plus souvent, toutefois, les objets Modèle sont implémentés à l'aide de simples Java Beans ou de composants plus puissants tels que des Enterprise JavaBeans.

Vue

La vue est généralement implémentée à l'aide de JavaServer Pages pour tirer pleinement parti des bibliothèques de balises personnalisées JSP fournies avec l'infrastructure. Les données dynamiques à afficher sont extraites des Java Beans ou des instances de la classe ActionForm créées par la couche Contrôleur. Les balises personnalisées constituent le principal moyen d'accès à ces données.

AvantagesTo top of page

Struts est une infrastructure open source utilisée par une vaste communauté de développeurs. Ses standards sont gérés par l'organisation Apache Software Foundation, dans le cadre du projet Apache. Il s'agit d'une infrastructure extrêmement intéressante, à la fois indépendante des fournisseurs et prise en charge par de nombreux outils de développement. Basé sur le schéma de conception MVC, Struts offre également les avantages suivants :

  • Infrastructure orientée HTTP qui masque les détails du traitement des requêtes HTTP.
  • Infrastructure indépendante des modèles qui permet au développeur d'utiliser la technologie de son choix dans la couche Modèle.
  • Haute configurabilité. Des fichiers de configuration XML permettent de contrôler le flux de l'application, la validation des entrées utilisateur ainsi que le traitement des erreurs.
  • Prise en charge du mécanisme d'internationalisation/localisation par le biais de la classe standard Java ResourceBundles.
  • Intégration des fonctions suivantes d'optimisation de la convivialité :
    • un ensemble complet de bibliothèques de balises personnalisées JSP qui permet de gérer des tâches courantes telles que la manipulation générale des beans, la logique conditionnelle et itérative, ainsi que le rendu HTML ;
    • une sous-architecture de titres qui permet de créer des modèles d'interface utilisateur réutilisables afin de contrôler la présentation et de garantir une conception globale homogène ;
    • l'accès à la bibliothèque de balises standard JSP (JSTL) via le langage Struts EL (Expression Language) pour une réutilisation de code supplémentaire.

RestrictionsTo top of page

Les restrictions suivantes s'appliquent à Struts :

  • Struts est une infrastructure open source dont le support repose sur la communauté des développeurs.
  • Struts est une infrastructure orientée JSP ce qui rend difficile l'utilisation d'une technologie différente pour la couche Vue.
  • Struts ne fournit pas de composant d'interface utilisateur ni de modèle de gestion des événements, éléments indispensables pour créer des interfaces utilisateur Web performantes.

 

JavaServer Faces To top of page

JavaServer Faces (JSF) est une infrastructure qui permet de créer des applications Web Java en utilisant une approche centrée sur l'interface utilisateur. Cette technologie fournit une infrastructure pour développer des applications Web à l'aide d'un modèle de composant d'interface utilisateur standard s'exécutant sur le serveur. Elle a pour but de faciliter le développement d'applications Web en simplifiant le modèle de programmation et en favorisant un développement Web événementiel, orienté interface utilisateur.

Architecture To top of page

JSF est une infrastructure basée sur MVC. Elle fournit une architecture extrêmement performante pour définir les composants d'interface utilisateur et gérer leur état sur le serveur ainsi que les événements générés par le client. Cette infrastructure prend également en charge la validation des entrées utilisateur et le contrôle de la navigation entre les pages. La figure 3 illustre les principaux composants de l'architecture JSF et décrit le flux de traitement d'une requête client.

Figure 3 : Architecture des composants JSF et flux de traitement des requêtes sur les pages

FacesServlet

Le FacesServlet constitue le point d'entrée de toutes les requêtes relatives à une page JavaServer Faces. Il initialise les ressources requises par l'environnement pour contrôler le cycle de vie de la page, puis appelle la page pour traiter la requête. Il agit comme un contrôleur frontal de l'application.

Page JavaServer Faces

Une page JavaServer Faces est une page JSP qui inclut des balises JavaServer Faces pour exprimer tous les composants d'interface utilisateur qu'elle contient. Chaque composant déclare son association de valeur avec une propriété Backing Bean et spécifie tous les détecteurs d'événements, valideurs et convertisseurs requis. L'infrastructure synchronise automatiquement les données d'un composant avec la propriété liée du Backing Bean associé.

Arborescence des composants d'interface utilisateur

Les composants d'interface utilisateur inclus dans la page JSF sont représentés sur le serveur sous forme d'arborescence (également appelée "Vue"). Lorsqu'une requête est traitée par l'infrastructure, cette arborescence est créée (pour une requête initiale sur la page) ou restaurée à partir de son état enregistré (pour les requêtes suivantes sur la page).

Valideur

Un valideur sert à valider les entrées utilisateur. JSF inclut de nombreuses classes de validation standard et permet de créer des classes de validation personnalisées.

Backing Bean

Un Backing Bean est un Java Bean qui contient les données relatives aux composants d'interface utilisateur d'une page JSF et implémente les méthodes prenant en charge leur comportement. Ces méthodes incluent généralement une logique assurant la gestion des événements, ainsi que la validation et le contrôle de navigation. Un Backing Bean appelle généralement des méthodes à partir d'un objet Modèle pour exécuter la logique métier. JSF permet de déclarer tous les Backing Beans utilisés par la page dans le fichier de configuration Faces (face-config.xml). De cette façon, ils seront automatiquement instanciés par le conteneur Web lors du démarrage de l'application (ces beans sont appelés Managed Beans). Le fichier de configuration spécifie également les règles de navigation entre les pages, qui agissent conjointement avec la logique de contrôle de navigation des Backing Beans.

Détecteur d'événements

Un détecteur d'événements est une classe définie par l'utilisateur, conçue pour gérer un type spécifique d'événement généré par un composant. JSF prend en charge trois types d'événement : les événements modifiés (lorsque l'utilisateur, par exemple, modifie la valeur d'un composant), les événements d'action (lorsque l'utilisateur, par exemple, clique sur un bouton) et les événements de modèle de données (lorsque l'utilisateur sélectionne une nouvelle ligne dans un ensemble de données).

Renderer Kit

Un Renderer Kit regroupe les renderers pour un type de client spécifique. Un renderer est une classe qui génère la sortie appropriée pour afficher un composant d'interface utilisateur sur un périphérique client spécifique. JSF fournit un Renderer Kit HTML standard qui génère du code HTML pour afficher un composant et vous permet de créer votre propre kit pour d'autres types de client.

Convertisseur

Un convertisseur permet de convertir un objet en une chaîne de caractères à des fins d'affichage et une chaîne de caractères en objet à des fins de traitement. Il est également utilisé pour appliquer les options de formatage et de localisation choisies.

AvantagesTo top of page

Développée par l'organisation Java Community Process (JCP), JSF est une infrastructure normalisée qui sera intégrée aux prochaines versions de la spécification Java 2 Enterprise Edition(J2EE). En tant que tel, JSF définit le standard officiel en matière de création d'interfaces utilisateur serveur Java. Ses principaux atouts incluent un modèle de programmation simplifié qui facilite le développement d'applications Web, allié à une architecture d'une grande flexibilité qui sépare clairement la logique applicative de la présentation (grâce au schéma MVC). Les avantages suivants dérivent de ces deux atouts majeurs :

  • Développement d'applications RAD

    JSF garantit un déploiement accéléré des applications Web grâce à son modèle de programmation simplifié. Les développeurs peuvent facilement assembler dans une page des composants d'interface utilisateur réutilisables, les connecter aux sources de données de l'application et associer les événements générés par le client aux gestionnaires d'événements serveur. L'infrastructure effectue la synchronisation automatique de l'état des composants et fournit un support complet des tâches de programmation Web courantes, telles que la validation des entrées utilisateur, l'exécution de la logique métier et le contrôle de la navigation entre les pages. En outre, les éditeurs de logiciels sont de plus en plus nombreux à offrir une prise en charge des outils visuels de création d'interfaces utilisateur Web à l'aide de JSF afin d'optimiser la productivité.

  • Maintenabilité

    La séparation réalisée par JSF entre la présentation et le comportement au niveau des composants d'interface utilisateur contribue à répartir les tâches tout en optimisant la maintenabilité :

    o Un concepteur de pages pourra ainsi se concentrer sur l'utilisation d'une balise pour afficher un composant tandis qu'un développeur Java s'attachera à l'implémentation de son comportement. Une fois leur travail terminé, ils pourront rapidement assembler le tout à l'aide du modèle de programmation simplifié de JSF.

    o Les modifications apportées à la présentation d'un composant n'ont aucun effet sur son comportement. Vous pouvez, par exemple, sélectionner une nouvelle balise pour afficher un composant sans pour autant modifier le code sous-jacent.

  • Flexibilité

    JSF offre une grande souplesse en termes de technologie de présentation et de langage de balisage :

    o Le modèle de rendu très flexible de JSF garantit l'indépendance des composants vis-à-vis des périphériques client. L'affichage des composants peut être réalisé avec des langages de balisage autres que le HTML, grâce à l'utilisation de moteurs de rendu spécifiques. Il est de ce fait possible de réutiliser la même logique de composant pour plusieurs types de clients en utilisant différents renderers.

    o JSF fournit une bibliothèque de balises personnalisées JSP pour représenter les composants sur une page JSP. Toutefois, vous pouvez, si vous le souhaitez, opter pour une autre technologie de présentation, la technologie JSF étant directement superposée à l'interface de programmation (API) du servlet.

  • Extensibilité

    Il est possible d'étendre le modèle des composants d'interface utilisateur JSF afin de créer des composants personnalisés. Vous pouvez ainsi créer des composants sophistiqués, tels que des arborescences et des menus, qui permettront d'enrichir les interfaces utilisateur de vos applications Web tout en les rendant plus conviviales.

 

RestrictionsTo top of page

Les restrictions suivantes s'appliquent à JSF :

  • JSF est une nouvelle technologie qui va évoluer au fil du temps.
  • JSF n'intègre aucune fonction de gestion de la présentation permettant de garantir une apparence homogène des pages et de diviser une même page en plusieurs sections pouvant être traitées de façon indépendante.
  • Le développement manuel d'interfaces utilisateur avec JSF s'avère fastidieux, surtout s'il est réalisé sans outils complémentaires. Vous ne bénéficierez réellement de ses avantages en terme de développement d'applications RAD que si vous utilisez conjointement une interface IDE intégrant des outils de conception visuels.

 

Guide de sélection d'une infrastructure To top of page

Nous vous recommandons d'utiliser une infrastructure basée sur l'architecture MVC, ce qui est le cas aussi bien de Struts que de JSF. Ces deux infrastructures intègrent également de nombreuses fonctionnalités communes, telles que la validation des entrées, le traitement des requêtes et la navigation entre les pages. Dans ce cas, comment faire un choix ? Le tableau 1 répertorie les principales fonctions d'une infrastructure et compare la façon dont elles sont prises en charge par Struts et JSF. Nous vous invitons à le consulter pour vous aider à choisir l'infrastructure qui répondra le mieux à vos besoins.

 

  Struts JavaServer Faces
Modèle de programmation
  • Style de traitement des formulaires
  • Style événementiel
Composants d'interface utilisateur et support
  • Composants d'interface utilisateur simples fournis dans une bibliothèque de balises Struts-HTML
  • Liaison des données à un bean ActionForm
  • Composants d'interface utilisateur enrichis
  • Création de composants personnalisés supplémentaires
  • Liaison des données à des Backing Beans ou tout objet Modèle pris en charge
  • Gestion des événements
Indépendance vis-à-vis des périphériques client
  • Non prise en charge
  • Prise en charge via les Renderer Kits
Gestion des erreurs et validation
  • Validation basée sur un fichier XML (validation.xml)
  • Validation à l'aide de nombreux valideurs prédéfinis
  • Création de valideurs personnalisés
Scripts
  • Ecriture de scripts dans des classes Java Action
  • Accès limité des scripts aux données de formulaire uniquement
  • Ecriture de scripts dans des Backing Beans, des classes de modèle et des classes de détection d'événements
  • Association de scripts à des événements
  • Accès des scripts aux composants d'interface utilisateur et à leurs données
Flux de pages
  • Infrastructure sophistiquée et flexible
  • Basé sur un fichier XML
  • Infrastructure sophistiquée et flexible
  • Configuré dans un fichier XML (faces-config.xml)
Gestion des sessions et des états d'objet
  • Manuelle
  • Automatique

Tableau 1 : Comparaison des fonctions prises en charge par Struts et JSF

Notez qu'il est possible d'associer les deux technologies en utilisant une bibliothèque d'intégration Struts-Faces développée dans le cadre du projet Apache (voir #resources -- This hyperlink in not present in this generated websiteRessources). Cette bibliothèque vous permet d'utiliser des composants JSF de votre interface utilisateur Web avec des composants contrôleur, des actions et une logique métier Struts.

A long terme, il est recommandé de privilégier JSF pour les nouveaux projets et de migrer les projets Struts existants vers JSF, ceci pour les raisons suivantes :

  • Contrairement à Struts, JSF permet de développer des interfaces utilisateur Web d'une grande richesse, comblant ainsi enfin les attentes des utilisateurs.
  • Le modèle de programmation simplifié de JSF fournit un haut niveau d'abstraction, pour une productivité optimale. Cela vous permet de penser en termes de composants d'interface utilisateur et d'événements client et non pas en termes de traitement de base "formulaire et champ" comme c'est le cas avec Struts.
  • JSF fournit une solution complète pour créer des applications Web et s'intègre facilement aux technologies émergentes telles que les Service Data Objects (voir #complementary -- This hyperlink in not present in this generated websiteTechnologies complémentaires).
  • De puissants environnements de développement intégré, tels que RAD 6.0, prennent déjà en charge JSF.
  • L'intégration prochaine de JSF à la spécification J2EE contribuera à optimiser le support des outils par de nombreux éditeurs de logiciels.

 

Technologies complémentaires To top of page

Cette section traite de l'intégration des technologies Service Data Objects (SDO) et Enterprise JavaBeans (EJB) à une infrastructure Struts ou JSF, afin d'obtenir une implémentation aussi performante et complète que possible.

Pour plus d'informations sur la technologie EJB, voir ///Principes et conseils : Enterprise JavaBeans (EJB)

 

Service Data Objects To top of page

Service Data Objects est une spécification de modèle de programmation qui permet d'accéder de façon uniforme et déconnectée à des données back-end, indépendamment de la source de données utilisée. Grâce à l'utilisation du modèle, il est possible d'extraire des données à partir de n'importe quelle source de données (base de données relationnelle, EJB Entity, service Web, source de données XML, etc.) et de les présenter avec une grande homogénéité, sous forme de diagramme structuré (DataGraph). SDO se prémunit des opérations déconnectées en préservant l'indépendance du DataGraph extrait vis-à-vis de toute connexion ou transaction back-end. Il s'agit d'une spécification qui a été soumise au JCP via la requête de spécification Java (JSR) n°235.

Architecture

L'architecture SDO utilise une couche d'accès aux données uniforme (Data Mediator Service) pour renvoyer les DataGraphs aux clients à partir de diverses sources de données. La figure 4 illustre les composants de l'architecture SDO.

Figure 4 : Architecture SDO

DataObject

Un DataObject contient les données réelles (valeurs primitives ou ligne de données d'une base de données relationnelle, par exemple) ainsi que les références possibles à d'autres DataObjects. Il contient des informations sur son type, ainsi que les relations et les contraintes qui lui sont associées.

DataGraph

Un DataGraph contient un ensemble de DataObjects et représente généralement l'unité de transfert entre les composants de l'architecture. Il enregistre toutes les modifications apportées aux données, y compris les DataObjects ajoutés, modifiés ou supprimés.

Data Mediator Service

Un Data Mediator Service interagit avec une source de données pour générer des DataGraphs représentant les données. La représentation des données natives est convertie en diagramme SDO par ce service connectable. Le Data Mediator Service applique également à la source de données les modifications apportées à un DataGraph.

 

Applicabilité des infrastructures To top of page

La technologie SDO garantit une intégration aisée des outils et des infrastructures. Dans le cas d'une infrastructure JSF ou de toute autre architecture MVC, les deux cas suivants sont possibles :

Liaison d'un composant d'interface utilisateur à un SDO (JSF)

Dans une infrastructure JSF, les valeurs des composants d'interface utilisateur Web peuvent être liées de façon déclarative à des SDO, à des fins d'extraction de données. Un composant Data Table, par exemple, peut être lié à un SDO afin d'extraire ses valeurs à partir d'une source de données back-end. Cette combinaison facilite la connectivité des données à partir d'un composant d'interface utilisateur, aucune opération de programmation n'étant requise. La figure 5 illustre l'architecture résultant de la liaison de composants d'interface utilisateur JSF à des SDO.

Figure 5 : Utilisation de SDO avec JSF

Objet Modèle et SDO (toute infrastructure MVC)

La couche Modèle d'une infrastructure MVC peut utiliser des SDO pour accéder aux données back-end. La figure 6 illustre un exemple de client modèle qui utilise des SDO pour accéder aux données persistantes avec des EJB Entity. L'objet Modèle utilise les DataGraphs renvoyés par un EJB Stateless Session Façade qui extrait les DataGraphs du Data Mediator Service. Ce dernier agit comme une façade de données pour l'EJB Entity basé sur le système de persistance.

Figure 6 : Utilisation des SDO avec les objets Modèle et les EJB

 

Ressources To top of page

Pour plus d'informations sur les infrastructures et les technologies de composants traitées dans ce document, cliquez sur l'un des liens suivants :

RUP (Rational Unified Process)   2003.06.15