Détails de l'application Web Auction

L'application Web Auction est constituée de plusieurs composants, illustrés dans le diagramme suivant. Ce document n'est pas un tutoriel expliquant comment construire l'application complète. Son rôle est plutôt de décrire certains points de développement et de conception importants, qui tirent parti des différents outils fournis avec le plan de travail, afin que vous puissiez mettre à profit ce que vous apprendrez pour concevoir vos propres applications Web.

Diagramme illustrant les relations entre les données, la logique métier, le contenu Web et les outils.
Comme le montre le diagramme ci-dessus, le contenu Web a été développé en parallèle avec les données et la logique métier (ou applicative). Alors que les concepteurs Web ont créé le style et l'agencement des pages Web, les développeurs Java et de services Web ont codé la logique applicative donnant vie à ces pages. Les sections suivantes décrivent comment ces composants clés ont été créés, ainsi que leur contribution à l'application Web Auction :
  1. Mapper des beans d'entité avec des tables de base de données à l'aide de l'éditeur de mappage d'EJB
  2. Générer une façade de session avec des objets de données SDO à l'aide de l'assistant de création de façade de bean de session
  3. Définir l'agencement du site Web avec l'outil Web Site Designer
  4. Créer des modèles de page Web avec l'outil Page Designer
  5. Ajouter des composants JavaServer Faces aux pages JSP avec l'outil Page Designer
  6. Créer le service Web

Mapper des beans d'entité avec des tables de base de données à l'aide de l'éditeur de mappage d'EJB

Les Enterprise JavaBeans (EJB) offrent aux applications Java un moyen pratique d'accéder aux données stockées dans des bases de données relationnelles. Les beans d'entité peuvent être développés suivant deux approches : BMP (persistance gérée par le bean) ou CMP (persistance gérée par le conteneur). L'approche CMP offre plus de souplesse que le mode BMP, car elle laisse au conteneur d'EJB le soin d'émettre tous les appels spécifiques à la base de données, suivant les directives du bean. Par défaut, les outils disponibles dans le plan de travail Rational génèrent des beans d'entité utilisant l'approche CMP. Les beans CMP ne contiennent pas de code SQL d'accès aux bases de données. Vous pouvez ainsi déployer le bean que vous créez sur différents serveurs J2EE utilisant différents types de bases de données, sans avoir à réécrire son code pour chaque cas.

Le mappage entre objets Java et bases de données relationnelles peut se faire suivant différentes approches : descendante, ascendante et rapprochement à mi-parcours. L'approche descendante consiste à partir d'objets existants, puis à définir des couches intermédiaires de plus en plus détaillées pour aboutir à la conception d'une base de données reflétant les objets existants. L'approche ascendante est le cas inverse : vous partez d'un schéma de base de données existant et vous concevez les couches dépendantes qui définissent les objets reflétant la structure de ce schéma. Enfin, la technique de rapprochement à mi-parcours est ainsi appelée parce qu'elle consiste à partir d'une base de données existante et d'objets existants, puis à développer les couches intermédiaires visant à faire coïncider les objets avec les tables de base de données qui leur correspondent.

Pour développer les EJB d'entité de l'application Auction, nous avons utilisé l'approche ascendante. Nous sommes partis d'une base de données Derby existante, contenant des tables qui correspondaient très précisément aux EJB dont nous avions besoin. Après avoir créé une connexion à la base de données en utilisant l'assistant prévu à cet effet, nous avons utilisé l'assistant de mappage entre EJB et base de données relationnelle (RDB) afin de créer les EJB correspondant à une ou plusieurs tables, à quelques exceptions près. La figure suivante illustre les beans d'entité utilisés dans l'application Auction et leurs interrelations.

Diagramme illustrant les relations entre divers beans d'entité

Le client distant n'accède pas directement aux beans d'entité de l'application Auction. Toutes les demandes et les réponses sont prises en charge par des façades de session, et les beans sont utilisés pour accéder aux données d'arrière-plan. Cela permet la mise en oeuvre, côté serveur, d'un accès partagé au stockage permanent des données. La section suivante décrit les façades de session plus en détail.

