|
L'exemple d'application Web Auction a été développé à l'aide de Software
Development Platform (SDP), version 6.0. Ce document identifie les principaux blocs de
construction de l'application Web Auction, qui sont illustrés dans le diagramme
ci-après.

L'application Web Auction contient de nombreux composants. Il ne s'agit pas
d'un tutoriel sur la manière de créer l'intégralité de l'application. Par contre, ce
document met en évidence les points importants de développement et de conception qui
permettent d'optimiser les différents outils fournis avec le plan de travail, de sorte
que vous puissiez appliquer ces connaissances à vos propres applications Web.
Comme illustré dans le précédent diagramme, le contenu Web a été
développé en parallèle avec les données et la logique métier. Les concepteurs ont
développé le style et la présentation des pages Web, tandis que les développeurs de
services Web et Java ont codé la logique métier permettant de piloter ces pages. Les
sections suivantes décrivent comment ces principaux composants ont été créés, ainsi que
leur contribution à l'application Web Auction :
- Mappage des beans entity aux tables de base de données à l'aide de l'éditeur de mappage des EJB
- Génération d'une façade de session avec des objets de données SDO à l'aide de l'assistant de génération de façade de bean session
- Définition de la présentation du site Web à l'aide de Web Site Designer
- Création de modèles de page Web à l'aide de Page Designer
- Ajout de composants JavaServer Faces à des pages JSP à l'aide de Page Designer
- Création d'une interface graphique Swing à l'aide de l'éditeur visuel Java
- Création du service Web
Mappage des beans entity aux tables de base de données à l'aide de l'éditeur de mappage des EJB
Les EJB (Enterprise JavaBeans) constituent un moyen pratique pour les applications Java d'accéder aux données stockées dans les bases de données relationnelles. Les
beans entity peuvent être développés à l'aide de beans BMP (bean-managed persistence) ou
CMP (container-managed persistence). Les beans CMP permettent une plus grande
flexibilité que les beans BMP car le conteneur d'EJB effectue tous les appels spécifiques
à la base de données, suivant les instructions du bean. Par défaut, les outils du plan de
travail Rational génèrent des beans entity à l'aide de beans CMP.
Le bean entity CMP ne contient pas de code SQL d'accès. Cela permet de déployer le bean
sur les autres serveurs J2EE qui utilisent des bases de données différentes, sans
avoir à ré-écrire le code
Il existe différentes approches pour le mappage des objets à des bases de
données relationnelles, telles que les approches descendante, ascendante et centrale. Une
approche descendante utilise les objets existants, puis définit des couches de plus en
plus détaillées à mesure que nécessaire, avant de concevoir la base de données. L'approche
ascendante utilise un schéma de base de données existant, puis conçoit les couches
dépendantes, qui définissent les objets. L'approche centrale utilise une base de
données existante et des objets existants, puis développe les couches intermédiaires
afin de faire correspondre les objets aux tables de base de données correspondantes.
L'application Auction utilise une approche ascendante pour le
développement des EJB entity. La base de données Cloudscape existait déjà et
contenait des tables qui correspondaient parfaitement aux EJB requis. Après avoir créé
une connexion à la base de données à l'aide de l'assistant Connexion à la base de
données, nous avons utilisé l'assistant Mappage EJB vers RDB pour créer des EJB mappés à
partir d'une ou de plusieurs tables, à quelques exceptions près. La figure ci-après
illustre les EJB entity utilisés dans l'application Auction et les relations
entre eux.

