Application de commerce électronique

F. Boyer, S. Chassande, D. Feliot, S. Krakowiak, D. Donsez

Projet de DESS-GI option SRR  et RICM3 option SR

Année Universitaire 2001-2002

Université Joseph Fourier

1. Objectifs
2. Fonctionnalités  attendues pour GICOM
3. Architecture du serveur GICOM
4. Réalisation  de l'application
5. Accès aux sources et services support
6. Déroulement du projet

Liens vers les documentations de chaque étape de travail

• ETAPE 1 - Serveur GICOM minimal
• ETAPE 2 - Application bancaire minimale
• ETAPE 3 - Application bancaire persistente
• ETAPE 4 - Serveur GICOM intégrant la gestion des ordres d'achat
• ETAPE 5 - Serveur GICOM sécurisé
• ETAPE 6a - Serveur Fournisseur Asynchrone
• ETAPE 6b - Serveur Fournisseurs en mode Web Service

1 Objectifs

• Services d'intégration et de coordination de composants existants (Corba)
• Communication sur un réseau à grande distance via le World Wide Web (Http, Applets, Servlets)

• les fonctionnalités attendues du serveur de commerce électronique GICOM
• l'architecture globale proposée pour la réalisation du serveur
• les étapes de réalisation

2 Fonctionnalités attendues pour GICOM

• Consultation de catalogues de produits
• Remplissage d'un caddie
• Demande d'achat des produits présents dans le caddie

La suite des actions éffectuées par un client donné entre le moment où il entre dans la galerie électronique, et le moment où il en sort, est applée session. Le serveur GICOM est capable de traiter plusieurs sessions en parallèle. La terminaison d'une session peut être demandée par le client au travers de l'interface graphique du serveur, ou bien provoquée par le serveur lorsque la session atteint une durée maximale. Ceci permet d'assurer que tout client qui oublie de se "déconnecter" du serveur le sera automatiquement au bout d'un temps fini.

Le serveur GICOM maintient une base d'informations dans laquelle sont décrits les fournisseurs de produits disponibles (nom, adresse, ...), ainsi que les produits disponibles (nom, prix, description, ...) dans leurs catalogues respectifs. L'arrivée d'un nouveau fournisseur implique que celui-ci s'enregistre auprès de l'administrateur de la base d'information du serveur.
Une fois enregistré, et avec l'aide de l'administrateur de la base d'information, un fournisseur peut créer un nouveau catalogue, et par la suite modifier ceux existants. De telles modifications (par exemple du prix) ne seront effectivement prises en compte que pour les sessions initiées après la validation de la modification. Lorsqu'un fournisseur supprime un produit de la base, il est donc possible qu'il reçoive des commandes pour ce produit, pendant une durée égale au délai maximal  de session.

Lorsque le client décide de valider ses achats, il émet un  ordre d'achat vers le serveur GICOM. Cet ordre d'achat comprend l'identification du client (nom, adresse, numéro de CB, etc), ainsi que l'identification des produits achetés et de leur fournisseur.  Le serveur procède alors de la maniere suivante :

• Premièrement, il effectue les transactions bancaires relatives aux produits achetés. Pour ceci, il communique avec  les organismes financiers intéressés (la banque du client et celles des fournisseurs).
• En second lieu, si le fournisseur est informatisé et accessible par le réseau, l'ordre d'achat le concernant lui est transmis (par exemple, par courier électronique). L'ordre d'achat est dans tous les cas stocké dans une base locale d'ordres à envoyer par courier papier aux fournisseurs.
• Enfin, le serveur renvoie au client une clé lui permettant de prouver son achat en cas de litige. Comme pour les fournisseurs, cet envoi peut être fait à la fois par courier électronique et par courier papier.

  Figure 1.  Intervenants dans l'application GICOM

3 Architecture du serveur GICOM

• Application client : c'est l'interface permettant à un client de parcourir la galerie et de réaliser des achats. Cette interface est interactive et rendue accessible au travers d'un accès Internet, sous la forme de formulaires HTML.

• Application serveur : le serveur de commerce est  décomposé en un ensemble de services (entrée d'un client dans la galerie, consultation d'un catalogue de produits, gestion d'un ordre d'achat, ...). Ces services seront réalisés par des servlets, ce qui permet d'optimiser les performances d'exécution du serveur ainsi que de conserver un contexte d'exécution (session) entre les services réalisés. La gestion des sessions clientes au niveau du serveur fera appel au mecanisme de  cookies de HTTP.
• Le serveur gère en outre des données persistantes (catalogues de produits, commandes en cours, etc), au niveau desquelles il est utile de pouvoir effectuer des accès associatifs. Ces données seront conservées dans une base de donnees de type SQL, accédée par le serveur au travers d'un driver JDBC.