Pour plus d'informations sur le mappage des beans d'entité, consultez la rubrique d'aide Génération d'un mappage ascendant.

Générer une façade de session avec des objets de données SDO à l'aide de l'assistant de création de façade de bean de session

La façade de session est l'interface entre le client et le système d'arrière-plan ; elle assure la communication avec les composants SDO (Service Data Object) et, par voie de conséquence, avec la base de données. Une façade de session est utile lorsque le client envoie des demandes nécessitant l'exécution de plusieurs objets. Envoyer ces demandes individuellement à chaque objet aurait pour effet d'augmenter le trafic réseau et les temps d'attente. La façade de session agit donc comme un tampon entre les deux extrémités. Elle reçoit une demande générale du client et envoie des demandes spécifiques aux objets concernés par le traitement de cette demande. Cela réduit le trafic et simplifie le développement du client.

Une fois la façade créée, vous pouvez sélectionner les EJB qu'elle gère en choisissant l'option de mappage d'EJB dans le menu de l'outil. La façade génère les composants SDO nécessaires à partir des beans d'entité sélectionnés. Dans l'application Auction, deux façades sont définies en fonction des deux groupes fonctionnels suivants :
  • La façade système assure l'interface avec les EJB d'arrière-plan spécifiques au système, tels que Category et Role.
  • La façade utilisateur encapsule les données spécifiques à l'utilisateur, telles que Bid, Item et Role.

En groupant les EJB et en utilisant deux façades différentes, vous pouvez accroître les performances de l'application, car les utilisateurs accèdent uniquement aux EJB dont ils ont besoin. Les beans d'entité qui contrôlent la fonction du service Web lui-même (par exemple, Category) sont contrôlés par la façade système.

Les EJB référencés par une façade sont choisis l'un après l'autre à l'aide de l'assistant Créer la façade du bean session, comme illustré ci-après. Si nécessaire, un EJB peut être référencé dans plusieurs façades. Nous n'avons pas eu à le faire dans l'application Auction.

Interface utilisateur de l'assistant Créer la façade du bean session

Vous pouvez étendre les fonctions des façades en leur ajoutant des méthodes. Par exemple, dans la façade utilisateur, une méthode renvoie la liste des utilisateurs sans distinction, tandis qu'une autre renvoie une liste limitée aux utilisateurs actifs. En utilisant ces méthodes comme exemple, vous pourriez ajouter une autre méthode à la façade utilisateur afin de renvoyer la liste de tous les utilisateurs marqués comme inactifs.

Vous trouverez plus d'informations sur les façades de session dans le document "Design Patterns: Session Facade" disponible sur le site http://java.sun.com./.

Définir l'agencement du site Web avec l'outil Web Site Designer

La vue Navigation de l'outil Web Site Designer offre une représentation visuelle de l'agencement du site. Elle montre les pages individuelles et leur organisation hiérarchique. Elle est utile à la maintenance de l'agencement et de l'organisation des pages du site. Lorsque vous faites glisser des pages dans l'éditeur, les contrôles de navigation définis dans le modèle de page sont automatiquement mis à jour. Par exemple, dans le cas de la structure de navigation du site Auction représentée ci-après, vous pourriez changer l'ordre des onglets de navigation en transférant la page Sell avant la page Browse. Web Site Designer génère automatiquement les onglets dans l'ordre correct sur toutes les pages. Pour que vos modifications soient visibles dans l'application en cours d'exécution, réenregistrez chaque page à laquelle le modèle de navigation est appliqué.

Figure montrant les JSP du site Auction dans Web Site Designer.

