Rapport MIF17 du Projet MIF13-MIF17

M2 Informatique TI – Université Claude Bernard Lyon 1
Rapport CAHD du Projet
Services Web-CAHD
Conception et réalisation d’une application de
consultation et vente de CD enrichie
sémantiquement
Par David CRESCENCE, Thiên Phúc DOAN, Sébastien FAURE
et William VIVET-GROS
2011-2012
Sommaire
Introduction ....................................................................................................... 3
I.
Contraintes techniques imposées ................................................................ 4
II. Nos choix ..................................................................................................... 5
III.
Présentation et pertinence des technologies et standards utilisés ........... 5
IV.
Fonctionnalités mises en place ................................................................. 7
V. Fonctionnalités restant à développer ........................................................... 8
Précisions pour le lancement du projet Maven ................................................ 10
Conclusion........................................................................................................ 10
2
Introduction
Dans le cadre du Master 2 Informatique de l’Université Lyon 1 spécialité Technologies de
l’Information, pour les UE TIW5 et TI1, les étudiants ont pour objectif de concevoir et réaliser une
application web de consultation et vente de CD enrichies sémantiquement.
Le présent rapport a pour but de présenter le travail réalisé en termes de Conception
d’Application Hétérogène Distribuée (TI1) durant le projet. Il présente nos choix, notre cheminement
et nos réalisations dans ce domaine pour atteindre les objectifs définis dans le cahier des charges de
l’application.
3
I. Contraintes techniques imposées
Pour la mise en place de ce projet, un certain nombre de contraintes technologiques nous ont
été imposées par le cahier des charges du projet. La partie Services Web (TIW5) faisant l’objet d’un
rapport séparé, nous n’aborderons ici que les contraintes liées à la partie CAHD. Nous verrons par la
suite que ces contraintes technologiques ne nous ont pas été imposées par hasard mais qu’elles
présentent de nombreux avantages.
Le but de cette partie du projet était de réaliser une version fonctionnelle de l’application métier
côté entrepôt de CD. C’est le partie inférieure du schéma ci-dessus, à savoir les services
CDWareHouseXYZ…
Pour cela, les étudiants devaient mettre en pratique les technologies vues dans l’UE CAHD lors
des différents travaux pratiques. Ainsi la programmation par composants devaient être employées et
les différents composants déployés dans un serveur JBoss/OSGi.
L’application devait exposer en front un service web de commande pour l’application principale
développée précédemment pour la partie TIW5 du projet, mais aussi répondre aux requêtes du
service qui centralise toutes les informations sur les livraisons de CD. Le back office traitant avec les
fabricants. En interne, il fallait en plus gérer des contraintes sur les approvisionnements, les
livraisons, la gestion des stocks et l’envoi direct de CD « rares ».
4
II. Nos choix
Avant toute chose, pour comprendre certains de nos choix, il est nécessaire de présenter
rapidement ce que nous avions fait précédemment dans la partie TIW5 du projet, cela ayant
débouché sur l’application principale avec laquelle la nouvelle application pour les entrepôts va
communiquer.
L’application principale créée et fonctionnelle contient les fonctionnalités suivantes :



L'utilisation des SPARQL endpoints pour enrichir les infos présentées à l'utilisateur ;
L’interaction répartie avec le service bancaire ;
Le processus de commande jusqu’à validation et paiement.
Pour la partie CAHD en particulier, nous avions décidé de permettre la gestion de deux types
d’entrepôts de CD : trois mettant en œuvre un stockage de données de type SQL (nous avons utilisé
MySQL) et un mettant en œuvre un stockage de données de type XML. Cette partie comprend :

La confirmation de la commande et son retrait des entrepôts qui se situe entre la validation
de la commande et le paiement (partie service web) ;

L’approvisionnement des quatre stocks avec une partie backoffice du site.
III. Présentation et pertinence des technologies
et standards utilisés
Serveur JBOSS : JBoss Application Server est un serveur d’applications J2EE Libre entièrement
écrit en Java, publié sous licence GNU LGPL. Parce que le logiciel est écrit en Java, Jboss Application
Server peut être utilisé sur tout système d’exploitation fournissant une machine virtuelle Java (JVM).
C’est un conteneur lourd qui supporte et peut mettre en œuvre la mise en place d’une architecture
de type OSGI.
OSGI : ce framework implémente un modèle de composants dynamique et complet, comblant
un manque dans les environnements Java/VM traditionnels. Les applications et composants (se
trouvant sous la forme de bundles pour le déploiement) peuvent être installés, arrêtés, démarrés,
mis à jour et désinstallés de manière distante sans nécessiter de redémarrage ; la gestion des
classes/paquetages Java est spécifiée de manière très détaillée. La gestion du cycle de vie est
effectuée à travers une API en appliquant une politique de gestion des téléchargements distants. Le
répertoire (registry) de services permet aux bundles de détecter l’addition de nouveaux services, ou
la suppression de services et de s’y adapter
5
Le schéma ci-dessus représente l’architecture que nous avons mise en place pour ce projet. La
mise en place de bundle futurs si la gestion de stocks venait à évoluer a ici été prévue. L’inclusion de
bundle d’aiguillage est assez générique pour, notamment dans notre cas précis, gérer le greffage de
bundle d’ajout/retrait de données de plusieurs sortes. Ici nous avions décidé de gérer les stocks de
CD au format BD relationnelles et XML. On imagine pouvoir mettre en place dans des versions
futures :


