Détails de l'application Web Auction

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 :

  1. Mappage des beans entity aux tables de base de données à l'aide de l'éditeur de mappage des EJB
  2. 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
  3. Définition de la présentation du site Web à l'aide de Web Site Designer
  4. Création de modèles de page Web à l'aide de Page Designer
  5. Ajout de composants JavaServer Faces à des pages JSP à l'aide de Page Designer
  6. Création d'une interface graphique Swing à l'aide de l'éditeur visuel Java
  7. 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.

Définition de la présentation du site Web à l'aide de Web Site Designer

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.

Création de modèles de page Web à l'aide de Page Designer

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.

Ajout de composants JavaServer Faces à des fichiers JSP à l'aide de Page Designer

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.

Création d'une interface graphique Swing à l'aide de l'éditeur visuel Java

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.