Outre la vue Navigation décrite plus haut, Web Site Designer comporte une vue Détail présentant les éléments de page organisés dans un tableau éditable (voir l'illustration suivante). Ce tableau facilite la mise à jour des propriétés des pages telles que leur titre, leur auteur et leur libellé de navigation.

Figure présentant la vue Détail de Web Site Designer.

Pour savoir comment gérer l'agencement d'un site Web à l'aide de l'outil Web Site Designer, consultez la rubrique d'aide en ligne "Création d'une structure de site Web".

Créer des modèles de page Web avec l'outil Page Designer

Le plan de travail comporte un outil de conception visuelle qui permet de développer les modèles de page d'un site ainsi que les pages Web elles-mêmes.

Un modèle de page est un ensemble d'éléments de contenu réutilisables qui permettent de donner le même aspect et le même comportement à certaines sections d'un site Web. Pour bénéficier d'une présentation commune et uniforme, les pages Web ont seulement besoin de comporter une référence aux modèles appropriés. Les modèles de page sont bénéfiques à la fois pour les utilisateurs du site, qui peuvent naviguer plus facilement du fait de l'uniformité des pages, et pour les développeurs, qui n'ont pas à réécrire les parties de code communes à toutes les pages.

Les modèles de page facilitent aussi la maintenance du contenu des sites Web. Les modifications apportées à un modèle sont automatiquement reflétées sur toutes les pages qui font référence à ce modèle. Par exemple, dans le cas de l'application Web Auction, le modèle maintemplate.jtpl définit l'agencement général des pages du site Auction. Vous pouvez ajouter des éléments de page Web à un modèle en utilisant la palette dans Page Designer. Sélectionnez un élément dans cette palette et faites-le simplement glisser vers la page Web ou le modèle en cours de conception. Le code HTML correspondant est alors généré automatiquement. Le modèle de page du site Auction pourrait être facilement modifié de cette manière. Vous pourriez, par exemple, ajouter la date et l'heure courantes dans le pied de page.

Les contrôles de navigation sont les éléments clés du modèle de page du site Auction. Dans l'application Web Auction, deux formes de contrôle de navigation sont utilisées :
  • Onglets de navigation : présentent les différentes sections du site Web.
  • Trajets de navigation : indique textuellement à quel endroit du site se trouve le visiteur. Par exemple, Home > Browse > Listing.
Figure montrant les onglets de navigation sur les pages de l'application Auction.

Plutôt que de "coder en dur" les contrôles de navigation, vous pouvez inclure la même barre de navigation dans toutes les pages du site en insérant simplement une balise de référence au modèle. L'éditeur de mappage de modèle insère des références au modèle désigné dans la page Web que vous créez.

Les modèles dynamiques repoussent encore plus loin les limites de cette technologie. Par exemple, sur une page donnée, ils peuvent présenter un contenu différent à l'utilisateur selon son rôle ou ses droits d'accès ou encore insérer des informations qui lui sont propres. Dans l'exemple d'application Auction, des modèles dynamiques sont utilisés pour que la barre de navigation présente des liens aux fonctions d'administration uniquement aux utilisateurs connectés en tant qu'administrateurs, et pour que le bouton "Login" soit remplacé par le libellé "Logout" dès lors que l'utilisateur s'est connecté avec succès.

Pour plus d'informations sur la création de modèles de page Web, consultez la rubrique d'aide correspondante.

Ajouter des composants JavaServer Faces aux pages JSP avec l'outil Page Designer

JavaServer Faces (JSF) est une technologie qui facilite la construction de l'interface utilisateur des applications Web dynamiques prévues pour s'exécuter sur un serveur d'applications. JSF est un langage ouvert qui utilise une bibliothèque de balises standard, naturellement appelée JavaServer Faces. Ces balises sont insérées dans le code HTML pour créer des pages Web dynamiques.

L'infrastructure (framework) JavaServer Faces gère les états de l'interface utilisateur au fil des demandes adressées au serveur et offre un modèle de développement simple pour le traitement des événements côté serveur qui résultent des actions du client. Par exemple, un composant JSF peut avoir un comportement spécifique en réponse à un événement particulier, comme un clic sur un bouton. Page Designer propose dans sa palette une variété de fonctions prédéfinies que vous pouvez faire glisser et déposer sur la page Web que vous créez. Elles facilitent grandement l'utilisation de composants JSF, d'éléments de code HTML et d'autres éléments de scriptage. Grâce à cette palette de composants, vous pouvez non seulement contrôler les fonctions élémentaires d'un champ, par exemple le type de valeur qu'il peut accepter (entier, alphanumérique, etc.), mais aussi le soumettre à des règles de validation. Dans Page Designer, les contrôles JSF peuvent être liés aux données SDO associées à chaque page.

La palette de Page Designer peut être utilisée pour enrichir les pages JSF de nouvelles fonctions. Par exemple, vous pourriez ajouter un bouton "Buy It Now" (Achat immédiat) à la page des détails d'un article pour permettre à un visiteur d'acheter l'article au prix fixé à l'avance par son vendeur, sans passer par le système de montée des enchères.

La figure suivante montre les contrôles JSF de la page du site Auction sur laquelle l'utilisateur peut voir les détails d'un article. Le champ newbid est un composant inputText configuré pour accepter uniquement des entiers, comme en témoigne la case Entier uniquement cochée dans l'angle inférieur droit de la figure. Le champ inputText comporte d'autres propriétés de validation, de comportement et d'accessibilité, définies dans les onglets correspondants, sous l'onglet h:inputText. L'onglet Validation sert à définir des règles de validation spécifiques, codées en Java. Par exemple, pour le champ newbid, la valeur saisie par l'utilisateur est jugée valide uniquement s'il s'agit d'un entier non nul, supérieur à l'enchère de départ (champ startingbid) et à l'enchère en cours (champ currentbid) plus un.

Figure montrant les contrôles JSF utilisés sur la page des détails d'un article en vente sur le site Auction

Le code suivant a été généré pour la validation du champ inputText newbid sur la page itemdetails de l'application Auction.

<h:inputText styleClass="inputText" id="newbid" required="true" size="14">
    <f:convertNumber integerOnly="true" />
    <f:validateLongRange minimum="#{pc_Itemdetail.userFacadeLocalGetFindHighestBidResultBean==null ?
        pc_Itemdetail.userFacadeLocalGetBidItemSDOByKeyResultBean.startingbid :
        pc_Itemdetail.userFacadeLocalGetFindHighestBidResultBean.currentbid+1}">
    </f:validateLongRange>
