Les applications J2EE et les Frameworks01/05/2004
3. Exemple d'application et making-of : le Petstore de Sun
3.1. Vue de l’architecture de plus haut niveau
3.2. Choix de conception
3.2.1. Utilisation ou non d’un framework
3.2.2. Web-tier business logic vs. enterprise beans components
3.2.3. Architecture locale vs. distribuée
3.2.4. Contrôle des transactions déclaratif vs programmé
3.2.5. Communication Synchrone vs. asynchrone
3.3. Diagramme Use Case de l’application
3.3.1. Le choix du Tiers pour l’application
3.3.2. Architecture locale ou distribuée ?
3.4. Architecture du site web
3.4.1. La couche View
3. Exemple d'application et making-of : le Petstore de Sun
C’est un exemple typique d’application e-commerce : une société vend des animaux avec
une boutique on-line. L’application a un site web qui représente l’interface avec les clients.
Les administrateurs et d’autres intervenants extérieurs, comme les fournisseurs , utilisent
d’autres interfaces de l’application pour maintenir l’inventaire, ou réaliser des taches de
gestion. Chaque classe d’utilisateur a accès à certaines catégories de fonctionnalités, et
chacune interagit avec l’application à travers un mécanisme d’interfaçage spécifique.
Certaines tâches sont exécutées automatiquement par l’application, d’autres doivent être
réalisées manuellement, comme la gestion de l’inventaire ou l’expédition des commandes.
L’application repose sur la plate-forme J2EE 1.3 de base de sun.
3.1. Vue de l’architecture de plus haut niveau
La plupart des applications d’ entreprise doivent coopérer avec de multiples sources de données et
d’EIS. Ces systèmes externes peuvent être des systèmes d’information internes comme des
legacy dbb ou des ERP (enterprise resource planning). D’autres systèmes externes peuvent
être des services web pour des partenaires. Par exemple le centre qui gère les commandes
est interne à l’entreprise, le service de cartes de crédit est externe à l’entreprise, et les
fournisseurs peuvent être en interne (ex : l’entrepôt) ou en externe.
Le petstore est donc en modules , le résultat étant une architecture d’entreprise découplée
Qui peut inter opérer avec des systèmes de source de données préexistantes et avec des
systèmes de partenaires, le tout construit par dessus une plate-forme J2EE.
L’application est donc divisée en 4 applications qui coopèrent :
- pet store e-commerce Web site (“petstore”) : a Web application which
shoppers use to purchase merchandise through a Web browser
- pet store administration application (“petstoreadmin”) : a Web application that
enterprise administrators use to view sales statistics and manually accept or reject orders.
While petstoreadmin is a Web application, its user interface is a rich client that uses XML
messaging, rather than an HTML Web browser
- order processing center (“OPC”) : a process-oriented application that manages order
fulfillment by providing the following services to other enterprise participants:
- receives and processes XML documents, via JMS, containing orders from the
petstore
- provides petstoreadmin application with order data using XML messaging
over HTTP
- sends email to customers acknowledging orders using JavaMail™
- sends XML order documents to suppliers via JMS
- maintains purchase order database
- supplier (“supplier”) : a process-oriented application that manages shipping products
to customers by providing the following services:
- receives XML order documents from opc via JMS
- ships products to customers
- provides manual inventory management through a Web-based interface
- maintains inventory database
On ne va décrire ici que de l’appli web-store du petstore.
Pour créer une application de ce genre, on est confronté à plusieurs choix de conception :
http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/sample-app/sample-app1.3.1a3.html
http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/webtier/web-tier5.html
- Utilisation ou non d’un framework
- Web-tier business logic vs. enterprise beans components
- Architecture locale vs. Distribuée
- Contrôle des transactions déclaratif vs programmé
- Communication Synchrone vs. asynchrone
3.2.1. Utilisation ou non d’un framework
Les petites applis n’utilisent souvent pas de framework. Les applis plus grandes
profitent souvent d’une application MVC framework comme WAF (dans le petstore)
ou Struts. La structure cohérente et la séparation fonctionnelle MVC font que les
applis sont plus fiables et plus faciles à maintenir et à étendre.
3.2.2. Web-tier business logic vs. enterprise beans components
Beaucoup d’appli implémentent toute la logic métier dans les classes Web-Tiers. Les
applications plus complexes et à plus grande échelle choisissent la technologie EJB
pour fournir un modèle de développement basé sur les composants pour une
meilleure fiabilité, une scalabilité, et pour avoir des services communs horizontaux.
3.2.3. Architecture locale vs. distribuée
Les clients d’EJB dans une architecture distribuée accèdent aux beans au travers
d’interface distante. Bien que les EJB distants augmentent la scalabilité et la
disponibilité, le coût important des communications distantes font qu’ils sont surtout
pertinents pour des opérations coarse-gained.
Les EJB locaux résident dans la même JVM que leurs clients, ils évitent donc les
procédures d’appel distant couteux. Les EJB locaux fournissent des accès très
performants aux fine-grained business logic, en maintenant des services de haut
niveaux du conteneur EJB.
Le petstore utilise la view des EJB par les clients locaux pour améliorer la
performance et simplifier le développement.
3.2.4. Contrôle des transactions déclaratif vs programmé
Les transactions J2EE peuvent être contrôlées soit en programmation dans le code,
soit de manière déclarative dans des descripteurs de déploiement. Les transactions
déclaratives sont faciles à créer et à gérer, alors que les programmées ont un degré
supérieur de contrôle.
Le Petstore utilise un contrôle programmé pour assurer la cohérence des données
quand on génère les views, et un contrôle déclaratif quand on update les données
dans le Tiers EJB.
3.2.5. Communication Synchrone vs. asynchrone
La communication synchrone est la plus utilisée quand l’opération peut produire un
résultat dans un temps raisonnable. La communication asynchrone est plus
complexe à implémenter et à gérer, mais elle est plus utile pour intégrer des
opérations high-latency, unreliable, or parallel . La plupart des applications utilisent
une combinaison de communication synchrone ou asynchrone.
Le petstore accède au catalogue de manière synchrone (car l’accès au catalogue est
une opération rapide). Mais le site transmets les ordres d’achats de manière
asynchrone car le traitements des commandes peut être plus long et le centre de
traitement des commandes pas toujours disponible.
3.3. Diagramme Use Case de l’application
Le diagramme Use Case permet de recenser les fonctionnalités et services de l’application
- Le client la boutique, commande, gère son compte et reçoit des emails
- L’ administration manager regarde les données financières de l’enterprise
- Un système bancaire traite la paiement par carte de crédit
- L’ouvrier du dépôt empaquette et envoie la commande
Quand on a déterminé les fonctionnalités de l’application, on peut commencer son design :
L’application utilise 2 modèles d’architecture : le modèle MVC pour l’unité interactive du site
web, et comme le centre de traitement des commandes n’est pas une application interactive,
sont design repose sur une architecture orientée process.
3.3.1. Le choix du Tiers pour l’application
Une étape importante du design d’une application J2EE est le choix du Tiers qu’elle va
utiliser. Il faut choisir si le composant web tiers accède aux ressources de l’EIS directement
ou au travers d’un Tiers EJB. Ce choix dépend des fonctionnalités, de la complexité et de la
scalabilité requis par l’application. Le Tiers EJB offre des avantages( prise en main
automatique de la sécurité, des transactions, des processing distribués, etc..).
Ensuite il faut décider comment distribuer les fonctionnalités de l’application au travers des
tiers. Il faut donc diviser l’application en objets.
Dans un design web-centric , les composants du tiers web utilisent des services du
conteneur comme l’ API JDBC pour communiquer directement avec les ressources EIS qui
contiennent les données de l’application. Dans cette approche, les web tiers composants
sont responsables de la plupart des fonctionnalités de l’application. Ils s’occupent de la
génération du contenu dynamique, de la présentation de contenu, et des requêtes
utilisateurs. Ils peuvent implémenter des fonctionnalités au cœur de l’appli, comme le
traitement des commandes, et faire appliquer les business rules.
Finalement les composants web tiers doivent aussi gérer les transactions, comme en
utilisant JTA, et le pooling des connexions pour l’accès aux données. En remplissant autant
de fonctionnalité, une application web-centric peut vite devenir monolitique, trop complexe et
difficile à maintenir.
L’approche Web-centric permet un démarrage rapide pour de petites applications avec peu
de besoins en terme de transactions, tandis que l’appoche EJB-centric est mieux pour la
construction d’application d’entreprise de grand taille, ou la scalabilité du code et des
performances sont prépondérantes.
Pour le petstore , le design est conçu pour une éventuelle expansion. Il peut donc être
considéré comme une architecture EJB-centric. (le cas de la lecture du catalogue aurait pu
utilisé une architecture web-centric).
3.3.2. Architecture locale ou distribuée ?
Une approche EJB-centric , avec la logique métier dans le tiers milieu, fournit une flexibilité
pour concevoir les applications distribuées (interagissant au travers de mécanismes de
communication distante) ou locale.
3.4. Architecture du site web
L’architecture MVC fonctionne bien pour cette application. Au plus haut niveau, l’ application
se divise en 3 catégories de couches logiques :
- couche qui porte l’aspect présentation de l’application,
- couche qui s’occupe des business rules and data,
- et celle qui accepte et interprète les requêtes utilisateurs et contrôle que les objets
métiers satisfassent aux requêtes.
En général l’aspect de l’interface change souvent, son comportement un peu moins, et les
business data and rules sont relativement stables.
Il faut maintenant spécifier les fonctionnalités de l’interface utilisateurs.
A customer accessing the Web site expects to see:
- Links or navigation bars to common navigational tasks
- A catalog providing an organized view of the site’s contents
- A search mechanism
- A master view of catalog items
- A detail view that describes the details of a particular item
- A shopping cart view that lets customers review and modify the contents of their shopping cart
- A checkout view that displays the total order cost and allows the customer to enter billing and shipping information
- A receipt view to provide confirmation of the purchase
En plus de ces fonctionnalités, l’application doit permettre des contraintes de sécurité
donnant des autorisations d’accès ou non à diverses fonctionnalités.
Une fois les fonctionnalités identifiées, on peut diviser l’ application en modules. Cette
séparation permet de réduire la dépendance des modules. On peut donc les développer de
manière indépendante. De plus, l’identification d’interfaces entre les modules permet de faire
faire des modules par des fournisseurs de composants.
On a pu donc diviser l’ application ainsi en 5 modules :
- Un module de « contrôle » pour créer et maintenir les infos des comptes client, qui
inclus un identifiant utilisateur, des infos pour le contact et la facturation. Ces infos
sont maintenues dans une bdd. Ce module créé aussi et gère le caddie de
l’utilisateur, et il contrôle les interactions avec l’utilisateur.
- Un module « sign-on » pour prendre en charge le processus de sécurité du log-in,
comme la vérification des login/pswd
- Un module « produits de catalogue », qui renvoie les infos-produits du catalogue,
basé sur une recherche du client.
- Un module « client » qui gère un processus d’achat d’un client et maintient les
enregistrement du compte client
- Un module de « messagerie » qui permet à l’appli d’envoyer et recevoir des
messages asynchrones contenant les ordres d’achat.
On identifie ensuite les unités : logique métier, données, logique présentation, et on les
modèle en objets software. On doit identifier les options au plus haut niveau, puis
redescendre. Le design général du site suit l’architecture MVC, alors que certains de ses
composants suivent des patterns J2EE.
Le Petstore est construit sur le Web Application Framework (waf). Les applis J2EE peuvent
utiliser les fonctionnalités de waf pour contrôler les screen flow de l’application, générer
les views, et activer les composants métiers qui réalisent les fonctions métiers de
l’application. Waf et composants métiers dépendent des technologies de la plateforme J2EE.
Le waf fournit différents services que la majorité des appplications web nécessite: filtrage et
redistribution des requêtes, génération de view avec template, un set de custom tags
réutilisables, et un screen flow control.
Like the application logic, most the components shown in Figure 11 are application-specific:
they represent business data and operations on those data. Entity beans represent business
entities such as Customer, Address, and Account. Session beans handle such application
functions as signing a user on and off of the system and managing the shopping cart. Other
session beans provide utility functions such as generating unique identifiers. Traditional
JavaBeans™ components serve as value object classes to communicate between
components within the application, and XML document classes are used to interoperate with
the order processing coordinator.
Modèle MVC :
|