La gestion d’autre format de base de données relationnelle comme Postgres, Oracle,
DB2, …
La gestion de bases au format RDF.
Ces versions futures ne sont pas du tout loin de notre livrable actuel puisque nous gérons déjà
MySQL et XML.
Pour ce projet nous avons utilisé un serveur JBoss7 qui avait déjà été fourni lors du TP5. De
même que le support OSGI qui est inclus à cette version de JBoss. Une base MySQL a aussi été
utilisée sur nos machines en local. Pour les bundles web JBoss7 permet l’utilisation de Tomcat.
IV. Fonctionnalités mises en place
L’objet de la partie CAHD du projet de la conception d’une solution de consultation et de vente
de CD était de développer des services permettant la gestion des entrepôts de CD, aussi bien leur
approvisionnement que leur système de livraison.
Tout d’abord pour l’approvisionnement. Nous avons mis en place plusieurs choses :



Une page web back office permettant aux employés d’approvisionner les stocks de nos 4
entrepôts ;
Un service d’aiguillage mettant en relation avec les services de chaque entrepôt ;
Quatre services indépendants d’approvisionnement de CD pour chaque entrepôt.
Chacun de ces services se traduisent par la mise en place de bundles OSGI. La page web fait appel
au service d’aiguillage via sa servlet puis le service d’aiguillage relai ensuite à un des entrepôts. Il y a
deux types d’entrepôts différents : les trois qui sont gérés avec MySQL, et celui géré avec un fichier
XML. Mais tous opèrent par le même mode opératoire : si on ajoute un CD qui n’est pas dans la base
de données, nous créons l’entrée dans la base ou si on ajoute un CD qui est déjà dans la base de
données, nous incrémentons sa quantité (cela est vrai pour la version XML de la même manière que
le SQL).
Voici les noms symboliques de nos services pour l’approvisionnement :



Bundle webapp pour le bundle web du back office ;
service_aiguillage_ajout pour le bundle d’aiguillage ;
service_addx, pour chacuns de nos bundles d’ajout de CD (x=1,2,3,4) avec :
o 1 : base de donnée « stock1 » de notre serveur MySQL
o 2 : base de donnée « stock2 » de notre serveur MySQL
o 3 : base de donnée « stock3 » de notre serveur MySQL
o
4 : fichier XML « base.xml » à la racine de la classe de service du module Maven
« service_add4 »
Ensuite pour la confirmation de la commande. Nous avons mis en place plusieurs composants :



Une page web front office permettant le retrait des CD de la commande des stocks de
nos 4 entrepôts ;
Un service d’aiguillage mettant en relation avec les services de chaque entrepôt ;
Quatre services indépendants de retrait de CD pour chaque entrepôt.
Chacun de ces services se traduisent par la mise en place de bundles OSGI. La page web fait appel
au service d’aiguillage via sa servlet puis le service d’aiguillage relai ensuite à un des entrepôts. Il y a
deux types d’entrepôts différents : les trois qui sont gérés avec MySQL, et celui géré avec un fichier
XML. Mais tous opèrent par le même mode opératoire :



Si on retire un certain nombre de CD dans un entrepôt et que la quantité ne suffit pas (ou
que l’album n’est pas dans la base), la commande n’est pas confirmée et on notifie
l’utilisateur de quels CD ne sont pas disponibles dans l’entrepôt sélectionné ;
Si la quantité est acceptable (au plus la quantité disponible dans l’entrepôt pour ces
albums), l’utilisateur est notifié que la commande s’est déroulé avec succès.
Si la quantité d’un album atteint zéro, l’entrée dans la base est supprimée (cela est vrai
pour nos deux types d’entrepôts)
Voici les noms symboliques de nos services pour le retrait des stocks :



