IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Les applications J2EE et les Frameworks

01/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.


3.2. Choix de conception


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 :


3.4.1. La couche View





Copyright(c) 2004 ALVARO Véronique.
Ce document issu de http://www.developpez.com est soumis à la licence GNU FDL traduite en français ici.

Mes articles :
Les applications J2EE et les Frameworks
Article sur Jonas
Les autres ressources :
Tous les cours Java
La FAQ Java
Les forums java, j2ee, JBuilder, Eclipse, Autres outils pour java.