</h:inputText>

Pour plus d'informations sur le développement de fichiers JSP à base de composants Faces, consultez la rubrique d'aide consacrée à JavaServer Faces.

Créer le service Web

Le service Web a été développé parallèlement à l'application Web car il ne dépend pas de celle-ci. Il constitue un autre moyen d'accéder à la logique applicative et n'inclut pas toutes les fonctionnalités de l'application Web. Consultez la section consacrée au service Web pour une description plus détaillée de cette partie de l'application Auction.

Organisation des projets de l'application Auction

L'application Web Auction se répartit dans plusieurs projets. Chacun remplit un rôle spécifique. La liste suivante décrit chaque projet et son rôle dans l'exemple Auction :
  • Le projet AuctionV60EAR est le principal fichier EAR (Enterprise Archive) qui est déployé sur le serveur d'applications. Il est nécessaire à l'environnement d'exécution.
  • Le projet AuctionV60EJB contient les EJB et les classes des façades de session.
  • Le projet AuctionV60EJBClient contient le code généré, y compris les classes SDO. Il est déployé sur le client.
  • Le projet AuctionV60Web contient tous les fichiers JSF, le modèle de page et la logique applicative nécessaire à l'exécution des fichiers JSF.
  • Le projet AuctionV60WebService contient les fichiers WSDL du service Web ainsi que ses sources Java.
  • Les projets OIDGenerator et OIDGeneratorClient servent à la création de nouvelles clés lors des insertions dans la base de données.
Sujet parent : Application Web Auction

Vos commentaires