Bundle webapp1 pour le bundle web côté client ;
service_aiguillage_retrait pour le bundle d’aiguillage ;
service_removex, pour chacuns de nos bundles de retrait de CD des stocks (x=1,2,3,4)
avec :
o 1 : base de donnée « stock1 » de notre serveur MySQL
o 2 : base de donnée « stock2 » de notre serveur MySQL
o 3 : base de donnée « stock3 » de notre serveur MySQL
o 4 : fichier XML « base.xml » à la racine de la classe de service du module Maven
« service_add4 »
V. Fonctionnalités restant à développer
Le projet s’étant déroulé sur deux plages différentes du calendrier et portant sur deux parties
(et technologies différentes) il a été difficile d’aboutir à une version finale. Ici, particulièrement
pour la page web de confirmation de commande, la liaison avec la partie servicemix se fait par
passage de paramètres en POST à notre page web. Cela aurait pu être fait d’une manière plus
propre, mais considérant qu’effectivement dans la réalité ces deux pages seraient sur des
serveurs différents, cela a aussi sa pertinence.
8
Toujours à propos de la confirmation de la commande, notre page de test (étant donné que
nous ne vous rendons pas la partie servicemix) contient un formulaire permettant le retrait d’un
seul CD (avec sa quantité associée). Ceci dit le tout est rapatrié dans une HashMap qui est prévu
pour accueillir plusieurs CD. Un autre point est le choix de l’entrepôt dont sont obtenus les CD. Le
mieux était de retirer d’un entrepôt au hasard, ceci dit pour des raisons pratiques (et de test)
nous avons permis le choix de l’entrepôt cible.
L’envoie de CD rares n’a ici pas été traité. Par manque de temps nous n’avons pas pu
implémenter cette fonctionnalité. Ceci dit nous imaginons tout à fait un bundle
service_retrait_rare venant se greffer à l’aiguilleur, celui-ci étant très générique. Ce service
permettrait de gérer des CD rares indépendamment des stocks, passant d’un stock à un autre
pour obtenir la quantité demandé de ce type de CD. Concrètement, il suffirait de gérer quatre
connexions en attribut d’une classe ServiceRemoveRare (au lieu d’une seule par mimétisme avec
nos classes ServiceRemove qui font le retrait).
9
Précisions pour le lancement du projet Maven
Plusieurs précisions sont nécessaires afin de faire fonctionner ce projet sur une machine :




Le chemin absolu du fichier XML dans les classes ServiceRetrait.java et ServiceAjout.java des
modules Maven service_aiguillage_ajout et service_aiguillage_retrait doit être changé ;
Un serveur MySQL (sur le port par défaut) doit être installé, avec un compte root sans mot
de passe. Trois bases de données doivent être créées (stock1, stock2 et stock3) avec chacune
une table albums(titre varchar, artiste varchar, quantite integer) ;
Des bundles précompilés avec les deux contraintes ci-dessus sont déjà présents dans les
dossiers target/ de chacun des modules maven ;
Pour les deux bundles web les manifest.MF à utiliser sont dans les dossiers de génération des
classes (webapp/target/webapp-1.0-SNAPSHOT/META-INF et webapp1/target/webapp1-1.0SNAPSHOT/META-INF). Il suffit de faire un maven install du projet racine et de compresser le
contenu du dossier webapp-1.0-SNAPSHOT (la même chose pour webapp1-1.0-SNAPSHOT
)et en remplaçant le manifest généré par maven (en ayant fait une copie préalable).
Conclusion
Ce projet a été très enrichissant pour nous car il nous a mis en situation réelle de projet en groupe de
quatre. Le fait de travailler en parallèle avec le binôme chargé de la partie CAHD nous a amené à
communiquer efficacement pour de meilleurs résultats.
Certes ce ne fut pas évident puisque certaines technologies étaient nouvelles pour nous et notre
emploi du temps plutôt chargé, mais nous avons finalement beaucoup appris sur ces technologies et
la conception et réalisation d’une application web de taille conséquente.
Alors que le déploiement de services web dans une architecture en bus de services ainsi que
l’interrogation de services du web en SPARQL tels que MusicBrainz étaient au départ assez obscurs
pour nous, nous sommes désormais plus familiers avec la mise en œuvre de ces processus et
pensons en avoir saisi leurs enjeux.
Aussi, ce projet nous a appris à nous répartir des rôles et tirer profit de différents outils de gestion de
projets tout au long de celui-ci afin de profiter au mieux des capacités de chacun, ce qui n’est jamais
aisé dans un groupe plutôt conséquent de quatre personnes.
De plus, il nous a fallu mettre en place certaines techniques pour communiquer entre nous et être
compris de tous, un des membres de l’équipe étant en plein apprentissage de la langue française.
Enfin, nous regrettons de ne pas avoir atteint la totalité de nos objectifs mais sommes conscients que
ce projet nous a tous fait progresser, c’est pourquoi nous pensons continuer le projet à titre
personnel et arriver un jour à son terme, ce qui serait, pour nous, une réelle satisfaction.
10