• Applications "banques" : on suppose que les banques sont gérées par des serveurs   CORBA. Ces serveurs fournissent des fonctions de consultation et de modifications de données bancaires (débits, crédits, etc), auxquelles le serveur GICOM pourra accéder via l'interface d'accès à distance de CORBA. Au niveau des clients, les banques fournieront une interface graphique au travers du World Wide Web, sous la forme d' applets, qui permettront à un client d'effectuer certaines opérations (consultation du solde, virement entre comptes, etc).

Figure 2. Architecture et techniques utilisées

 4 Réalisation  de l'application

• ETAPE 1 - Serveur GICOM minimal : cette étape consiste à réaliser le serveur de commerce électronique, sans se soucier de son interaction avec les applications bancaires. La gestion des ordres d'achats ne sera donc pas prise en compte dans cette étape.
• ETAPE 2 - Application bancaire minimale : cette étape consiste à réaliser une application de gestion d'une banque, qui fournit des services de consultation et de modification des données bancaires. Une banque sera mise en oeuvre par un ensemble de serveurs CORBA (chacun représentant par exemple une agence de la banque). Un serveur CORBA est un support permettant de rendre accéssible à distance un ensemble de services. Dans cette première étape, on réalisera les serveurs CORBA représentant les banques, et on rendra disponibles aux clients certains services (solde, virement, ..) au travers d'une interface graphique accessible par le Web, et mise en oeuvre par un applet.
• ETAPE 3 - Application bancaire persistente: dans la version de base de l'application bancaire, la persistence des données gérées par les serveurs bancaires (serveurs CORBA) n'est pas assurée. L'étape 2 consistera à rendre ces données persistentes, de manière à assurer que le relancement d'un serveur après son arrêt permet de récupérer les données bancaires, dans l'état dans lequel elles ont été sauvegardées pour la dernière fois. Cette fonctionnalité sera utile pour l'étape 4.
• ETAPE 4 - Serveur GICOM intégrant la gestion des ordres d'achat: cette étape réalise l'intégration des programmes réalisés en 2 et 3, de manière à permettre à un client de l'application de commerce électronique de passer des ordres d'achat de produits. Le serveur GICOM accèdera aux banques pour débiter le compte d'un client et pour créditer les comptes des fournisseurs des produits achetés. Ces opérations seront réalisées de manière transactionelle, afin de garantir la conservation de la cohérence du système. Les transactions gérant des ordres d'achat seront des transactions distribuées, puisqu'elles impliquent des serveurs distants (serveur GICOM et serveurs bancaires). Elles seront réalisées selon le protocole de validation à deux phases.
• ETAPE 5 - Serveur GICOM sécurisé: si le temps le permet, cette étape sera réalisée dans le but d'assurer la confidentialité et l'intégrité des données échangées entre les serveurs, ainsi que l'authentification des entités interagissant. La méthode utilisée pour garantir ces propriétés utilisera la cryptographie à clé publique et à clé secrete.
• ETAPE 6a - Serveur Fournisseur asynchrone  si le temps le permet, cette étape sera réalisée dans le but de passer les commandes auprès des fournisseurs en utilisant une Messagerie Inter-applicative (MOM) permettent l'envoi asynchrone de messages.
• ETAPE 6b - Serveur Fournisseur en mode Web Service si le temps le permet, cette étape sera réalisée dans le but de passer les commandes auprès des fournisseurs en se basant sur les protocoles de base des Web Services (SOAP, ...).

5 Accès aux services supports

6 Déroulement et évaluation du projet

• 17 séances de 3H, assistée par un enseignant. Ces 17 séances sont partagées en
- 5 séances communes aux 2 groupes, dans lesquelles sont présentées les principes des technologies utilisées,
- 6 séances propres à chaque groupe, dans lesquelles un enseignant supervise la mise en oeuvre de l'application.
• 1 stage bloqué sur une semaine (5 journées), également assisté par un enseignant.

• 17 séances de 3H, assistée par un enseignant. Ces 17 séances sont partagées en
- 5 séances communes aux 2 groupes, dans lesquelles sont présentées les principes des technologies utilisées,
- 6 séances propres à chaque groupe, dans lesquelles un enseignant supervise la mise en oeuvre de l'application.
• 4 demi journées libre, également assisté par un enseignant.

Contact auteurs

• Fabienne.Boyer@imag.fr
• Sebastien.Chassande@inrialpes.fr
• David.Feliot@inrialpes.fr
• Sacha.Krakowiak@imag.fr
• Didier.Donsez@imag.fr

• Sebastien.Chassande@inrialpes.fr
• Didier.Donsez@imag.fr

• Gerard.Forestier@imag.fr