Le client éloigné n'accède pas directement aux beans entity de l'application Auction. Toutes
les demandes et les réponses sont traitées par des façades de session et les
beans sont utilisés pour accéder aux données du système dorsal. Cela permet un accès
partagé côté serveur au magasin de données persistant. La section ci-après aborde
les façades de session de manière plus approfondie.
Pour plus d'informations sur le mappage des beans entity, voir la rubrique
d'aide Génération
d'un mappage ascendant.
Génération d'une façade de session avec des objets de données SDO à l'aide de l'assistant de génération de façade de bean session
La façade de session correspond à l'interface entre le client et le
système dorsal qui permet aux composants SDO (Service Data Object) et donc à la base de
données de communiquer. Une façade de session est utile lorsque le client envoie des
demandes nécessitant l'exécution de plusieurs objets. L'envoi de chacune de ces
demandes aux objets peut considérablement augmenter le trafic réseau et les délais
d'attente. La façade de session sert de tampon entre les deux extrémités ; elle prend
une demande générale du client et envoie des demandes spécifiques aux objets nécessaires. Cela
permet de réduire le trafic et de simplifier le développement du client.
Une fois la façade créée, vous pouvez sélectionner les EJB qu'elle gère en
sélectionnant Map EJBs dans le menu de l'outil. La façade génère les
composants SDO nécessaires à partir des beans entity. L'application Auction contient deux
façades, basées sur les groupes fonctionnels suivants :
- La façade système sert d'interface avec les EJB
spécifiques au système dorsal, tels que Catégorie et Rôle.
- La façade utilisateur encapsule les données spécifiques aux utilisateurs,
telles que Bid, Article et Rôle.
En regroupant les EJB et en utilisant deux façades différentes, vous pouvez
améliorer les performances de l'application car les utilisateurs n'accèdent alors
qu'aux EJB dont ils ont besoin. Les beans entity qui contrôlent la fonction du site Web
lui-même, tels que Catégorie, sont contrôlés par la façade système.
Les EJB référencés par une façade sont choisis un par un, à l'aide de l'assistant Créer
un élément facade de bean session, comme illustré dans le diagramme ci-après. Un EJB peut être
référencé dans plusieurs façades, si nécessaire. Ce n'est pas le cas dans l'application
Auction.

Vous pouvez ajouter des fonctions supplémentaires en ajoutant des méthodes aux
façades. Par exemple, dans la façade utilisateur, une méthode renvoie une liste des
utilisateurs, tandis qu'une autre renvoie une liste des utilisateurs actifs. En se
servant de ces méthodes comme exemple, il est possible d'ajouter une autre méthode à la
façade utilisateur qui renvoie une liste de tous les utilisateurs marqués comme
inactifs.
Pour plus d'informations sur les façades de session, reportez-vous au
document "Design Patterns: Session Facade", sur le site java.sun.com.
La vue Navigation de l'outil Web Site Designer offre une représentation visuelle
de la manière dont est disposé le site. Elle affiche chaque page et son organisation
hiérarchique et permet de gérer la présentation et l'organisation des pages sur le site. Lorsque
vous déplacez des pages dans l'éditeur à l'aide de la souris, les commandes de navigation
des modèles de page sont automatiquement mises à jour. Par exemple, à l'aide de la
structure de navigation du site Auction illustrée dans le diagramme ci-après, vous
pouvez modifier l'ordre des onglets de navigation en plaçant la page Sell
avant la page Browse. Web Site Designer génère automatiquement les onglets dans
l'ordre approprié dans toutes les pages. Pour que les modifications soient visibles dans
l'application active, sauvegardez de nouveau chaque page qui utilise le modèle de navigation.

