L'objectif du projet est de concevoir et de réaliser une application distribuée, dont la mise en oeuvre utilise deux principaux types de services sous-jacents :

Un service Web de Commerce Electronique mis en œuvre au moyen d’une architecture JavaEE (JSP/Servlet, EJB 3)
Une application bancaire mise en œuvre au moyen de CORBA

L'application à réaliser est un serveur de commerce électronique (appelé GICOM) de type "galerie marchande", permettant à des clients de consulter et d'acheter des produits de manière électronique, au travers du web. Au moment du paiement, le serveur de commerce électronique contacte alors les serveurs (CORBA) de l’application bancaire pour réaliser les transferts de fonds.

La suite de ce document décrit :

les fonctionnalités générales de l’application distribuée GICOM
l'architecture globale proposée pour la réalisation de l’application GICOM
les étapes de réalisation

2 Fonctionnalités attendues pour GICOM

L’application GICOM fournit des services à deux types de partenaires : les clients et les fournisseurs de produits.

Les services fournis à un client sont les suivants :

Consultation de catalogues de produits
Remplissage d'un caddie
Demande d'achat des produits présents dans le caddie
Envoi des commandes de produits à livrer aux fournisseurs
Transfert de fond du compte client vers le compte fournisseur entre les serveurs bancaires
Notification de commande au client par courrier électronique

Les points 1,2,3,6 reprennent les fonctionnalités de l’application eCOM (http://ecom.objectweb.org) vu en tronc commun au premier trimestre. Cependant, les terminaux utilisés par le client sont potentiellement de plusieurs types : navigateur Web pour station de travail (MS Internet Explorer, Mozilla, Safari), terminal iMode (cHTML), terminal WAP/WML, JavaPhone (J2ME/CDLC/MIDP).

Le point 4 est réalisé par le sous-système fournisseur. Ce sous-système est constitué de plusieurs serveurs appartenant aux différents fournisseurs.

Le point 5 est réalisé par le sous-système bancaire. Ce sous-système est constitué de plusieurs serveurs bancaires appartenant à plusieurs banques interopérant pour des opérations fiabilisées de transfert de fond. Chaque banque a sa propre architecture répartie avec un serveur centrale de la banque et des serveurs d’agence qui gèrent les comptes de clients.

1 Architecture du serveur GICOM

Cette section décrit l'architecture globale et précise les services supports utilisés pour réaliser l'application GICOM. Ces services supports sont décrits en détail dans les documents présentant les étapes de réalisation de l'application. De manière globale, l'application proposée est composée des parties suivantes (Figure 1) :

Serveur de commerce électronique eCOM (en vert dans la figure 1)

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/JSP et de Entreprise JavaBeans. Les Servlets/JSP assurent le fonctions de présentation de l’application dans les formats acceptés par les terminaux de client (HTML,cHTML,WML, …). Les EJB masquent l’accès au serveur de base de données dans laquelle sont décrit les fournisseurs de la galerie marchande et leurs catalogues de produits, ainsi que les commandes passées par les clients, réalisent l’envoi des mails.

Serveurs de Commande des fournisseurs (en bleu dans la figure 1)

Chaque fournisseur dispose d’un serveur en mode Web Service permettant à ces clients B2B (Business-To-Business) comme le serveur de commerce électronique ECOM de passer des commandes à livrer. Tous les fournisseurs utilisent la même interface de services (exprimé en WSDL) et enregistre leur web-service auprès d’un annuaire UDDI. CES SERVICES NE SERONT PAS IMPLEMENTES DANS LE CADRE DU PROJET mais elle sera prévue dans le serveur de la galerie marchande.

Serveurs Bancaires (en rouge/rose dans la figure 1)

Le sous-système est constitué de plusieurs serveurs bancaires appartenant à plusieurs banques (indépendantes) interopérant pour des opérations fiabilisées de transfert de fond. Chaque banque a sa propre architecture répartie constituée d’un serveur central de la banque et des serveurs d’agence qui gèrent les comptes de clients. Les interfaces entre les serveurs sont définies au moyen d’IDL CORBA et le protocole d’échange est IIOP. Le serveur inter-bancaire sert à référencer les serveurs centraux des banques. Une application de guichet permet la consultation des agences, des clients, des comptes et d’effectuer des créations de comptes client et des opérations de transfert entre les comptes.

Serveur de parité monétaire (en jaune dans la figure 1)

Ce serveur propose des parités à jour entre différentes devises. Ce serveur est un Web Service disponible sur Internet. Vous n’aurez pas à l’implémenter mais à l’utiliser (pour l’initialisation du bean EuroConvertor).

Figure 1. Architecture et techniques utilisées

2 Réalisation

La réalisation de l'application de commerce électronique se fera en 6 étapes décrites ci-après. Chacune des étapes est décrite plus en détail dans un document séparé.

ETAPE 1 - Serveur eCOM étendu : cette étape consiste à réaliser le serveur de commerce électronique eCOM, sans se soucier de son interaction avec le sous-système bancaire, le système fournisseur, le service de parité. Cette étape reprend les résultats du projet eCOM mené au premier trimestre et y ajoute le support des terminaux mobiles et à initialiser la table des parités entre l’Euro et les devises d’usage des clients eCOM au moyen d’un Web Service de parité disponible sur Internet
ETAPE 2 – Sous-système bancaire minimal : cette étape consiste à réaliser une application de gestion bancaire fournissant les services de consultation et de modification des données bancaires (clients, comptes). Chaque banque sera mise en œuvre par un ensemble de serveurs CORBA (représentant un serveur central et plusieurs serveurs d’agence). Dans cette étape, les objets ne sont pas persistants au interruption des serveurs (crash ou arrêt volontaire). Une application standalone sera développée pour consulter et modifier les objets Client et Compte.
ETAPE 3 – Sous-système bancaire persistant: cette étape consiste à rendre persistant les objets gérés par les serveurs de l’application bancaire de manière à assurer que le relancement d'un serveur après un arrêt involontaire ou volontaire permette de récupérer les données bancaires, dans l'état dans lequel elles ont été sauvegardées pour la dernière fois.
ETAPE 4 – Sous système bancaire fiable et persistant: cette étape consiste à fiabiliser les opérations de transfert de fond entre les comptes situés dans des agences différentes. En effet, une panne de serveur peut se produire pendant le transfert et entraîne la réalisation d’un débit (resp. un crédit) sans que le crédit (resp. un débit) correspondant soit effectif. Pour cela, les opérations de modification sur les objets Comptes seront réalisées de manière transactionelle, afin de garantir la conservation de la cohérence du système. Le protocole de validation à deux phases sera utilisé pour valider la transaction distribuée.
ETAPE 5 – Sécurisation des communications: cette étape consiste à sécuriser les communications entre les clients et les services (HTTP,IIOP,SOAP)
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, ...).
ETAPE 7: Administration et Supervision des serveurs si le temps le permet, cette étape sera réalisée dans le but d’administrer et de superviser les serveurs (CORBA) en se basant sur JMX.

