ObjectWeb - Wiki - Main - frsujet -1-

ObjectWeb - Wiki - Main - frsujet
Sujet en francais du projet eCOM
Sommaire
• Les EJB
• Variantes
• Les clients lourd eCOM
° Commandes
° Exemple de sortie XML
• Les clients Web (Servlets et JSPs)
• Gestion des exceptions
• Transactions
• Performances
Objectifs pédagogiques du projet
Le projet eCOM consiste à concevoir et développer une application de commerce électronique. Une
motivation principale du projet eCOM est qu'il intègre dans sa mise en œuvre différentes thématiques
étudiées dans les formations en informatique : en particulier, interfaces homme-machine, applications et
architectures réparties, base de données. Les aspects relatifs au génie logiciel sont également présents
puisque le projet eCOM comprend la conception et la réalisation d'un produit logiciel qui satisfait certains
critères de qualité (documentation, respect des normes, etc). L'intégration de différentes thématiques
présente les atouts suivants :
• Valorisation des enseignements acquis dans les différentes thématiques au profit d'un projet important
et réaliste.
• Appréhension des (inter)dépendances entre les thématiques.
• Communications entre les différents réalisateurs du projet.
En outre, une deuxième motivation forte du projet eCOM est qu'il intègre des technologies et des standards
récents et largement utilisés dans le domaine des applications Internet. Ce projet permet plus précisément
de se placer en tant qu'utilisateurs de la technologie JavaEE (Java 2 Enterprise Edition) destinée à la
réalisation de serveurs d'information ou de serveurs de commerce électronique à base de composants
distribués, transactionnels et persistants. Les réalisateurs sont confrontés par ce biais à la manipulation de
mécanismes et de fonctions générales d'un système distribués : gestion de la désignation de composants
distribués, configuration d'une application distribuée, association de propriétés non fonctionnelles aux
composants (persistance, transactions), gestion des images persistantes des composants (liaisons avec
une base de données).
Le projet se décompose en différentes parties intervenant dans la programmation et dans le déploiement
d'une application JavaEE, classiquement qualifiée de n-tiers :
• Une partie navigateur (chez le client)
• Une partie serveur Web avec la programmation et le déploiement de servlets,
• Une partie logique applicative avec la programmation et le déploiement des EJB ("cœur du serveur
JavaEE")
• Une partie Base de données.
Principes d'architecture d'une application JavaEE
L'application de commerce électronique est construite au moyen de servlets et de composants répartis
appelés EJB (Enterprise Java Beans). Les spécifications JavaEE de SUN définissent le modèle de
programmation des servlets et des EJB ainsi que leurs processus de déploiements.
JavaEE (Java 2 Enterprise Edition) est un framework orienté vers le developpement d'applications
d'entreprise avec le langage de programmation Java. Ce framework rassemble un certain nombre de
spécifications d'API afin de faciliter la création d'applications réparties et fiable.
Voici une liste (très partielle) des API inclues dans JavaEE :
• EJB : API de manipulation des composants réalisant la logique applicative de l'application
• Servlets : « composants » réalisant la partie présentation de l'application
-1-
ObjectWeb - Wiki - Main - frsujet
• JSP : similaire aux ASP et aux PHP, elles permettent l'inclusion de scripts Java dans les pages
générés dynamiquement. Celles ci sont en réalité compilées en objets Java lors de la première
requête et exécutées par une JspServlet.
• JNDI : API de connexion à des annuaires, notamment des annuaires LDAP. Elle est utilisée pour
désigner les ressources et les composants dans la plateforme.
• JDBC : API de connexion à des bases de données relationnelles.
• JTA : API de gestion des transactions
• JCA (Java Connector Architecture): API de connexion à des sources de données non relationnelles
(patrimoniales, propriétaires (ERP), …).
• JDO : API de persistance transparente à des sources de données relationnelles ou non (bases de
données objets, …).
• JMS : API de communication asynchrone au travers de MOM (Message Oriented Middleware)
• JavaMail : API de connexion à des serveurs de mails (SMTP, POP3, IMAP4)
• JMX : API pour l'administration des applications
• JAAS (Java Authentication and Authorization Service) API d'authentification des exécutants de code
Java dans la plateforme. JAAS étends ainsi le systèmes de permissions de Java
Plusieurs API gravitant autour d'XML y ont été ajoutées :
• JAXP (Java API for XML Parsing) : API d'unification des différents parseurs XML (parsers SAX, DOM
et processeurs XSLT).
• JAXB : API de sérialisation/déserialisation d'objets Java vers/depuis XML
• JAX-RPC : API d'invocation synchrone de services par XML (SOAP)
• JAXM : API de communication asynchrone par XML
• JAXR : API d'enregistrement et de recherche de Web Services.
Le projet eCOM porte sur l'utilisation des Servlets/JSP et des EJB (via le container EasyBeans qui implante
la spécification EJB3.0), dont la persistence est mise en œuvre via une base relationnelle. Les clients sont
deux types : application Java standalone accédant aux beans directement par RMI, et navigateur Web
affichant la présentation HTML calculée par l'intermédiaire de Servlets. Concernant la couche présentation,
il est demandé aux étudiants d'utiliser la technologie Ajax, qui permet d'optimiser la gestion des pages
HTML, et de suivre le modèle de conception MVC.
La plate-forme d'exécution JavaEE qui est utilisée dans ce projet est la plate-forme JOnAS, qui est
disponible en logiciel libre au travers du consortium ObjectWeb. JOnAS intègre un container de servlet qui
peut être Jakarta Tomcat ou Jetty.
-2-
ObjectWeb - Wiki - Main - frsujet
Figure 1 : Architecture JavaEE et portée du projet eCOM L'application eCOM - Version 1
Vous aurez dans un premier temps à programmer une mini application de commerce électronique pour
valider votre savoir-faire concernant le tiers EJB. Dans un deuxième temps, vous ferez complèterez cette
application, après avoir finalisé votre cahier des charges et adopté un modèle de conception permettant de
mettre en oeuvre un site de commerce électronique élaboré, offrant de multiples fonctions. La suite de cette
section décrit l'application que vous devez produire dans un premier temps (appelée eCOM-VERSION 1).
Les EJB
L'application considérée utilise au minimum cinq types de beans purement applicatifs, gérant
respectivement des comptes utilisateurs (type Account), des produits (type Product), des magasins (type
ProductStore), des caddies virtuels (type Cart) et des couvertisseurs de devise (type EuroConvertor). Les
beans de type Cart et EuroConvertor ne sont a priori pas persistants, contrairement aux autres. D'autre
types de beans peuvent être ajoutés (par exemple, pour gérer un suivi des commandes).
Ces beans n'interagissent pas directement avec les clients ou les administrateurs de l'application de
commerce électronique. Pour des raisons d'efficacité, ils ne fournissent que des interfaces locales. La
manipulation de ces beans depuis un client ou un administrateur distant est réalisée au travers de deux
beans session fournissant des interfaces distribuées, appelés EcomAdmin et EcomCustomer. Le bean
EcomAdmin fournit une interface d'administration de l'application (création ou destruction de comptes, de
magasins, de produits, etc). Le bean EcomCustomer fournit une interface à un client désireux de connaître
les magasins et les produits, et souhaitant éventuellement acheter des produits.
Les beans EcomAdmin et EcomCustomer ne sont utilisables qu'au travers d'un programme externe qui
communique avec eux. Ce programme peut être mis en œuvre sous la forme d'un programme Java
standard, ou bien de servlets. Il est demandé de fournir les deux types de programmes dans
eCOM-VERSION1.
A titre indicatif, les interfaces de beans que l'on demande de programmer sont les suivantes. Ces interfaces
peuvent tout à fait être modifiées.
Account Un bean de type Account représente et gère le compte d'un acheteur ou celui d'un magasin. Les
identifiants devront être des numéros au format IBAN. Les méthodes métier qu'il fournit sont principalement
les suivantes.
interface Account { void deposit(double amount); // dépose une somme d'argent sur le compte.
double withdraw(double amount); // retire une somme d'argent du compte. double getBalance(); //
retourne le solde disponible sur le compte. … }
Product Un bean de type Product gère un produit d'un magasin. Les méthodes métier qu'il fournit sont
principalement les suivantes. {
interface Product { ProductPK getReference(); //retourne la référence (identificateur unique) du
produit String getName(): retourne le nom du produit double getPrice(); //retourne le prix du
produit int getProductStore(); //retourne la référence du magasin qui vend ce produit … }
ProductStore Un bean de type ProductStore gère un magasin. Les méthodes métier qu'il fournit sont
principalement les suivantes.
interface ProductStore { Vector getProducts(); //retourne la liste des produits vendus par le
magasin String getName(); //retourne le nom du magasin. int getReference(); //retourne la
référence (identificateur unique) du magasin String getAccountId(); //retourne le numero IBAN du
compte du magasin … }
Cart Un bean de type Cart gère un caddie d'un client connecté à l'application. Les méthodes métier qu'il
fournit sont principalement les suivantes.
-3-
ObjectWeb - Wiki - Main - frsujet
interface Cart { void addProduct(ProductPK productPK); //ajoute un produit dans le caddie.
Vector getProducts(); //retourne la liste des produits contenus dans le caddie. double
getTotalPrice(); //retourne le prix total des produits contenus dans le caddie. void buy(String
accountId); //achète les produits contenus dans le caddie avec un numéro de compte client. … }
Les règles de gestion du caddie interdisent les cas suivants (dans lesquels l'exception CartException est
levée) :
•
•
•
•
l'ajout d'un produit après l'achat du contenu du caddie,
l'achat d'un caddie vide,
la suppression d'un produit non présent dans le caddie,
le paiement du total du caddie avec un compte dont le solde n'est pas suffisant.
Le caddie possède un état interne (EMPTY|FILLING|BOUGHT) permettant de vérifier ces règles.
EuroConverter On fait l'hypothèse que les prix dans la base sont en Euro (EUR). Pour permettre un
affichage des prix dans l'unité monétaire de l'usager de eCOM, on utilisera un bean opérant les conversions
de devise. Un bean de type EuroConverter gère les conversions monétaires de plusieurs devises de la zone
Euro depuis/vers l'EURO
interface EuroConvertor { double convertToEuro(double amount, String currencySymbol); //
conversion d'un montant dans une monnaie vers l'Euro double convertFronEuro(double amount,
String currencySymbol); // conversion d'un montant depuis l'Euro vers une monnaie Vector
getCurrencySymbols(); // donne la liste des symboles des monnaies disponibles String
getCurrencyRealName(String currencySymbol); // donne le nom réel d'une monnaie à partir de son
symbole … }
Dans un premier temps, vous ne considérerez que des conversions à parité fixe entre l'Euro et les
anciennes monnaies de l'Euroland. Le convertisseur de devises prend en compte les taux de conversion
définitifs de l'euro fixés le 31 décembre 1998 avec 6 chiffres significatifs (pour plus d'info sur les conversions
: http://fxtop.com/fr/adv.htm). Les taux de l'euro contre les devises out sont rafraîchis quotidiennement, ce
sont les taux officiels diffusés par la Banque Centrale Européenne au 21 novembre 2001.
Quelques constantes : 1 EUR = 1.95583 DEM = 1 BEF = 6.55957 FRF = 1936.27 ITL
Les montants en euro sont arrondis avec 2 décimales (22.224 => 22.22, 22.226 => 22.23, 22.225 => 22.23).
Pour convertir un montant d'une dénomination nationale de l'euro à une autre (par exemple du mark
allemand au franc français), le montant intermédiaire en euro est calculé en interne avec une précision de 3
décimales. Les montants en devises sont exprimés avec la bonne précision (0 ou 2 décimales suivant le
pays).
Les conversions d'une devise "out" à une devise "in" se font par l'intermédiaire du montant en euro avec 2
décimales. Les conversions d'une devise "out" à une autre devise "out" se font par l'intermédiaire du
montant en euro avec une précision maximale. Les montants peuvent être rentrés avec le point ou la virgule
comme séparateur décimal.
Remarque : la conversion pourrait se faire avec des devises dont la parité est fluctuante par rapport à l'Euro
: USD, GBP, JPY, …
Variantes
Si vous ne disposez que de peu de temps pour faire ce projet, vous pouvez n'implanter que les beans
Account, Product et Cart en supprimant ProductStore et EuroConvertor.
Si vous disposez de plus de temps, vous pouvez ajouter des beans tels qu'Order, Customer,
ShipmentCalculator, …
Les clients lourd eCOM
-4-
ObjectWeb - Wiki - Main - frsujet
Il y a deux principaux types de clients lourds :
• celui de l'acheteur (ecom.client.ExternCustomer)
• et celui de l'administrateur de l'application Ecom (ecom.client.ExternAdmin).
Chaque client lourd est un programme Java qui gère la communication avec un bean dit facade
(ecom.beans.CustomerBean et ecom.beans.AdminBean). L'interface utilise des lignes de commande à la
manière d'un shell. Le bean ecom.beans.CustomerBean permet à un client de remplir un caddie et de
l'acheter avec un compte en utilisant les commandes suivantes passées à un petit interpréteur de
commandes. Le client ecom.client.ExternAdmin vous permettra également initialiser et de modifier la base
de données eCOM via les beans persistents (de type Entity) représentant les comptes, les magasins et les
produits. Le squelette de l'interpréteur shell vous est fourni. Commandes
Les commandes des 2 clients sont les suivantes :
• help|? liste une aide
• output HTML|WML|XML|TEXT|JSON positionne le format de sortie (utilisable à tout moment). Par
défaut : TEXT. Vous n'implémenterez que les sorties TEXT, XML et bien sur HTML et JSON !
• pause attend un CR pour continuer (utile pour tester les blocages liés aux transactions)
• batch -stopOnError cmds.txt exécute la série de lignes de commande présentes dans le fichier
cmds.txt (utile pour initialiser les beans, pour écourter les démonstrations, ...). L'option -stopOnError
arrête l'exécution des commandes si une exception est levée.
• currency EUR|FRF|DEM|BEF positionne la devise utilisée pour les sorties (utilisable à tout moment).
Par défaut : EUR
• language en|fr|es|it,… positionne la langue utilisée pour les sorties (utilisable à tout moment). Par
défaut : en
• begin démarre une transaction
• commit valide la transaction courante
• rollback|abort abandonne la transaction courante
• account liste tous les comptes
• store liste tous les magasins
• product liste tous les produits
• product -store 1001 liste les produits du magasin 1001
• product -name "Machine à laver" liste les produits dont le nom est celui passé en paramêtre
• product -like Machin% liste les produits dont le nom est semblable
• product -price 1000.00 liste les produits de prix inférieur
• product -price 100.00 1000.00 liste les produits dans un intervalle de prix
• cart affiche le contenu du caddie (et le prix total)
• cart -add 101 ajoute le produit 101 dans le caddie
• cart -add 102 ajoute le produit 102 dans le caddie
• cart -add 103 ajoute le produit 103 dans le caddie
• cart -remove 102 ajoute le produit 102 dans le caddie
• cart -buy FR7630003003930003728602468 achète le contenu du caddie avec le compte
FR7630003003930003728602468
• exit|quit quitte le client ecom (et abandonne le ou les transactions non validées)
Exemple de sortie XML
La sortie XML peut être générée après construction d'un objet org.w3c.dom.Document
<?xml version="1.0" standalone="yes"?> <?xml-stylesheet type="text/xsl" href="cart2html.xsl"
?><cart> <state>FILLING</state> <product> <productStoreId>1001</productStoreId>
<reference>101</reference> <name>Machine à laver</name> <price currency="FRF">2000.00</price>
</product> <product> <productStoreId>1002</productStoreId> <reference>103</reference>
<name>Machine à coudre</name> <price currency="FRF">3000.00</price> </product> <total
currency="FRF">5000.00</total></cart>
Les clients Web (Servlets et JSPs)
Les servlets ecom.servlets.CustomerServlet et ecom.servlets.AdminServlet reprennent essentiellement les
commandes des clients lourds.
-5-
ObjectWeb - Wiki - Main - frsujet
On vous demande de programmer ces servlets ainsi que des pages HTML associées register.htm,
login.htm, ...) qui utilisent respectivement les beans EcomCustomer et EcomAdmin. Dans un premier temps,
ces servlets ne retournent des documents au format text/html
La servlet ecom.servlets.CustomerServlet sert les opérations dont les URI sont /store, /product, /card, /add,
/checkout, /orders, ...
La servlet ecom.servlets.AdminServlet sert les opérations d'ajout, de suppression et de consultation des
diffèrents Entity Beans. Les URI doivent avoir le format /secured/ car ces opérations ne sont autorisées qu'à
l'administrateur authentifié (username : tomcat, password : tomcat).
L'utilisation du patron de conception Modèle-Vue-Contrôleur (MVC) est recommandée pour la réalisation
des 2 clients légers. La servlet réalise le contrôle tandis que des JSPs réalisent l'affichage des vues. Un
exemple de MVC à base de servlets/JSP est fourni ici, à titre pédagogique : fichier .war déployable dans un
serveur d'applications ( {attach:} model2.war ) ou arborescence complète en format tar/gzip ( model2.tar.gz
).
Chaque client Web est conditionné et déployée sous la forme d'un WAR distinct : ecomcustomer.war et
ecomadmin.war.
Remarque: une partie du code peut être factorisé intelligemment entre les clients lourds et les
clients Web. L'application eCOM - Version 2
Vous pouvez cette fois donner libre cours à votre imagination pour produire un site de commerce
électronique intégrant des fonctions d'achat, de suivi de commandes, etc coté client, ainsi que des fonctions
de mises à jour, de consultation de stocks, etc coté administrateur. Ce site pourra faire appel à des
technologies complémentaires tels que AJAX, Struts, JSF, TagLibs personnalisés, ...
Vous penserez cependant à respecter les consignes indiquées par les enseignants aussi bien du point de
vue ergonomie que système. Quelques critères de qualité de l'application eCOM
Gestion des exceptions
En cas de levée d'exception, un client doit repartir dans un état cohérent mais en essayant de ne lui faire
perdre le contenu de son caddie !
Transactions
Vous testerez et validerez le bon fonctionnement des transactions, par exemple en lançant un achat et en
arrêtant brutalement le serveur. Pour cela, il faudra introduire des temporisations paramétrables pour avoir
le temps de provoquer des pannes en cours de transaction. N'hésitez pas à démarrer plusieurs clients en
parallèle pour faire des tests de concurrence entre les transactions.
Performances
On s'intéresse à mesurer les performances de l'application eCOM (Servlets+EJB). Pour cela, vous
mesurerez les performances de votre site au moyen d'outils comme Apache JMeter ou CLIF et vous
joindrez les mesures effectuées à votre rapport final.
Sujet en francais du projet eCOM (fr)
Creator: xwiki:XWiki.donsez Date: 2007/08/23 07:14
Last Author: xwiki:XWiki.donsez Date: 2010/09/17 16:01
Copyright (c) 2005-2006, ObjectWeb Consortium
-6-
ObjectWeb - Wiki - Main - frsujet
-7-