En plus de la vue Navigation que nous venons de décrire, Web Site Designer
fournit une vue Detail qui organise les éléments de page supplémentaires
en une table éditable et pratique, comme illustré dans la figure ci-après. Cette table
facilite la mise à jour des propriétés des pages, telles que le titre, l'auteur et le
libellé de navigation.
Pour plus d'informations sur l'utilisation de Web Site Designer pour gérer la
présentation du site Web, reportez-vous à la rubrique Création
d'une structure de site Web de l'aide en ligne.
Le plan de travail est livré avec un outil de conception visuelle pour le
développement des modèles de page, mais également des pages Web elles-mêmes.
Les modèles de page sont des parties de code du contenu réutilisables qui
permettent d'obtenir un aspect et un comportement communs pour les diverses sections
d'un site Web. Pour partager une présentation commune, les pages Web n'ont qu'à faire
référence aux modèles. L'utilisation de modèles est intéressante à la fois pour
l'utilisateur, qui peut explorer facilement le site Web, et pour le développeur, qui n'a
qu'à créer le code spécifique à une page donnée.
Les modèles de page facilitent la maintenance du contenu des sites Web. Les
modifications apportées au fichier du modèle sont automatiquement répercutées dans
chaque page qui y fait référence. Par exemple, dans l'application Web Auction, le modèle
maintemplate.jtpl fournit la présentation générale des pages Auction. Il est possible
d'ajouter des éléments de page Web au modèle à l'aide de la palette de Page Designer,
ce qui permet de déplacer des éléments dans la page Web à l'aide de la souris. Le code
HTML requis est généré automatiquement. Le modèle Auction peut être facilement
modifié de cette manière, pour inclure par exemple la date du jour et l'heure actuelle
dans le pied de page.
Les principaux éléments du modèle Auction sont les commandes de navigation. La
barre de navigation de l'application Web Auction utilise deux formes de navigation :
- Les onglets de navigation, qui affichent les différentes sections du site Web.
- Les pistes de navigation ou "chemin contextuel", qui affichent
textuellement la position de l'utilisateur sur le site Web (par exemple, Home >
Browse > Listing.

En insérant une balise qui appelle le modèle au lieu de coder la navigation,
vous pouvez inclure la même barre de navigation dans toutes les pages du site. L'éditeur
de mappage des modèles insère des références dans le modèle d'une page Web.
Les modèles dynamiques poussent cette technologie encore un peu plus, par
exemple, en modifiant le contenu des pages Web en fonction des rôles ou des capacités des
utilisateurs ou en insérant des informations spécifiques à l'utilisateur dans une page Web. L'exemple
Auction utilise des modèles dynamiques pour ne fournir des liens d'administration dans la
barre de navigation qu'aux utilisateurs connectés en tant qu'administrateurs et pour
modifier le bouton "Login" en "Logout" une fois que
l'utilisateur s'est connecté.
Pour plus d'informations sur la création des modèles de page Web,
reportez-vous à la rubrique d'aide Création
d'un modèle de page.
La technologie JSF (JavaServer Faces) permet de créer des interfaces
graphiques pour les applications Web dynamiques exécutées sur un serveur d'applications. JSF
est un langage en norme ouverte qui utilise une bibliothèque de balises JavaServer Faces standard. Ces
balises sont insérées dans le code HTML pour créer des pages Web dynamiques.
La structure JSF gère les états des interfaces graphiques via les demandes
serveur et offre un modèle de développement simple permettant de traiter les événements
côté serveur activés par le client. Par exemple, un JSF peut avoir un comportement
particulier pour des événements différents, tels qu'un clic de bouton. Page Designer
possède des fonctions intégrées, affichées visuellement dans la palette, que vous
pouvez déplacer dans la page Web à l'aide de la souris. Ces fonctions de
glisser-déplacer facilitent l'utilisation des éléments JSF, HTML et autres éléments de
script. Cela sert non seulement à contrôler les fonctions de base d'une zone, telles
que le type de valeur d'une zone de texte (entier, alphanumérique), mais également à
définir des règles de validation. Dans Page Designer, les commandes JSF peuvent
être liées aux données SDO associées à chaque page.
La palette de Page Designer permet d'ajouter des fonctions supplémentaires
aux pages JSF. Par exemple, il est possible d'ajouter un bouton "Buy It Now" à
la page des détails des articles pour permettre à un utilisateur d'acheter l'article à la
valeur définie par le vendeur.
La figure ci-après illustre les commandes JSF de la page des détails du site Auction. La
zone de saisie newbid n'accepte que les entiers car la case Integer only est
cochée, comme illustré dans le coin inférieur droit de la figure. La zone de
saisie contient des paramètres supplémentaires pour la validation, le comportement et
l'accessibilité, comme défini dans les balises qui suivent h:inputText, dans la partie
inférieure gauche de la figure. La balise Validation contient les règles de validation
spécifiques définies à l'aide de Java. Par
exemple, une entrée valide pour la zone de saisie newbid est un entier non nul, supérieur
à l'enchère de départ et à l'enchère en cours plus un.