Les dépendances entre les étapes sont exprimées ci-dessous :

L’étape 1 dépend du projet eCOM mené au premier trimestre.
L’étape 2 ne dépend de rien.
L’étape 3 dépend de l’étape 2.
L’étape 4 dépend de l’étape 3.
L’étape 5 dépend des étapes 1 et 2.
Les étapes 6a et 6b dépendent de l’étape 1.
Les étapes 6a et 6b dépendent de l’étape 1.
Les étapes 7 dépendent de l’étape 2.
l’intégration du sous-système bancaire à eCOM doit être démarrée dès la fin de l’étape 2.

Vous devrez vous organiser pour mener en parallèle plusieurs étapes vus les contraintes de temps !

3 Accès aux services supports

Tous les supports fournis se trouvent en ligne sur http://www-adele.imag.fr/users/Didier.Donsez/ujf/GICOM/.

Certains éléments du sujet se trouve également sur http://ecom.objectweb.org.

4 Méthodologies et Outils

Vous devez utiliser les outils de développement et de déploiement listés

5 Déroulement et évaluation du projet

Pour M2GI/SRR, le projet GICOM sera réalisé en trinôme, selon le planning suivant :

· ?? séances de 3H, assistée par un enseignant. Ces séances sont partagées en

- 6 séances dans lesquelles sont présentées les principes des technologies utilisées

- 10 séances pendant lesquelles un enseignant supervise la mise en oeuvre de l'application.

- ? séances de travail sans enseignant.

Pour RICM3/SR, le projet GICOM sera réalisé en trinôme, selon le planning suivant :

· ??? séances de 3H, assistée par un enseignant. Ces séances sont partagées en

- ? séances communes aux 2 groupes, dans lesquelles sont présentées les principes des technologies utilisées,

- ? séances propres à chaque groupe, dans lesquelles un enseignant supervise la mise en oeuvre de l'application.

- ? séances de travail sans enseignant.

Une démonstration sera demandée aux trinômes à l'issue du projet. Durant cette démonstration, il faudra mettre en valeur l'état d'avancement du projet, présenter les problèmes importants rencontrés et la manière avec laquelle ils ont été résolus.

6 Démonstration finale

Les PC d’une demi-salle vous sont réservés pour y déployer vos serveurs (l’usage de machine personnelle doit être réduite au minimum pour montrer la configurabilité et deployabilité de votre implémentation.

- Dans le sous-système eCOM, le serveur JOnAS et les serveur Bases de Données devront être sur des machines séparées.

- Le sous-système bancaire doit comporter au moins 2 banques et 3 agences par banque réparties sur des machines séparées.

- Les serveurs WS des fournisseurs sont sur des machines différentes du serveur JOnAS d’eCOM

7 Contacts

Contact contributeurs

Fabienne.Boyer@imag.fr
David.Feliot@scalagent.com
Sacha.Krakowiak@imag.fr
Sebastien.ChassandeBarrioz@rd.francetelecom.com
Didier.Donsez@imag.fr

Contact enseignants RICM3/SR 2007-2008 :

PierreYves.Gibello@experlog.com
Didier.Donsez@imag.fr

Contact enseignants M2GI/SRR 2007-2008:

Sara.Bouchenak@imag.fr
Didier.Donsez@imag.fr
Johann.Bourcier@imag.fr

Contact administrateurs :

Gerard.Forestier@imag.fr

8 Lecture

Un article à propos de GICOM

Boyer F., Chassande-Barrioz S., Donsez D., Féliot D., Krakowiak S. GICOM : un atelier pour l'expérimentation des technologies de systèmes distribués d'entreprise [On-line] TICE 2002, Lyon 13-15 novembre, 2002 [30/04/2003], p. 423-424. Available from internet : <URL:http://docinsa.insa-lyon.fr/tice/2002/ca/ca102.html>