Le code ci-après a été généré pour la zone de saisie newbid dans la page
des détails sur les articles 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 Faces JSP,
reportez-vous à la rubrique d'aide JavaServer
Faces.
En plus des pages Web, l'application Auction contient un client Java Swing
qui permet aux administrateurs de gérer les données utilisateur telles que les noms et
les mots de passe. L'utilisation d'un client Swing ramène toutes les opérations de
traitement sur la machine du client, ce qui réduit les délais d'attente associés aux
applications Web. Le client User Admin répertorie tous les utilisateurs de l'application. L'administrateur
peut interagir avec les données de l'utilisateur et gérer les attributs de ces derniers,
sans avoir à attendre le rechargement d'une page Web. Un client Swing fournit
également une interface orientée application, plus nette.
L'application du client Swing a été développée à l'aide de l'éditeur visuel
Java, comme illustré ci-après. A l'aide de cet éditeur, vous pouvez développer votre
application de manière visuelle ; le code est généré automatiquement. Il n'est plus
nécessaire d'écrire le code Swing compliqué manuellement.
La figure ci-dessus illustre l'application User Admin à l'intérieur de
l'éditeur visuel Java. Les
blocs de droite correspondent aux façades de session, qui utilisent des objets SDO
pour accéder à la logique métier. Les lignes pleines connectant ces blocs à la
conception de l'interface sont associées à des événements spécifiques de l'interface
graphique. Les lignes tiretées montrent quels paramètres sont transmis aux objets
SDO, ainsi que les valeurs que ces derniers renvoient. Le développement visuel
de cette application est bien plus rapide que la création d'un code Java Swing compliqué
et facilite les modifications de l'interface graphique.
L'interface User Admin a été créée directement dans l'éditeur visuel Java. Les
nouveaux composants Swing peuvent être sélectionnés dans la palette et ajoutés à l'application. Tout
composant peut être personnalisé pour obtenir la présentation désirée à l'aide des
outils, des assistants, des appréciations en retour et des propriétés fournis dans la
page des propriétés. En outre, les composants qui peuvent afficher un contenu, tels que
les tables et les zones de texte peuvent être liés pour afficher les données fournies par
une source de données.
Une fois que l'application User Admin est développée, elle doit être déployée
sur le site Web. L'application User Admin terminée est intégrée dans un fichier EAR
et placée dans la structure des répertoires du site Web. Des ressources HTML et des
scripts supplémentaires sont créés pour déployer correctement l'application via WebStart,
comme spécifié dans la documentation du logiciel WebSphere Application Client livré
avec le produit WebSphere Application Server. Les ressources exécutées côté client
sont signées à l'aide d'un certificat pour des raisons de sécurité. Une fois que la
configuration requise décrite dans la documentation est effectuée, l'application est
prête à être déployée sur un client ne possédant qu'un navigateur et Java
WebStart.
Une fois que les composants de l'application Web ont été créés, l'application
Web Auction est déployée et exécutée sur un serveur d'applications. L'application
Auction contient des composants supplémentaires disponibles dans la galerie des
exemples.
Pour plus d'informations, voir la rubrique d'aide relative à l'édition
Java dans l'éditeur visuel.
Création du service Web
Le service Web a été déployé en parallèle avec l'application Web car il ne
dépend pas de cette dernière ; il représente un autre moyen d'accéder à la logique métier
et n'inclut pas toutes les fonctionnalités de l'application Web. Pour une description
plus détaillée de cette partie de l'application Auction, voir la section Service Web. |