conception dapplication cloud sur google app engine
TRANSCRIPT
UNIVERSITE D’ANTANANARIVO
ECOLE SUPERIEURE POLYTECHNIQUE
DEPARTEMENT ELECTRONIQUE
---------------------
MEMOIRE DE FIN D’ETUDES en vue de l’obtention du
DIPLOME D’INGENIEUR EN ELECTRONIQUE Option: Informatique Appliquée
CONCEPTION D’APPLICATION CLOUD SUR GOOGLE APP ENGINE
- DEVELOPPEMENT DE LA PARTIE TRAITEMENT DE AN-TANANA v1.0 -
Rapporteur : Madame RABEHERIMANANA Lyliane Irène
Présenté par :
TSIFERANARIVO Nasolo Michel
Soutenu le 13 Septembre 2013
N° d’ordre : Année Universitaire : 2011-2012
UNIVERSITE D’ANTANANARIVO
ECOLE SUPERIEURE POLYTECHNIQUE
DEPARTEMENT ELECTRONIQUE
---------------------
MEMOIRE DE FIN D’ETUDES en vue de l’obtention du
DIPLOME D’INGENIEUR EN ELECTRONIQUE Option: Informatique Appliquée
CONCEPTION D’APPLICATION CLOUD SUR GOOGLE APP ENGINE
- DEVELOPPEMENT DE LA PARTIE TRAITEMENT DE AN-TANANA v1.0 -
Présenté par :
Le 13 Septembre 2013
TSIFERANARIVO Nasolo Michel
Devant les membres du jury:
Président :
Examinateur :
Examinateur :
Examinateur :
Rapporteur :
Monsieur RATSIMBA Mamy Nirina
Monsieur RATSIMBAZAFY Guy Predon
Monsieur RANDRIAMAROSON Rivo Mahandrisoa
Monsieur HERINANTENAINA Edmond Fils
Madame RABEHERIMANANA Lyliane Irène
i
REMERCIEMENTS
En premier lieu, je remercie Dieu tout puissant pour sa grâce et sa bonté, de m’avoir donné la force
et l’intelligence de réaliser ce mémoire.
Je tiens ensuite à adresser mes vifs remerciements et ma profonde gratitude à:
Monsieur RATSIMBA Mamy Nirina, Chef du Département Electronique et Président du
jury de cette soutenance de mémoire de fin d’études.
Messieurs les membres du jury pour avoir accepté d’examiner et pris le soin d’évaluer ce travail
malgré leurs obligations :
Monsieur RATSIMBAZAFY Guy Predon
Monsieur RANDRIAMAROSON Rivo Mahandrisoa
Monsieur HERINANTENAINA Edmond Fils
Madame RABEHERIMANANA Lyliane Irène, mon directeur de mémoire, qui m’a toujours
soutenu et dirigé, pour ses directives et remarques, ainsi que pour la confiance qu’elle m’a
accordée durant la préparation de ce mémoire.
Tous les enseignants du Département Electronique, ainsi que les enseignants et responsables de
l’Ecole Supérieure Polytechnique qui ont assuré notre formation durant ces cinq années d’études.
Enfin, je ne saurais oublier de remercier mes parents et familles pour leur soutien inconditionnel
et leur amour.
Toutes les personnes qui ont contribué, de près ou de loin, à l’élaboration du présent mémoire.
A vous tous, merci infiniment! Nasolo
ii
RESUME
Le Cloud Computing est une récente application se basant sur l’utilisation des systèmes
informatiques à distance en tant que service. Il s’agit d’un ensemble de techniques basées sur les modes
de communication web et sur le modèle de l’architecture client-serveur. Il offre principalement trois
modèles de service: l’infrastructure, la plateforme et le logiciel. A travers ces services découle son
exploitation : hébergement de données dans des serveurs distants et accès aux ressources à distance. Le
présent mémoire concerne la conception d’application en mode Cloud Computing. Dans ce travail, j’ai
voulu montrer l’applicabilité de ce nouveau concept. A cet effet, j’ai contribué à un projet de conception
d’un logiciel cloud public dénommé An-tànana où j’étais le développeur de la partie traitement. Le
logiciel est hébergé et déployé sur la plateforme Google App Engine. De ce fait, il exploite les ressources
du fournisseur. Les unités de traitement (et de stockage) utilisées par l’application sont celles de Google.
L’interaction entre l’utilisateur et l’application s’effectue à l’aide d’Internet. Son interface est donc une
interface web. An-tanana a été conçu pour la gestion des réservations hôtelières, il a pour objectif
principal de montrer aux utilisateurs que l’on peut s’en passer de ses propres appareils électroniques pour
continuer un travail en cours en profitant du Cloud Computing. Ceci permet ici à un gérant d’hôtel
d’accéder et de modifier ses données n’importe où et à tout moment.
iii
ABSTRACT
Cloud computing is a new concept based on the use of remote resource as a service. It gather web technologies and Client-server architecture. There are mainly three kinds of service’s model: hardware, platform and software. Thus, client can take advantage of data storing and remote resources through those different services. This dissertation is focused on the study and design of Cloud Computing application. It also works to use Java language with Google App Engine in order to develop a software named An-tànana as a public cloud application where . This software developed in the Google App Engine platform calls to the computer-related technologies and skills put forwarded in the newly developed concept of Cloud Computing. The application use the Google Platform performance and can be accessed via Internet. It has web page as interface. An-tànana takes the management of hotel bookings as showcase and aims to show how users can secure their data and have access to them without being dependent of their own electronic host equipment by simply relying on the Cloud Computing effectiveness. It results in greater mobility for the hotel manager to check by himself at any moment, at any place and from any computer-like equipment the situation in the hotel.
iv
TABLE DES MATIERES
REMERCIEMENTS………………………………………………………………………………………………………………………..……………i
RESUME…………………………………………………………………………………………………………………………………….…………….ii
ABSTRACT……………………………………………………………………………………………………………………………………………….iii
TABLE DES MATIERES………………………………………………………………………………………………………………………………iv
LISTE DES ABREVIATIONS ET ACRONYMES………………………………………………………………………………………………vii
LISTE DES FIGURES ................................................................................................................................ viii
LISTE DES TABLEAUX ................................................................................................................................ x
INTRODUCTION ……………………………………………………………………………………………………………………………….. 1
CHAPITRE 1 : PRESENTATION DU CLOUD COMPUTING
1.1 HISTORIQUE ................................................................................................................................ 2
1.2 DEFINITIONS................................................................................................................................ 4
1.2.1 Cloud Computing ................................................................................................................. 4
1.2.2 Nuage .................................................................................................................................. 4
1.2.3 Datacenter........................................................................................................................... 4
1.2.4 Virtualisation ....................................................................................................................... 5
1.3 MODELES DE SERVICE.................................................................................................................. 6
1.3.1 IAAS (Infrastructure As A Service) ......................................................................................... 7
1.3.2 PAAS (Platform As A Service) ............................................................................................... 7
1.3.3 SAAS (Software As A Service) ............................................................................................... 7
1.4 TYPES DE CLOUD COMPUTING .................................................................................................... 8
1.4.1 Cloud public ......................................................................................................................... 8
1.4.2 Cloud privé .......................................................................................................................... 9
1.4.3 Cloud hybride .....................................................................................................................10
CHAPITRE 2 : TECHNOLOGIES DU WEB ET DU CLOUD COMPUTING
2.1 PRINCIPES GENERAUX ................................................................................................................12
2.1.1. Architecture client-serveur .................................................................................................12
2.1.2. TCP/IP et Cloud Computing .................................................................................................13
2.2. GOOGLE APP ENGINE .................................................................................................................14
2.2.1 Présentation générale.........................................................................................................14
v
2.2.2 Environnement d’exécution ................................................................................................15
2.2.3 Datastore............................................................................................................................15
2.3. SERVLETS ET JSP .........................................................................................................................18
2.3.1 Conteneur Web ..................................................................................................................18
2.3.2 Servlet ................................................................................................................................20
CHAPITRE 3 : DEVELOPPEMENT DU LOGICIEL AN-TANANA V 1.0
3.1 CAHIER DES CHARGES.................................................................................................................23
3.1.1 Présentation du logiciel ......................................................................................................23
3.1.2 Fonctionnalités ...................................................................................................................23
3.1.3 Besoins matériels ................................................................................................................23
3.1.4 Besoins fonctionnels ...........................................................................................................23
3.1.5 Besoins non fonctionnels ....................................................................................................24
3.1.6 Règles de gestion ................................................................................................................24
3.1.7 Maintenance du logiciel ......................................................................................................24
3.2 MODELE DU SYSTEME ................................................................................................................25
3.2.1 Configuration de l’application .............................................................................................25
3.2.2 Système de réservation ......................................................................................................26
3.3 MODELISATION PAR UML ET CODAGE ........................................................................................27
3.3.1 Architecture de l’application ...............................................................................................27
3.3.2 Diagramme de cas d’utilisation ...........................................................................................29
3.3.3 Codage ...............................................................................................................................31
CHAPITRE 4 : MODE D'ACCES A AN-TANANA V1.0
4.1 COMPTE AN-TANANA .................................................................................................................34
4.1.1 Connexion d’un utilisateur ..................................................................................................34
4.1.2 Création de compte An-tànana ...........................................................................................35
4.2 MANIPULATION PAR L’ADMINISTRATEUR ...................................................................................36
4.2.1 Configurations initiales du logiciel .......................................................................................36
4.2.2 Spécification tarifs et utilisateurs ........................................................................................38
4.2.3 Affichage des informations concernant l’hôtel ....................................................................39
4.3 MANIPULATION PAR UN UTILISATEUR ........................................................................................40
4.3.1 Création d’une nouvelle réservation ...................................................................................41
vi
4.3.2 Affichage ............................................................................................................................43
4.3.3 Mise à jour d’une réservation .............................................................................................44
4.3.4 Suppression d’une réservation ............................................................................................44
4.3.5 Facturation .........................................................................................................................45
CONCLUSION……………………………………………………………………………………………………………………………………47
ANNEXES
ANNEXE 1 : OUTILS JAVA ........................................................................................................................49
A1.1 Descripteurs de déploiement ....................................................................................................49
A1.2 Servlets .....................................................................................................................................50
A1.3 Implémentation de données avec JDO et l’API Datastore ..........................................................51
A1.4 JSP (Java Server Page) ...............................................................................................................52
A1.5 Outil de développement : Eclipse ...............................................................................................53
ANNEXE 2 : MODELISATION DU LOGICIEL AN-TANANA v1.0 ...................................................................55
REFERENCES …………………………………………………………………………………………………………………………………… 58
vii
LISTE DES ABREVIATIONS ET ACRONYMES
API : Application Programming Interface
ARPANET : Advanced Research Projects Agency Network
ASP : Application Service Provider
CCITT : Comité consultatif international téléphonique et télégraphique
CERN : Conseil Européen pour la Recherche Nucléaire
CPU : Central Processing Unit
CSS : Cascading Style Sheets
EC2 : Elastic Compute Cloud (Amazon)
EJB : Entreprise Java Bean
GAE : Google App Engine
HTML : Hypertext Markup Language
HTTP : Hypertext Transfer Protocol
IAAS : Infrastructure As A Service
IDE : Integrated Development Environment
ISO : International Organization for Standardization
JAAS : Java Authentication and Authorization Service
Java EE : Java Enterprise Edition
JDO : Java Data Objects
JPA : Java Persistence API
JSP : Java Server Pages
LAN : Local Area Network
NoSQL : Not Only SQL
OMG : Object Management Group
PAAS : Platform As A Service
RAM : Random Access Memory
SAAS : Software As A Service
SDK : Software Development Kit
SGBDR : Système de Gestion de Base de Données Relationnel
SQL : Structured Query Language
TCP/IP : Transmission Control Protocol/Internet Protocol
UML : Unified Modeling Language
URL : Uniform Resource Locator
VPN : Virtual Private Network
XML : Extensible Markup Language
viii
LISTE DES FIGURES
Figure 1. 1: Chronologie de l’Informatique et du Cloud Computing ................................................... 4
Figure 1. 2: Cloud Computing - nuage – datacenter ............................................................................ 5
Figure 1. 3: Architecture d’une virtualisation ..................................................................................... 6
Figure 1. 4: Modèle de service Cloud- Clients ..................................................................................... 6
Figure 1. 5: Modèle de service - détails .............................................................................................. 8
Figure 1. 6 : Cloud public .................................................................................................................... 9
Figure 1. 7 : Cloud Privé .................................................................................................................... 10
Figure 1. 8 : Cloud hybride ................................................................................................................ 10
Figure 2. 1 : Architecture client-serveur ........................................................................................... 12
Figure 2. 2 : Architecture Client-Serveur en Cloud Computing .......................................................... 13
Figure 2. 3: TCP-IP et Cloud Computing ............................................................................................ 13
Figure 2. 4 : Architecture générale de Google App Engine ................................................................ 14
Figure 2. 5 : Structure du Datastore .................................................................................................. 15
Figure 2. 6 : Interaction entre une application et Datastore (implémentation en Java) ................... 18
Figure 2. 7 : Contrôleur et cycle de vie d'un servlet ......................................................................... 19
Figure 2. 8 : Classes et Interface parents des servlets ....................................................................... 20
Figure 3. 1 : Modèle de la configuration de l’application .......................................................................25
Figure 3. 2 : Modèle du système de réservation de l’application An-tànana .........................................26
Figure 3.3 : Architecture en trois couches [20] ......................................................................................28
Figure 3. 4 : Diagramme de déploiement d’An-tànana v1.0 ..................................................................29
Figure 3. 5 : Diagramme de cas d'utilisation d’An-tànana .....................................................................30
Figure 3. 6 : Processus de traitement dans An-tanana v1.0 ...................................................................31
Figure 3. 7 : Servlets et JSPs d’An-tanana v1.0 ......................................................................................32
Figure 3. 8 : Diagramme de classe des données .....................................................................................33
Figure 4. 1 : Connexion avec le système de gestion d’utilisateur de Google ..................................... 34
Figure 4. 2 : Création de compte An-tànana ..................................................................................... 35
Figure 4. 3 : Connexion à An-tànana – Utilisateur non agrée ............................................................ 36
Figure 4. 4 : An-tànana – Page d’accueil ........................................................................................... 36
Figure 4. 5 : An-tànana- Page de configuration ................................................................................. 37
Figure 4. 6 : Configurations Initiales dans An-tànana v1.0 ................................................................ 37
Figure 4. 7 : An-tànana – Initialisations des tarifs ............................................................................. 38
Figure 4. 8 : An-tànana – Ajout d’un utilisateur ................................................................................ 38
Figure 4. 9 : Configuration des tarifs des chambres .......................................................................... 39
Figure 4. 10 : Affichage des informations concernant un hôtel abonné à An-tànana ....................... 40
Figure 4. 11 : Page ‘client’ ................................................................................................................. 40
Figure 4. 12 : Page ‘réservation’ ....................................................................................................... 41
Figure 4. 13 : Formulaire de renseignement client ........................................................................... 42
Figure 4. 14 : Formulaire de création d’une réservation ................................................................... 42
Figure 4. 15 : Formulaire pour la recherche d’un client .................................................................... 43
ix
Figure 4. 16 : Affichage des clients.................................................................................................... 43
Figure 4. 17 : Affichage des réservations .......................................................................................... 44
Figure 4. 18 : Page de mise-à-jour d’une réservation ........................................................................ 44
Figure 4. 19 : Formulaire pour la suppression d’une réservation ...................................................... 45
Figure 4. 20 : Formulaire pour la génération d’une facture .............................................................. 45
Figure 4. 21 : Exemple d’une facture ................................................................................................ 46
x
LISTE DES TABLEAUX
Tableau I : Historique du Cloud Computing ........................................................................................2
Tableau II : Comparaison du Datastore avec un SGBDR .................................................................... 17
Tableau III: Description des cas d'utilisation d’An-tànana ................................................................ 31
Tableau A. 1 : Balises JSP .......................................................................................................................52
Tableau A. 2 : Description des scénarios ................................................................................................56
1
INTRODUCTION
Les NTIC ou nouvelles technologies de l’information et de la communication ont eu un
développement accéléré grâce à la combinaison de l’électronique, de l’informatique et de la
télécommunication. Elles ont trouvé des applications variées, impensables il y a quelques décennies, dans
différents domaines tant publics que privés. Les matériels et équipements nécessaires à leur utilisation
ont également évolué avec des innovations fulgurantes. Les ordinateurs ont gagné en vitesse de
traitement, en capacité de mémoire et en mobilité en ayant des tailles plus réduites.
De nouvelles applications se sont en même temps développées pour faciliter et élargir davantage
le bénéfice des services offerts par les technologies disponibles. Le Cloud Computing en constitue une des
dernières qui se trouvent en phase de lancement depuis quelques années par les grandes sociétés en
informatique.
Le Cloud Computing contribue à apporter des solutions aux problématiques posées par la forte
dépendance de l’utilisateur de son matériel (ordinateur ou autre) qui héberge ses données. Cette
dépendance l’oblige à transporter son matériel pour pouvoir en consulter le contenu au cours de tous ses
déplacements. Ce transport permanent est source d’inconfort et d’encombrement lors des déplacements
et voyages, avec un surcroît de risques de perte ou de chocs dommageables. Mais ce matériel est
également exposé à d’autres risques importants tels que perte des données due à des attaques par des
virus ou de pannes, etc. Les solutions clés apportées par le Cloud Computing se trouvent ainsi dans la
notion de mobilité et de sécurité.
Le caractère récent et la puissance de cette application m’a intéressé à l’étudier davantage afin
de pouvoir la maîtriser. C’est ainsi que j’ai contribué dans un projet de mise en place d’une application
Cloud public. Je me suis engagé dans ce mémoire de fin d’études dont le sujet s’intitule Conception
d’application cloud sur Google App Engine – Développement de la partie traitement de An-tànana v1.0
-
L’objectif de ce travail est d’approfondir les connaissances sur le fonctionnement du Cloud
Computing afin de fournir un outil informatique susceptible d’utilisation élargie. En participant au
développement du logiciel - An-tànana -, j’ai soutenu la pertinence et la faisabilité de l’exploitation du
Cloud Computing. Mais j’aurais également relevé ses limites et contraintes, notamment dans le contexte
local.
Cet ouvrage comprend quatre chapitres. Le premier chapitre présentera le Cloud Computing. Le
deuxième chapitre exposera les technologies utilisées et détaillera les théories correspondantes. Le
troisième chapitre se focalisera sur les différentes phases de conception d’An-tànana v1.0, en particulier
la modélisation. Le dernier chapitre montrera les fonctionnalités du logiciel, résultat même de ce travail.
2
Chapitre 1
PRESENTATION DU CLOUD COMPUTING
L’informatique a évolué très rapidement durant ces dernières décennies. Le Cloud Computing
définit un nouveau concept qui s’est développé tout dernièrement et dont les entreprises et sociétés,
aussi bien celles de petite taille que les grandes, songent à tirer profit de ses avantages. Ce chapitre
présente, dans un premier temps, un bref historique de l’origine du Cloud Computing. Il expose ensuite
quelques définitions des termes autour du Cloud Computing ainsi que les modèles de service existants.
Les différents types de Cloud Computing clôtureront le chapitre.
1.1 HISTORIQUE
Le développement du Cloud Computing est lié à celui de l’informatique en général et de l’Internet
en particulier. Même si le procédé de transfert de services depuis un serveur distant n’a vraiment eu lieu
qu’au début des années 1990 (tableau 1), le désir de pouvoir bénéficier, et implicitement vendre, des
services complexes utiles en ayant de simples infrastructures, a été toujours présent dans l’esprit des
usagers. La figure 1.1 résume l’historique du Cloud Computing.
Tableau I : Historique du Cloud Computing
Dates Evènements
1990
internet devient Internet
Le CERN (Conseil Européen pour la Recherche Nucléaire) met à la
disposition du public des utilisations non commerciales d’Internet.
Tim Berners-Lee et Robert Cailliau développent les standards
formant l’aspect d’Internet composé de pages web.
1993
Arrivée des logiciels
accélérant la prise en main
d’Internet
Apparition du navigateur Mosaic.
Apparition et entrée de Netscape dans les PC ou Personal Computer.
1995
Augmentation du commerce
en ligne.
Pierre Omidyar crée l’EBAY encore appelé AuctionWeb.
Jeff Bezos crée la société Amazon.
3
1995
Les grandes sociétés
adoptent les datacenters
Apparition de l’ASP (Application Service Provider), offre permettant
au client de louer l’accès à un logiciel installé sur les serveurs
distants d’un prestataire, sans installer le logiciel sur ses propres
machines.
L’explosion des utilisateurs entraine la création de datacenters
performants.
1996
Naissance de l’IAAS
(Infrastructure As A Service)
Location des datacenters avec adaptation et facturation
proportionnelles aux besoins des clients
Par la suite, plusieurs sociétés ont emboité le pas d’Amazon.
1998
Fondation de Google
Google, une société fondée dans la Silicon Valley, en Californie, par
Larry Page et Sergey Brin, est mise en place. Elle a pour principale
activité la conception de moteur de recherche pouvant concurrencer
ceux de l’époque, mais sera dans le futur, parmi les acteurs des
solutions infonuagiques.
1999
Création d’application
d’entreprise par Salesforce,
naissance des SAAS
Salesforce a été créé par Marc Benioff, Parker Harris, Dave
Moellenhoff et Frank Dominguez. Cette société offre des logiciels de
gestion en ligne pour les entreprises.
Les années 2000
Naissance de nombreuses
offres Cloud
Les grandes sociétés informatiques cherchent de nouveaux marchés
sur Internet
2002
Lancement de Méchanical
Turk
Mechanical Turk, un des sites d’Amazon, voit le jour. Il permet
d’utiliser le Cloud Computing à transférer des taches spécifiques
impossibles pour les ordinateurs chez des humains (Turkers).
2007
Lancement de Force.com
(PAAS)
SalesForce lance Force.com, une plateforme de développement
d’application pour les développeurs externes.
2008
Lancement de Windows
Azure
Microsoft lance également sa plateforme applicative rassemblant
applications, données et services en nuage.
2009
Sortie de la version bêta de
Google App Engine
Google sort la version bêta de « Google App Engine », une
plateforme permettant le développement et l’exécution
d’applications.
4
2009 Lancement de Google App Engine
2007Salesforce lance
Force.com
2002Lancement de
Mechanical Turk
1999Salesforce crée les
applications d’entreprise
1995 Fondation
d’Amazon et d’eBay
1991Le CERN met Internet à la
disposition du grand public
1990
2000
Evolution importante des
ordinateurs et de l’informatique
2008Lancement de
Windows Azure
Figure 1. 1: Chronologie de l’Informatique et du Cloud Computing [1]
1.2 DEFINITIONS
La terminologie communément utilisée comporte les notions ci-après :
1.2.1 Cloud Computing
« Le Cloud Computing est un procédé consistant à transférer sur des serveurs situés à distance
des fichiers ou des bases de données conservés auparavant dans les serveurs locaux ou sur l’ordinateur
personnel » [2].
Le Cloud Computing, appelé aussi Informatique dans les nuages ou infonuagique, se réfère ainsi
à la manière d'utiliser la technologie informatique et d’exploiter les systèmes et ressources y afférents
(matériels, logiciels) localisés à distance, à la place de ceux qui sont en local, afin que les acteurs puissent
fournir ou consommer des services via l’Internet.
1.2.2 Nuage
« Un nuage est un parc de machines, d'équipements de réseau et de logiciels maintenu par un
fournisseur, que les consommateurs peuvent utiliser en libre-service via Internet. Les caractéristiques
techniques du nuage ne sont pas connues du consommateur et les services sont payés à l'usage. » [3]
Le nuage, venant de l’anglais cloud désigne l’ensemble des matériels et logiciels permettant de
fournir les services Cloud. Il est formé surtout par un ou plusieurs datacenters. Son appellation vient
également du fait que les clients utilisent les dispositifs sans en connaitre nécessairement les
caractéristiques techniques.
1.2.3 Datacenter
Les datacenters sont les centres informatiques de traitement de données utilisés par les grandes
sociétés travaillant sur Internet. Ils servent principalement à gérer de nombreux serveurs. Un datacenter
est formé de plusieurs équipements tels les racks de serveurs, le système de climatisation, le système de
prévention contre l'incendie, etc. (Fig. 1.2)
5
NUAGE
UTILISATEURS
DATACENTER DATACENTER
INTERNET
serveur
Figure 1. 2: Cloud Computing - nuage – datacenter
1.2.4 Virtualisation
La virtualisation est l’ensemble de techniques qui permettent d’exécuter plusieurs machines
virtuelles sur une seule machine physique [4]. Chaque machine virtuelle partage un même ensemble de
ressources physiques (Fig 1.3).
La virtualisation est régie par deux principes fondamentaux : le cloisonnement et la transparence.
Le cloisonnement permet à chaque système d’exploitation de fonctionner les uns indépendamment des
autres. La transparence indique que le mode virtualisé ne change rien au comportement des systèmes
d’exploitation et des applications.
La virtualisation de serveurs est un ensemble de techniques et d’outils permettant de faire
tourner plusieurs systèmes d’exploitation sur un même serveur physique. Le principe de la virtualisation
est donc un principe de partage : les différents systèmes d’exploitation se partagent les ressources du
serveur. Dans le cas d’une virtualisation du stockage, la virtualisation permet de masquer les spécificités
physiques des unités de stockage. Côté utilisateur, les unités de stockage sont vues comme un unique
volume.
La virtualisation d’un ordinateur physique est l’exemple le plus basique dans ce concept. Mais à
grande échelle, la mise en place d’une infrastructure complète virtuelle se réalise en intégrant plusieurs
ordinateurs/serveurs physiques et périphériques de stockages interconnectés avec une plateforme de
virtualisation. Ainsi se forme la base de développement du Cloud Computing.
6
Figure 1.3: Architecture d’une virtualisation
1.3 MODELES DE SERVICE
Les modèles de service divisent les offres Cloud en trois catégories : le matériel, la plateforme et le
logiciel. Ainsi, trois différents modèles de service existent. Chacun a ses spécificités qui s’adaptent à
chacun des besoins des clients. La figure 1.4 représente ces modèles de service avec les types de client
correspondants.
Figure 1.4: Modèle de service Cloud- Clients
SAAS
PAAS
IAAS
Client: simple utilisateur
Client:Informaticiens
SAAS: Software as a ServicePAAS: Platform as a ServiceIAAS: Infrastructure as a Service
7
1.3.1 IAAS (Infrastructure As A Service)
L’IAAS ou l’infrastructure comme un service est une offre permettant à un client de disposer d'une
infrastructure à la demande. Elle est également appelée « Hardware As A Service ». A la différence d’un
modèle classique où l’utilisateur gère lui-même les équipements informatiques, les matériels, l’électricité
et les configurations nécessaires sont ici déportés chez le prestataire. Les serveurs, systèmes de stockage,
commutateurs, routeurs et autres équipements, sont mis à disposition pour gérer une charge de travail
demandée par les applications. Ainsi, l’entreprise gérera l’ensemble des fonctionnalités de base. De ce
fait, la présence d’un administrateur système est toujours nécessaire pour cette solution.
Pour permettre la virtualisation de plusieurs systèmes d’exploitation en nuage, les prestataires
IAAS installent d’abord un programme servant de système d’exploitation pour d’autres systèmes
d’exploitation dans leurs serveurs : c’est l’hyperviseur [5]. Ce dernier sert à arranger l’exécution des
machines virtuelles des clients. Ainsi une application lancée sur un système d’exploitation peut être vue
dans d’autres systèmes d’exploitation gérés par le même hyperviseur juste en l’instanciant sans la copier
physiquement. En effet, l’architecture d’un hyperviseur permet de charger un (ou plusieurs) système
d’exploitation quelconque comme s’il était tout simplement un autre programme. Parmi les prestataires
d’IAAS, Amazon avec EC2 en est un.
1.3.2 PAAS (Platform As A Service)
La PAAS ou plateforme comme un service est la plateforme d’exécution, de déploiement et de
développement d’applications. En plus de l’infrastructure, ce modèle met à la disposition des clients une
plateforme prête pour la conception et l’exécution de logiciels. Cette plateforme est gérée par le
fournisseur et ne peut en aucun cas être modifiée par le client. Il suffit que la fonction logicielle soit
correctement et continuellement assurée. Chacune des sociétés de Cloud Computing a ses techniques
pour garantir le bon fonctionnement des services. Les principales techniques à assurer sont : le
basculement (fail-over) et la répartition de charge (load-balancing) [6]. Dans cette offre, les clients
profitent des APIs (Application Programming Interface) pour les communications avec les serveurs
physiques, des systèmes de base de données, etc.
1.3.3 SAAS (Software As A Service)
Le SAAS ou logiciel comme un service permet de déporter chez le prestataire l'application utilisée
par le client. En d’autres termes, le fournisseur gère l’ensemble allant de l’infrastructure physique jusqu’à
l’exécution de l’application. Dans ce cas, le client se contente de l’utilisation. Ainsi, l’installation, la mise à
jour et la migration des données sont faites automatiquement pour ce type de service. Les clients
consomment les logiciels à la demande avec une facturation à l’usage réel, ceci sans acheter des licences.
Les solutions SAAS constituent la forme la plus répandue du Cloud Computing. Les prestataires de
SAAS les plus connus sont : Google avec Gmail, Youtube ou encore les réseaux sociaux Facebook et Twitter.
La figure 1.5 présente les détails des modèles de service Cloud.
8
1.4 TYPES DE CLOUD COMPUTING
Trois principaux types de Cloud existent : le Cloud public, le Cloud privé et le Cloud hybride. Chaque
type est proposé en fonction des besoins de l’utilisateur (entreprise).
1.4.1 Cloud public
Il s’agit de cloud public lorsque le service peut être accédé par le grand public. Les données et les
ressources se situent dans des datacenters distants. C’est une stratégie de déploiement où les utilisateurs
ont accès aux services via Internet. Le cloud public est fourni principalement par les géants de l’industrie
informatique comme Amazon, Windows ou Google [7]. L’utilisateur bénéficie des énormes ressources et
des espaces de stockage très volumineux de son fournisseur. Le cloud public est le type de référence dans
le domaine du Cloud Computing.
Concrètement, ces prestataires de service louent l’utilisation de leurs serveurs. Généralement, la
facturation s’effectue en fonction des ressources consommées par l’utilisateur (CPU, RAM, Stockage, etc.).
L’utilisateur ignore l’emplacement des datacenters dans lesquels ses données sont stockées. D’ailleurs,
ces dernières peuvent être hébergées ou répliquées d’un datacenter à un autre sans qu’il s’en aperçoive.
----------------------------------
PAAS
----------------------------------
IAAS
Réseaux Serveurs Stockage CPU
Virtualisation Système
d’exploitation
Base de données
Moteur applicatif
Informatique Finance Production Décisionnel
----------------------------------
SAAS
Hyperviseur
APIs
Environnement de développement/test
Applications
Environnement d’exploitation
Infrastructure physique
Figure 1.5: Modèle de service - détails
9
Figure 1.6 : Cloud public
1.4.2 Cloud privé
Il s’agit de cloud privé lorsque le service ne peut être accédé que par un nombre restreint
d’utilisateurs. Il est dédié exclusivement à l'entreprise. Cette dernière garde la maîtrise du cycle de vie de
ses applications et de ses données. Le service offert par le cloud privé peut être accédé via un LAN (Local
Area Network – Réseau Local) ou Internet, mais en général il est exploité via des réseaux sécurisés de type
VPN (Virtual Private Network – Réseau Privé Virtuel). Contrairement au cloud public, il est limité par les
ressources de l’infrastructure employée. Toutefois, deux configurations de cloud privé sont possibles: le
cloud privé interne et le cloud privé externe (Fig 1.7).
Le cloud privé interne permet à une entreprise de déployer son propre cloud sur ses propres
infrastructures physiques. L’entreprise gère alors elle-même son système. Ce modèle de déploiement est
réalisé à l’aide du principe de la virtualisation de l’infrastructure de l’entreprise. Par contre, le cloud privé
externe est géré par un prestataire de service. Dans ce cas, ce dernier loue son infrastructure (dédiée) à
l’entreprise.
Amazon, Windows,Google, …
INTERNET
UTILISATEUR
UTILISATEUR
UTILISATEUR
10
LAN / INTERNET / VPN
Utilisateur
Infrastructure de l’entreprise
(interne)Infrastructure d’un
prestataire (externe)
Figure 1.7 : Cloud Privé
1.4.3 Cloud hybride
Le cloud hybride est une combinaison du cloud public et du cloud privé (Fig 1.8). C’est un
environnement Cloud Computing dans lequel l’entreprise fournit et gère des ressources en interne et
utilise d’autres ressources fournies de l’extérieur (via Internet).
Figure 1. 8 : Cloud hybride
Le choix entre ces différents types de cloud repose sur les besoins de l’utilisateur. Si l’utilisateur
possède déjà des serveurs et que ses besoins sont constants, il est préférable qu’il opte pour le cloud
privé. Il suffit de virtualiser son infrastructure. Ainsi, l’entreprise peut profiter de son propre cloud. Elle
peut aussi utiliser ce type de cloud dans le cas où elle veut contrôler ses données et ses applications. Dans
HYBRIDE
PRIVE PUBLIC
11
ce cas, l’utilisateur entreprend ses propres moyens de sécurité. Par contre, si l’utilisateur ne possède pas
encore de serveur ou qu’il ne veut pas investir dans un parc de serveurs complet, il est recommandé
d’utiliser le cloud public. Enfin, si l’utilisateur possède des serveurs mais ses activités fluctuent de manière
significative et demandent ponctuellement des capacités plus fortes, il est conseillé d’opter pour le cloud
hybride.
Du fait de sa performance et de ses caractéristiques, le Cloud Computing peut être exploité à des
fins multiples. Il constitue non seulement un outil très ergonomique pour les utilisateurs, mais aussi
contribue fortement dans le concept de l’informatique en tant que service. Les services cloud les plus
répandus sont les services de messageries en ligne (Webmail) tels que Yahoo, Gmail, Live etc. Le Cloud
Computing peut également être exploité comme service de stockage en ligne. L’utilisateur peut
sauvegarder ses données dans le cloud. Il peut se passer de son propre support de stockage (disque dur,
disques amovibles, etc.) et permet ainsi d’éviter les risques de pertes de données (endommagement ou
pertes de ces supports). Les services SkyDrive (Microsoft), Dropbox ainsi que GoogleDrive en sont des
exemples. Les logiciels en ligne constituent un autre exemple d’application du Cloud Computing et font
de plus en plus partie des solutions informatiques d’entreprise. Les logiciels en question ne sont donc plus
installés sur l’ordinateur de l’utilisateur mais hébergés dans le cloud. Enfin, certains secteurs comme la
finance ou la recherche scientifique ont besoin d’une grande puissance de calcul pendant un temps
déterminé que leurs équipements ne permettent pas toujours de satisfaire. Le Cloud Computing peut
alors se présenter comme solution à cette situation. En effet, les technologies déployées par le système
cloud offrent une puissance accrue pour les traitements de données.
12
Chapitre 2 TECHNOLOGIES DU WEB ET DU CLOUD COMPUTING
Les applications cloud héritent de technologies informatiques standards. Elles utilisent les
technologies sur Internet bien que certaines leur soient propres. Ce chapitre rappelle, les principes
généraux des applications web, suivis de la présentation d’une plateforme, Google App Engine. En plus, il
expose des notions de servlets et de JSP.
2.1 PRINCIPES GENERAUX
2.1.1. Architecture client-serveur
L’architecture client-serveur désigne un mode de communication entre deux entités - le(s)
client(s) et le(s) serveur(s) - souvent par l’intermédiaire d’un réseau. Le client est la machine dotée d’un
programme (« programme client »), pouvant effectuer une requête pour avoir des ressources venant du
serveur qu’est la machine programmée pour fournir la réponse.
Les applications web nécessitent l’utilisation du système client-serveur (Fig 2.1). Le serveur
Internet attend la demande des données (utilisation de TCP et IP) et renvoie le contenu des données
requises. De son côté, le navigateur est client du serveur auquel il a envoyé une requête HTTP. Le
navigateur présente à l’utilisateur une réponse une fois les données téléchargées. L’architecture client-
serveur sépare le serveur qui gère les données du client qui cherche à accéder à ces données.
Figure 2.1 : Architecture client-serveur
Les applications cloud adoptent cette architecture bien que les serveurs puissent varier dans un
nuage. Elles se comportent comme des sites web animés par des serveurs qui rendent les services
demandés aux applications clients, navigateurs ou interfaces personnalisés. La figure 2.2 illustre
l’architecture client-serveur pour une application cloud public.
13
Figure 2.2 : Architecture Client-Serveur en Cloud Computing
2.1.2. TCP/IP et Cloud Computing
Le modèle TCP/IP est le modèle de protocole utilisé pour le transfert des données sur Internet. Il
contient quatre couches : Hôte-réseau, Internet, Transport, Application [8]. Comme le Cloud Computing
fonctionne à partir d’Internet, il utilise ce modèle. Les offres cloud, SAAS ou PAAS, comme les applications
web, parcourent les protocoles TCP/IP avant d’atteindre les clients. Sa particularité est que l’application
réceptrice, en général un navigateur, simule une application lancée en local en affichant les opérations
réellement effectuées chez le serveur du prestataire. Pour les services IAAS, les machines ou plus
précisément la puissance des machines (puissance de calcul, espace de stockage) sont gérées comme des
serveurs à distance, donc via les protocoles de TCP/IP également. La figure 2.3 illustre le fonctionnement
du Cloud Computing avec la norme TCP/IP :
Figure 2. 3: TCP-IP et Cloud Computing
14
2.2. GOOGLE APP ENGINE
2.2.1 Présentation générale
a) Description
Google App Engine (GAE) est une plateforme de conception et d'hébergement d'applications web
basée sur les serveurs de Google. Il permet d'exécuter des applications web sur l'infrastructure Google. Il
est conçu pour héberger des applications utilisées par plusieurs utilisateurs simultanément. Les
applications sur GAE supportent plusieurs requêtes (jusqu’à des milliers, voire plus) simultanément sans
que celles-ci affectent la performance de l’application [9], c’est la notion de monter à l’échelle (scalability).
L’allocation de ressources s’effectue en fonction de la charge (élasticité) : plus la charge augmente plus
les ressources allouées pour l’application sont plus importantes ; et inversement. A la différence de la
facturation forfaitaire effectuée sur des services d’hébergement web classique, celle du GAE se base en
fonction des ressources consommées.
b) Architecture générale
L’application sur GAE interagit avec le client (navigateur) par l’intermédiaire des requêtes. La
plateforme App Engine est structurée principalement par trois éléments : les frontends, les serveurs de
fichiers statiques et les serveurs d’application (Fig 2.4). Les frontends gèrent les requêtes provenant du
client (navigateur). Les serveurs de fichiers statiques hébergent les fichiers statiques tels que HTML,
JavaScript, CSS et fichiers images. Les serveurs d’applications hébergent les fichiers ressources qui seront
exécutés à l’aide de l’environnement d’exécution [10]. Généralement, les applications interagissent avec
un système de base de données (Datastore) et des mémoires caches (pour l’optimisation de la
performance).
Serveurs d’application
Serveurs d’application
Frontends
Serveurs de fichiers
statiques
Serveurs d’application DATASTORE
Requête
Memcache
Figure 2. 4 : Architecture générale de Google App Engine
15
2.2.2 Environnement d’exécution
Les applications peuvent s’exécuter soit dans l’environnement Java soit dans l’environnement
Python. Chaque environnement propose des protocoles standards et des technologies courantes en
matière de développement d'applications web. Ces deux environnements utilisent le même modèle de
serveur d’application.
Le SDK (Software Development Kit ou Kit de développement logiciel) Python est implémenté en
langage Python pur et s'exécute sur toute plateforme dotée de Python 2.5, y compris Windows, Mac OS X
et Linux [10]. Le SDK Java s'exécute sur toute plateforme dotée de Java 5 ou de Java 6. Le développement
d’applications pour l’environnement d’exécution Java utilise les outils de développement web Java ainsi
que les normes API (Application Programming Interface). Les applications ainsi développées interagissent
avec l’environnement à l’aide de la technologie Java Servlet.
2.2.3 Datastore
a) Description
Datastore est un système de base de données NoSQL dans Google App Engine. Il possède trois
particularités. Premièrement, le Datastore n’est pas un système de gestion de base de données
relationnel (SGBDR). Deuxièmement, il ne possède pas de schéma. Enfin, il est hiérarchisé. Les données
manipulées par Datastore sont de type orientées objet.
b) Structure
Le magasin de données dans GAE constitue une solution évolutive et robuste pour le stockage des
données des applications web. Il est conçu pour privilégier les performances des opérations de lecture et
de requête. Cette performance est satisfaite du fait de sa structure. En effet, Datastore est basé sur
Bigtable. Celui-ci est un système de stockage scalable, distribué, hautement disponible et structuré. Il est
conçu pour gérer des données très volumineuses réparties sur des milliers de serveurs. Il est utilisé par
Google depuis 2005 notamment pour son moteur de recherche, pour YouTube, Google Earth, Analytics et
plusieurs autres projets [11]. Lors d’une opération sur les données, Datastore supporte les requêtes
tandis que Megastore supporte les transactions.
Figure 2. 5 : Structure du Datastore
16
c) Modèle de stockage
- Entité
Une application App Engine stocke ses données dans Datastore comme une ou plusieurs entités.
Autrement dit, une entité est un objet de données dans le magasin de données. Une entité possède un
kind, une key, et une ou plusieurs propriétés [12]. Kind est le type de donnée de l’entité. Key est la clé de
chaque entité. Cette clé est l’identifiant unique de chaque entité. Chaque propriété d’une entité
représente des valeurs associées aux types de données pris en charge : entiers, valeurs à virgule flottante,
chaînes, dates, données binaires, etc. Enfin, chaque entité appartient à un groupe d’entités constitué d’un
ensemble formé d'une ou de plusieurs entités susceptibles d'être manipulées au sein d'une seule
transaction.
- Relations entre entités
Les entités dans Datastore peuvent avoir des relations entre elles. La relation entre deux entités
peut être soit de type appartenance, communément appelé parenté, soit de type indépendant. Il s’agit
d’une relation d’appartenance lorsqu’une entité ne peut exister sans l’autre. Il s’agit d’une relation
indépendante lorsque deux entités peuvent exister indépendamment de la relation qui les lie l’une à
l’autre. Aussi, la relation entre deux entités possède une notion de multiplicité (un-à-un, un-à-plusieurs)
et une notion de navigabilité (unidirectionnelle, bidirectionnelle).
Remarque :
D’une part, deux entités de même kind peuvent avoir des propriétés différentes. Et une même
propriété de deux entités (de même kind) peut contenir des types de données différents. D’où la notion
de base de données sans schéma [13]. Autrement dit, Datastore ne possède aucune notion de structure
des données enregistrées.
D’autre part, toute entité stockée dans Datastore peut avoir un parent (et respectivement de
grand parent). D’où la notion de base de données hiérarchisée. Une entité et son parent (s’il existe)
appartiennent au même groupe d’entités. Le regroupement d’entités au sein d’un même groupe indique
à GAE de stocker ces entités dans la même partie du réseau distribué (dans le même emplacement
physique). Ainsi, les opérations effectuées sur des entités du même groupe sont théoriquement plus
performantes.
Du fait du modèle de stockage de Datastore, les données dans le magasin de données peuvent
être assimilées à une base de données orientée objet dans laquelle une entité est représentée dans le
code par un objet et le kind par une classe [14].
d) Opérations sur les données
La manipulation des données dans Datastore s’effectue à l’aide de requêtes et de transactions. La
base de données manipulée est de type NoSQL [15]. Le langage de requête dans Datastore est proche du
SQL mais se limite au simple filtre et tri. Donc, il ne supporte pas les jointures. Chaque tentative de
création, de mise à jour ou de suppression d'une entité intervient dans le cadre d'une transaction. Une
transaction garantit que chaque modification apportée à l'entité est enregistrée dans le magasin de
données, ou, en cas d'échec, qu'aucune des modifications n'est appliquée. Cela assure la cohérence des
données au sein d'une entité.
17
e) Différence entre Datastore et SGBDR
Le Datastore n’est pas un SGBDR. Néanmoins il existe une certaine équivalence entre ces deux
ensembles. Un kind dans Datastore est équivalent à une table dans un SGBDR. Une entité dans Datastore
correspond à une rangée dans un SGBDR. Une propriété d’un kind est équivalente à un champ. Une key
correspond à Primary Key.
La différence entre Datastore et un SGBDR réside dans leurs performances et leurs capacités à
monter à l’échelle. Datastore est conçu à monter à l’échelle en fonction de la charge. Autrement dit, sa
capacité augmente au fur et à mesure que la charge monte. Il satisfait donc une performance constante
quel que soit le nombre de charges reçues. Par contre, un SGBDR est difficile à monter à l’échelle.
Ces comparaisons sont résumées dans le tableau II ci-dessous.
Tableau II : Comparaison du Datastore avec un SGBDR
Datastore SGBDR
Catégorie d’objet Kind Table
Une entrée/ Un objet Entité Rangée
Identifiant unique Key Primary Key
Donnée individuelle Propriété Champ
Flexibilité du langage de
requête
Proche du SQL mais limité au
simple filtre et triage.
Supporte totalement SQL :
Jointure, Filtre, Sous-requêtes
Fiabilité et Scalability Hautement scalable et fiable
avec performance.
Difficile à monter à l’échelle.
f) Implémentation de données avec Java
Lors de l’implémentation des données avec Java, Datastore interagit avec l’application soit à l’aide
des interfaces JDO (Java Data Objects) ou JPA (Java Persistence API), soit à l’aide de l’API bas niveau de
Datastore [A1]. La figure 2.6 montre l’interaction entre une application et Datastore lors de
l’implémentation de données avec Java.
18
Figure 2. 6 : Interaction entre une application et Datastore (implémentation en Java)
2.3. SERVLETS ET JSP
Une servlet est une classe Java qui permet de créer dynamiquement des données au sein
d'un serveur HTTP. Pour fonctionner, les servlets ont besoin de l’aide du conteneur. En fait, c’est le
conteneur qui gère la vie des servlets et s’assure de faire comprendre ce que le client veut qu’ils traitent.
Les JSP (Java Server Page) ressemble aux servlets parce que lorsque compilés les JSP deviennent des
servlets [A1].
2.3.1 Conteneur Web
Le conteneur web est une application placée du côté serveur. Il contrôle les servlets. Les tâches
des conteneurs sont semblables, mais celles de Google App Engine ont leurs spécificités. En effet, Google,
dans son PAAS, a ajouté autour de ses conteneurs plus de fonctionnalités pour assurer la sécurité et
optimiser le système. Les applications hébergées sur cette plateforme profitent ainsi des avantages du
conteneur.
Le conteneur fait communiquer les servlets au serveur. Il s’assure de la fonction d’écoute sur les
ports. Quand les requêtes venant du client arrivent, il charge les classes nécessaires et instancie les
servlets au moment voulu. A partir des demandes effectuées par le client, le conteneur crée les objets
requête et réponse. Ensuite, il crée un processus (ou thread) pour la servlet afin de lancer la méthode
service() de celle-ci [16]. A la fin du traitement, il s’occupe encore de mettre les servlets dans les ramasse-
miettes.
Le conteneur se charge également de convertir les codes JSP en Java avant d’être utilisés. La figure
2.7 montre le cycle de vie d’une servlet, gérée par le conteneur.
19
Figure 2. 7 : Contrôleur et cycle de vie d'une servlet [17]
Lorsque le conteneur voit qu’il a besoin d’une servlet, il charge la classe correspondante suivant
le descripteur. A la phase de l’instanciation, le constructeur sans argument de la classe de la servlet est
lancé. Ce constructeur est généré de manière transparente par le compilateur.
La méthode init() est appelée au chargement de la servlet. Cette méthode contient le code
nécessaire aux initialisations tel que: obtention d’une source de données, création de structures…
Par la suite, la méthode service() est exécutée. Durant l’exécution de cette méthode, la servlet passe la
majorité de son existence à traiter les requêtes en effectuant les principales demandes qu’elle devrait
fournir dans cette étape. Les algorithmes écrits par le programmeur lors des redéfinitions des méthodes
doPost() ou doGet() forment le noyau de cette méthode.
A la fin, le conteneur laisse la servlet libérer la mémoire qu’elle a utilisée : destruction d’objet (le
conteneur appelle destroy() ), fermeture des entités du magasin de données, etc.
Remarque:
Un descripteur de déploiement (ou « deployment descriptor ») est un fichier au format XML. Il est
utile au conteneur pour gérer les fichiers de l’application dans le serveur. Ce descripteur sert d’indication
pour le(s) serveur(s), afin d’assurer le fonctionnement des servlets et de gérer les contraintes de sécurité.
Un projet App Engine est au moins composé de deux descripteurs : web.xml et appengineweb.xml [A1].
20
2.3.2 Servlet
La classe des servlets permet de créer des données au sein d'un serveur HTTP. Ces données sont
généralement présentées au format HTML, mais elles peuvent également l'être au format XML ou tout
autre format destiné aux navigateurs web. En général, ce sont les servlets HTTP qui s’utilisent dans le
monde du web.
Toutes les servlets implémentent l’interface servlet du package javax.servlet. Les méthodes
service(), init() et destroy() régissent le cycle de vie de la servlet. GenericServlet est la classe mère de toutes
servlets. Celle-ci est une classe abstraite qui rassemble les méthodes pour le comportement des servlets.
Le développement d’une classe servlet est une tâche pratique même si elle ne ressemble pas aux
autres classes Java. Il suffit de suivre un modèle de codage [A1], redéfinir les méthodes do<methodeHttp>
et mettre les briques de raisonnements dans la (ou les) méthode(s) qu’on redéfinit. Les difficultés
principales résident dans les algorithmes pour traiter les problèmes à résoudre. La figure 2.8 présente le
diagramme UML simplifié des classes et interfaces parents dont héritent les servlets.
<<Interface>>
Servlet
GenericServlet
HttpServlet
ClasseServlet
...
...
...
...myMethod()doPost(HttpServletRequest,HttpServletResponse)
Figure 2. 8 : Classes et Interface parents des servlets
21
2.3.3. Java Server Page
Les Java Server Page ou JSP constituent un outil assez particulier. Elles combinent du code HTML
et du code Java. Les pages JSP sont principalement constituées de balises HTML pour l’affichage, et de
code Java pour les traitements [A1]. L’avantage des JSP est la facilité de création de pages générées
dynamiquement sur un serveur HTTP. Définitivement elles sont similaires à des servlets quoiqu’elles
utilisent une démarche opposée. En effet, une JSP contient du code Java dans une page HTML alors qu’une
servlet contient du code HTML dans son code Java.
Pour toute requête à un fichier JSP, le serveur HTTP fait appel au serveur de servlet. Le conteneur
de celui-ci crée une classe équivalente de servlet à partir des balises JSP et du reste du fichier. Puis, il
compile et crée une instance de cette classe avant que la méthode _jspService() soit exécutée. Cette
méthode a comme argument les objets de requête et de réponse. Les instructions Java d’un fichier JSP
sont incluses dans des balises spéciales.
22
Ce chapitre a fait révéler les différentes technologies du web et du Cloud Computing. Il a rappelé
dans un premier temps que le Cloud Computing adopte en plus de ses particularités les technologies
existant. Il s’agit des technologies des réseaux informatiques. Après, une plateforme particulière, Google
App Engine a été décrit. Son fonctionnement, son architecture et la possibilité qu’elle puisse offrir en
termes de performance pour les SAAS a surtout fait l’objet du paragraphe. Les outils pour la partie
traitement d’une application développé dans un environnement Java a terminé ce chapitre. Le dernier
paragraphe a montré que ce sont les conteneurs web qui sont responsables des fonctionnements des
applications Java sur le web. Ce conteneur gère les servlets qui contiennent les algorithmes pour une
opération donnée.
Après ces théories concernant les applications Cloud. Voyons dans le chapitre suivant le
développement d’un SAAS déployé sur la plateforme Google App Engine, utilisant l’environnement Java.
23
Chapitre 3 DEVELOPPEMENT DU LOGICIEL « AN-TANANA v1.0»
Le logiciel An-tànana va être réalisé sur la plateforme Google App Engine. Ce PAAS permet de
développer soit avec le langage Python soit avec Java. An-tanana v1.0 est développé sous
l’environnement Java, ainsi le langage utilisé est le Java J2EE. La partie traitement métier qui sera surtout
développée ici s’appuie sur les outils web de Java J2EE tels les JSP et les Servlets.
Ce chapitre présente la conception de l’application. Il fait apparaitre la définition des besoins
l’application An-tànana, ses fonctionnalités et la modélisation par UML.
3.1 CAHIER DES CHARGES
3.1.1 Présentation du logiciel
Le logiciel An-tànana est une application cloud public conçu pour la gestion d’établissement
hôtelier. C’est donc un Software As A Service. Pratiquement, il participe à l’organisation de
l’établissement, notamment la gestion des réservations, gestion de la clientèle ainsi que de la facturation.
Où qu’il soit, le propriétaire (ou le gérant, selon le cas) peut suivre en temps réel les activités au sein de
son établissement.
3.1.2 Fonctionnalités
L’application permet d’enregistrer, de consulter, de mettre à jour ou supprimer des réservations.
Elle permet aussi d’enregistrer et de consulter la liste des clients. Enfin, elle permet d’émettre une facture
à un client.
3.1.3 Besoins matériels
L’application n’est dépendante ni du matériel utilisé ni du système d’exploitation (Windows,
Linux, MacOs, Android, iOS, etc…). Il suffit d’un terminal (ordinateur de bureau, ordinateur portable,
Smartphone, tablette, etc…) ayant un navigateur web et ayant accès à Internet pour l’utiliser. De plus, elle
ne requiert aucune configuration minimale.
3.1.4 Besoins fonctionnels
- L’interface de l’application n’est accédée que par un navigateur web en tapant l’URL
correspondant du logiciel.
- L’application ne nécessite aucune installation au préalable ou autres prérequis. L’utilisateur n’a
besoin que d’une connexion à Internet pour l’utiliser.
- Seuls les utilisateurs autorisés, soit utilisateur simple (réceptionniste) soit administrateur
(propriétaire ou gérant), ont accès à l’application.
- Le système d’authentification se fait via l’entrée de login et de mot de passe (Compte Gmail).
- Seul l’administrateur a accès à la configuration de l’application.
24
- Les données sont stockées physiquement dans les infrastructures de Google via la plateforme
Google App Engine.
- Les données ainsi stockées sont garanties de fiabilité, d’intégrité et de disponibilité.
- Le coût taxé de l’utilisation de l’application se base sur le nombre d’utilisateurs, le volume des
données stockées et la quantité de ressources consommées par le logiciel.
3.1.5 Besoins non fonctionnels
La principale contrainte quant à l’utilisation de l’application est d’une part, sa dépendance à
Internet et, d’autre part, le débit et la bande passante offerte par ce dernier. Autrement dit, la vitesse
d’exécution de l’application ne dépend que de la vitesse de la connexion utilisée. Mais aussi, l’utilisation
de données sensibles et importantes est déconseillée.
3.1.6 Règles de gestion
La conception du logiciel est basée sur quelques hypothèses. Celles-ci sont conçues non
seulement pour se référer au mieux la situation réelle, mais aussi et surtout dans le but de modéliser un
schéma cohérent des données. Ces hypothèses ne reflètent donc pas forcément la situation exacte dans
un établissement hôtelier mais elles permettent essentiellement de réaliser un modèle de logiciel cloud
traitant des données cohérentes. Ces suppositions sont récapitulées par les règles de gestion suivante :
1. Un hôtel possède au moins une chambre.
2. Une chambre n’appartient qu’à un seul hôtel.
3. Une chambre possède un tarif.
4. Un tarif (défini selon les options) peut appartenir à plusieurs chambres.
5. Une réservation est affiliée à une seule chambre.
6. Une réservation est affectée à un seul client.
7. Une chambre peut enregistrer plusieurs réservations (dates différentes).
8. Un client possède un seul contact. Un contact ne peut exister sans client.
9. Un contact correspond à une adresse. Un contact possède une adresse.
10. Un client peut faire une ou plusieurs réservations.
3.1.7 Maintenance du logiciel
La maintenance de l’application se base sur l’amélioration de l’ergonomie, l’ajout de fonctions,
l’optimisation de la performance et l’optimisation de la sécurité. D’ailleurs, la mise à jour du logiciel ne
nécessite aucune intervention de la part de l'utilisateur, elle est effectuée par le développeur et s'applique
immédiatement.
25
3.2 MODELE DU SYSTEME
Les besoins ci-dessus amènent à définir un modèle conceptuel du système. En effet, l’application
comporte deux ensembles de fonctions : la configuration de l’application et le système de réservation
proprement dit. La configuration est effectuée par l’administrateur du logiciel tandis que l’utilisateur
simple n’a accès qu’au système de réservation.
3.2.1 Configuration de l’application
La configuration de l’application se base sur la définition des paramètres de base de l’hôtel. Chaque
établissement possède ses propres paramètres et options qui sont définis pendant l’initialisation du
système, c’est-à-dire, à la première utilisation de l’application.
Lors de la première utilisation de l’application, l’administrateur est convié à entrer les paramètres
de base de l’établissement. Ainsi, il lui sera demandé d’entrer le nom et les coordonnées de l’hôtel.
Ensuite, il lui sera demandé d’entrer le nombre de chambres au sein de l’établissement et de définir les
tarifs. A chacune de ces étapes, les variables ainsi paramétrées seront enregistrées dans le magasin de
données. L’administrateur peut consulter tous ces paramètres. Ces différentes fonctions sont résumées
dans la figure 3.1.
Administrateur
Magasin de données
Initialiser nom et coordonnées de l’établissement
Définir les tarifsDéfinir nombre de
chambresAfficher les paramètres
Figure 3. 1 : Modèle de la configuration de l’application
26
3.2.2 Système de réservation
La principale fonction de l’application se focalise sur le système de réservation. Elle s’appuie
notamment sur la gestion de la clientèle et la gestion de la réservation proprement dite. Le concept est
schématisé par la figure 3.2.
Créer réservationAfficher clients /
réservations
Supprimer réservation
Chercher clientInscrire nouveau
client
Utilisateur
Magasin de données
Valider réservation
Mise-à-jour réservation
Générer facture
Figure 3. 2 : Modèle du système de réservation de l’application An-tànana
Lors d’une création d’une réservation, généralement il s’agit d’un nouveau client. Dans ce cas, il
inscrit le client (nom, prénom, contact, etc) et insère par la suite les paramètres de réservation (date de
début et fin de la réservation, numéro de la chambre). Par contre, dans le cas exceptionnel où le client est
déjà enregistré dans le magasin de données de l’application, l’utilisateur peut alors effectuer une
recherche. Le logiciel exécute alors un algorithme de recherche afin d’obtenir le client correspondant. Ce
n’est qu’après ces étapes qu’il active la validation de la réservation. Une fois la réservation validée, les
données de réservation (dates de début/fin, numéro de la chambre ainsi que nom et coordonnées du
client) seront alors enregistrées dans le magasin de données.
Après l’opération de création de réservation, l’utilisateur peut consulter la liste de celle-ci et/ou la
liste des clients inscrits ou supprimer une réservation. L’utilisateur peut également mettre à jour une
réservation. De la même façon, il peut générer une facture pour une réservation donnée.
27
3.3 MODELISATION PAR UML ET CODAGE
Pour modéliser un système informatique, l’OMG ou Object Management Group a adopté et
standardisé le langage de modélisation unifié ou UML (Unified Modeling Language) qui « permet à tout
collaborateur dans la conception d’un logiciel de visualiser et de comprendre le système en question »
[19]. Ceci nous a permis notamment de répartir les tâches que nous avons effectuées dans ce projet, à
savoir le développement de la partie traitement du logiciel, l’élaboration de la base de données et la
création de l’interface. Le présent ouvrage concerne surtout ce premier. La modélisation d’An-tànana
comporte quatre diagrammes UML présentés dans ce sous-chapitre.
3.3.1 Architecture de l’application
Le paquetage est une notion fondamentale introduite par UML pour la gestion des systèmes
nécessitant la mise en place d’une organisation hiérarchique. Il sert d’élément d’organisation pour un
projet de conception. Pour An-tànana, un diagramme de paquetage est conçu afin de représenter
l’architecture en couche du logiciel.
a) Diagramme de paquetage
Le logiciel An-tànana suit une architecture en trois couches : Modèle, Vue et Contrôleur. La couche
modèle concerne la manipulation et la conservation des données. La vue concerne le rendu de
l’application et son interaction avec l’utilisateur. La couche contrôleur regroupe l’ensemble des règles
métiers de l’application. Cette architecture organise la conception, mais impacte également la
performance du logiciel. Comme le présent travail s’oriente surtout sur le développement de la couche
Contrôleur, la couche Modèle et la couche Vue a été effectué en étroite collaboration lors de la mise en
place du logiciel tout entier[16].
Le magasin de données de Google en combinaison avec les APIs JDO (Java Data Objects) constitue
la couche modèle de l’application. La couche contrôleur est composée de servlets http. Ce sont les outils
nécessaires pour le développement d’application App Engine avec Java. Selon le cahier des charges,
l’application est accessible via des navigateurs. Ainsi la couche vue est réalisée à l’aide du langage HTML
pour les fichiers statiques et JSP pour les fichiers dynamique. L’utilisation de JavaScript assiste la
conception de cette dernière couche. La figure 3.3 montre un diagramme de paquetage UML représentant
ces trois couches. Chaque sous-système contient les technologies Java 2EE utilisées dans l’application.
28
HTMLJSP
JavaScript
ServletJavaXML
JDOGoogle API Datastore
Figure 3.3 : Architecture en trois couches [20]
Remarque :
Comme introduit dans le chapitre précédent, en plus des techniques utilisées par les applications
sur Internet, An-tànana est conçu avec les technologies suivantes: Google App Engine, le langage de
programmation orienté objet Java, les technologies pour la présentation telles que JSP, HTML, JavaScript.
Google App Engine, la PAAS de Google, est la plateforme de développement et d’exécution même
de cette application Cloud. Il s’agit d’une plateforme à la fois gratuite et offrant un outil simple
d’utilisation. Effectivement, la majorité de la phase de codage et de test a été effectuée avec l’IDE Eclipse
muni d’un plug-in Google App Engine.
Le langage Java est le langage utilisé pour la programmation d’An-tànana, plus précisément la
version J2EE (Java 2 Enterprise Edition). Les bibliothèques qui s’utilisent avec les applications web
(servlets/EJB/JSP) sont également utilisées. C’est une version de la plateforme Java spécialement étudiée
pour les problèmes des applications d’entreprise. Elle fournit de nombreuses solutions au niveau de la
gestion des problèmes récurrents dans ce domaine : sécurité (API JAAS), prise en charge des transactions
(API JDO).
b) Diagramme de déploiement
Le diagramme de paquetage donne une vue très globale des parties de l’application et permet de
décrire l’architecture en couche. Pour illustrer son architecture technique, un diagramme de déploiement
est nécessaire. Un diagramme de déploiement est un diagramme représentant les nœuds ou les instances
de nœuds sur lesquels le système s’exécute. Il offre une vue statique servant à représenter la disposition
physique des matériels qui composent le système et la répartition des composants sur ces matériels. La
modélisation d’un tel diagramme a été essentielle afin de comprendre l’architecture technique de
l’application An-tànana. La figure 3.4 illustre le diagramme de déploiement du logiciel An-tànana.
Les principaux nœuds d’An-tànana sont l’appareil du client et le (ou les) datacenter(s) sur
le(s)quel(s) est lancée l’application. Ils sont ainsi constitués par le cloud, le serveur d’application et le
serveur de données. A l’intérieur de ceux-ci sont placés les composants logiciels assurant les
fonctionnalités de l’application. Un exécutable pouvant envoyer/recevoir des requêtes/réponses http,
donc généralement un navigateur, est le composant placé coté client. Les servlets sont les composants
29
responsables du traitement et des manipulations de données. Les composants déployés par les serveurs
de données sont les entités.
Datacenter (nuage)
Appareil Client
<<executable>>Navigateur
Serveur d’application Google
<<environment d’execution>>Conteneur de servlets
<<composant>>Servlet
<<composant>>JSP
HTTP
Serveur de données Google
<<database>>Datastore
<<composant>>Entité
JDOAPI Datastore
Figure 3. 4 : Diagramme de déploiement d’An-tànana v1.0
3.3.2 Diagramme de cas d’utilisation
a) Identification des acteurs
Les acteurs du système sont : le ou les utilisateurs, l’administrateur, le système d’autorisation.
Utilisateur : comme utilisateur simple, il s’occupe de mettre à jour les réservations ainsi que la liste des
clients. Il peut aussi consulter et supprimer les réservations existantes et émettre une facture.
Administrateur : il est utilisateur, mais en outre, il peut voir et gérer les clients et les réservations ainsi
que modifier le prix des services et les configurations de l’hôtel tels les nouveaux services, le nombre de
chambres.
Le système d’autorisation : Les modifications importantes comme le changement de prix, de services ...
sont autorisées par un système d’autorisation vérifiant les utilisateurs qui ont le droit d’administrer ou
d’utiliser le logiciel.
30
b) Identification des cas d’utilisation
Ces acteurs ont les cas d’utilisation suivants :
Pour Utilisateur: Ajout de client et/ou modifications des informations le concernant, ajouter réservation,
visualiser et supprimer réservation, émettre facture.
Pour Administrateur: modifier prix, configurer hôtel.
Pour Système d’autorisation : néant.
Figure 3. 5 : Diagramme de cas d'utilisation d’An-tànana
c) Résumé des cas d’utilisation Le tableau III résume chaque cas d’utilisation (pour plus de détails, voir annexe A2).
31
Tableau III: Description des cas d'utilisation d’An-tànana
Cas d’utilisation Résumé
Gérer client L’utilisateur crée ou recherche un client de l’hôtel. Il peut également
modifier les informations le concernant ce client.
Gérer réservation L’utilisateur ajoute, modifie ou supprime une réservation
appartenant à un client de l’hôtel.
Générer facture L’utilisateur peut obtenir une facture à partir des réservations ou
des services consommés par un client.
Configurer Hôtel L’administrateur configure les paramètres concernant l’hôtel.
Modifier Prix L’administrateur initialise ou modifie les tarifs.
3.3.3 Codage
Le codage du logiciel avec Java nécessitait à part le J2EE des connaissances sur les bases du
langage. En effet les algorithmes dans les servlets sont du Java standards. Voici un aperçu des servlets
codé pour le développement de An-tanana v1.0. Il y a ceux responsables des écritures de données
(Généralement SaveXXX où XXX designe les entités de données dans le datastore de Google [16]), et ceux
responsable de l’affichage c’est-à-dire de l’écriture (Généralement AfficheXXX). La servlet PMF est une
servlet particulière gérant la manipulation des données persistante. Elle renferme les codes API JDO pour
l’accès à des données dans le datastore. Les fichiers sources JSP sont utiles pour alléger le traitement,
même s’ils servent surtout aux affichages de résultats dynamiques (Fig 3.6). La figure 3.7 présente les
fichiers sources du package traitement avec les JSP qui y sont liées.
Figure 3. 6 : Processus de traitement dans An-tanana v1.0
Base de DonnéesJSP Servlet
Affichage/Saisie
Opération préalable des requêtes pour le
traitement ou des résultats pour
l’affichage
Opération de calcul(facture) ou de modification
de la base de données
32
Figure 3. 7 : Servlets et JSPs d’An-tanana v1.0
Remarque : Les données du logiciel An-tanana v1.0
L’implémentation de la base de données du logiciel a été effectuée à l’aide des API JDO et l’API
bas niveau Datastore. Cette manipulation des données est liée au traitement. La figure 3.8 Affiche le
diagramme de classe des données du logiciel An-tànana v1.0.
Puisque la base de données est de type orientée objet, la modélisation de celle-ci se conforme à
la conception d’un diagramme de classe. Afin d’optimiser la cohérence et la lecture des données, la
définition des entités ainsi que ses propriétés respectives ont été établies à partir des règles de gestion.
Un établissement (hôtel) est défini par son nom et ses coordonnées (adresse et e-mail) (type String).
Une chambre possède son numéro (type int). Un tarif est défini selon les options de l’établissement (type
HashMap<String, long>). Les réservations (entité Resa) se distinguent les unes par rapport aux autres
à l’aide de la combinaison des deux paramètres : la date de début (type Date) ainsi que le numéro de la
chambre correspondant (type int). Un client possède un nom et un prénom. Un contact signifie un
numéro de téléphone et une adresse e-mail. Enfin, l’adresse correspond à l’adresse physique (logement,
rue, ville et pays) du client (toutes de type String).
33
En conclusion, la principale fonctionnalité de l’application est la gestion des réservations d’un
établissement hôtelier. Un administrateur a droit aux configurations importantes de celui-ci. La partie
traitement concerne les opérations demandées par les requêtes et la manipulation de la base de données.
Il s’agit notamment de la gestion des clients et des réservations. Les différents servlets formant le noyau
du système sont responsables de ses gestions. De même, la génération de facture et des modifications
utiles pour le bon fonctionnement de l’application telles les sessions sont également assurés par le
conteneur de servlets. Le logiciel développé en langage Java et hébergé sur le PAAS de Google profite de
la performance de ces technologies utilisées.
1..1
1..1
1..1
1..*
0..*1..11..11..*
1..1
1..1
1..1
1..1
0..*
1..1
Hotel
-
-
-
nomHotel
adresseHotel
emailHotel
: String
: String
: String
Chambre
- numero : int
Resa
-
-
-
dateDeb
dateFin
numChambre
: Date
: Date
: int
Contact
-
-
tel
: String
: String
Client
-
-
nom
prenom
: String
: String
Adresse
-
-
-
-
logt
rue
ville
pays
: String
: String
: String
: String
Users
-
-
admin
user
: String
: String
Tarif
- TarifService : HashMap<String,long>
Figure 3. 8 : Diagramme de classe des données
34
CHAPITRE 4 MODE D’ACCES A AN-TANANA v1.O
Ce dernier chapitre présentera essentiellement la manipulation du logiciel. Il sera décrit en
premier lieu le mode d’authentification, la manipulation par l’administrateur ainsi que la manipulation
par un utilisateur. L’interface est implémentée principalement en HTML et JSP. L’interaction entre le
logiciel et son utilisateur est facilitée par des codes JavaScript. Enfin, l’aspect visuel de l’interface est affiné
à l’aide des feuilles de styles CSS.
4.1 COMPTE AN-TANANA
4.1.1 Connexion d’un utilisateur
Pour gérer un hôtel avec An-tànana v1.0, un client doit créer un compte propre à son hôtel. Pour
pouvoir créer un compte, le client doit posséder un compte Google à l’exemple de Gmail. Avant toute
manipulation, même pour utiliser un compte An-tànana déjà existant, l’utilisateur - administrateur ou
utilisateur simple - s’authentifie en utilisant le service des utilisateurs de Google. La figure 4.1 montre la
connexion avec le système de gestion d’utilisateur de Google.
Figure 4. 1 : Connexion avec le système de gestion d’utilisateur de Google
35
4.1.2 Création de compte An-tànana
Après s’être authentifié et connecté, le client peut créer un compte An-tànana. An-tànana v1.0
gère le compte d’un hôtel avec un identifiant. Cet identifiant est défini lors de la création d’un compte. Le
SAAS configure ce créateur comme administrateur, à la fois premier utilisateur par défaut du compte.
Toutefois il invite l’administrateur à ajouter un utilisateur simple lors de cette création. La figure 4.2
montre les détails de la création de compte.
Figure 4. 2 : Création de compte An-tànana
Remarque :
L’identifiant de l’hôtel peut être différent de son nom commercial. L’administrateur précisera le
nom commercial (paragraphe suivant).
Après avoir créé un compte, un utilisateur agréé peut désormais manipuler et gérer l’hôtel. Un
nouveau compte nécessite des configurations initiales utiles que seul l’administrateur peut régler. La
figure 4.3 montre un utilisateur non agréé qui tente d’entrer dans un compte An-tànana. Le paragraphe
suivant montre les différentes manipulations d’un administrateur.
Une fois connecté, l’utilisateur est redirigé vers la page d’accueil d’An-tànana. L’identifiant de son
hôtel est précisé sur la page d’accueil, la figure 4.4 montre la page d’accueil sur différent terminaux.
36
Figure 4. 3 : Connexion à An-tànana – Utilisateur non agrée
Figure 4. 4 : An-tànana – Page d’accueil
4.2 MANIPULATION PAR L’ADMINISTRATEUR
L’administrateur d’An-tànana est responsable de la configuration du logiciel pour la gestion des
paramètres de l’hôtel. Les principales tâches de l’administrateur sont décrites ci-après.
4.2.1 Configurations initiales du logiciel
Lors de la première utilisation, l’initialisation des informations concernant l’hôtel est nécessaire.
Pour configurer, il faut entrer dans l’onglet configurations. La figure 4.5 montre la page de configuration
d’An-tànana.
37
Figure 4. 5 : An-tànana- Page de configuration
Lors de la configuration initiale, le logiciel réserve l’espace utile au compte dans le Datastore de
Google. Il hiérarchise ces données dans le Datastore en créant la clé parent correspondant au compte de
l’hôtel. Les informations nécessaires à la première utilisation du logiciel sont : le nom, l’adresse, le contact,
le nombre de chambres dont l’hôtel dispose. Une capture de la configuration de « EN_Hotel » est montrée
sur la figure 4.6.
Figure 4. 6 : Configurations Initiales dans An-tànanav1.0
38
4.2.2 Spécification tarifs et utilisateurs
Après les précédentes configurations, les initialisations telles que la tarification et les utilisateurs
du compte sont également nécessaires au logiciel afin de mener à bien la gestion de l’hôtel. Les
utilisateurs s’agissent ici des personnes, autres que l’administrateur, autorisées à accéder au compte. La
figure 4.7 montre la configuration des tarifs d’un hôtel « EN_Hotel » et la figure 4.8 l’ajout d’un utilisateur.
Figure 4. 7 : An-tànana – Initialisations des tarifs
Figure 4. 8 : An-tànana – Ajout d’un utilisateur
Les tarifs fixés par le gérant de l’hôtel devraient être définis par l’administrateur. Ceci concerne le
prix correspondant au type de lit, aux prix des services disponibles dans l’hôtel. Après il doit également
préciser le tarif de chaque chambre. Généralement ceci dépend du type de lit à l’intérieur, cette première
39
version d’An-tànana va associer le type de lit au tarif d’une chambre. La figure 4.9 affiche une
configuration en cours des tarifs des chambres.
Figure 4. 9 : Configuration des tarifs des chambres
4.2.3 Affichage des informations concernant l’hôtel
L’administrateur peut vérifier les configurations ou les informations concernant l’hôtel en cliquant
sur le bouton Affiche Hôtel. Cette opération prend plus de temps que les autres requêtes car elle regroupe
l’ensemble des informations concernant l’établissement. La figure 4.10 montre une capture du résultat
d’un hôtel.
Remarque:
Si l’administrateur diffère du propriétaire ou gérant de l’hôtel, il est préférable que ledit
administrateur soit une personne de confiance car les modifications qu’il peut effectuer sont cruciales.
40
Figure 4. 10 : Affichage des informations concernant un hôtel abonné à An-tànana
4.3 MANIPULATION PAR UN UTILISATEUR
La manipulation par un utilisateur simple se résume à la gestion de la réservation et de la clientèle.
Comme mentionné dans le cahier des charges, le logiciel permet d’enregistrer un client, d’afficher la liste
des clients enregistrés, de chercher un client et d’émettre une facture. Il peut non seulement insérer une
nouvelle réservation et afficher les réservations mais aussi les mettre à jour ou les supprimer. Ces
fonctionnalités sont illustrées dans le logiciel par les interfaces graphiques représentées respectivement
dans les figures 4.11 et 4.12 suivantes.
Figure 4. 11 : Page ‘client’
41
Figure 4. 12 : Page ‘réservation’
4.3.1 Création d’une nouvelle réservation
La création d’une nouvelle réservation se déroule généralement en deux étapes : la page de
renseignement du client et la création de la réservation proprement dite (date de début et date de fin).
Cliquer sur le bouton « nouvelle réservation » permet d’obtenir un formulaire ‘Fiche client‘ permettant
d’entrer les renseignements concernant le client. Un formulaire s’affiche alors permettant d’insérer le
nom, prénom et coordonnées du client (Fig 4.13). Les données fournies sont vérifiées du côté navigateur
à l’aide d’un code JavaScript. Cette vérification permet d’avoir une cohérence et une fiabilité des données.
Elle vérifie les champs vides et assure que les formats du texte tapé suivent la norme.
Les champs obligatoires sont ceux du nom, prénom, e-mail et téléphone. Le texte dans le champ
e-mail doit suivre le format classique d’un e-mail ([email protected]), tandis que la valeur du champ
téléphone doit être de type numérique et doit être composé au minimum trois chiffres. Une fois ces
conditions satisfaites et le formulaire validé, ces données seront enregistrées dans le magasin de données
et la page se redirigera vers la page création d’une réservation.
La page précédente aboutit à la page de création d’une réservation proprement dite (Fig 4.14).
Ainsi dans cette page seront saisis les paramètres correspondants : date de début de la réservation, date
de la fin de la réservation et le numéro de la chambre. Les formats de ces dates sont assurés par jQuery
(bibliothèques JavaScript). Ce formatage permet la facilitation d’entrée de la date et surtout garantit que
la date ainsi définie correspond aux formats acceptés par Java lors du traitement et lors de la sauvegarde
des données. Une fois validés, ces paramètres seront stockés dans le magasin de données.
42
Figure 4. 13 : Formulaire de renseignement client
Figure 4. 14 : Formulaire de création d’une réservation
Cas particulier : Recherche d’un client
Toutefois, un cas particulier est considéré : s’il s’agit d’un client qui s’est déjà inscrit
antérieurement (déjà dans le magasin de données). L’utilisateur peut choisir l’option « Chercher client »
afin d’éviter la page de renseignement. Dans ce cas, la page se redirige vers une autre page pour la
43
recherche du client correspondant (Fig 4.15). L’application exécute ainsi un algorithme de recherche. Si la
recherche aboutit, elle renvoie le client correspondant, sinon la page retourne vers le formulaire
« nouveau client ». Les champs du formulaire comportent le nom et prénom du client à chercher.
Figure 4. 15 : Formulaire pour la recherche d’un client
4.3.2 Affichage
a) Affichage de la liste des clients
Le logiciel permet la consultation des clients déjà enregistrés. Cette page permet de visualiser les
noms, prénoms et coordonnées des clients ainsi que leurs réservations respectives (date début, date fin
et numéro de la chambre). La figure 4.16 suivante en est un exemple.
Figure 4. 16 : Affichage des clients
44
b) Affichage des réservations
Le logiciel permet de visualiser les réservations enregistrées dans le magasin de données. Afin de
faciliter sa lecture, l’affichage a été réalisé à l’aide d’une interface graphique dotée d’un calendrier où les
dates réservées sont mises en évidence en couleur (Fig 4.17). L’affichage est représenté comme suit :
Figure 4.17 : Affichage des réservations
4.3.3 Mise à jour d’une réservation
La figure 4.18 montre l’interface graphique permettant de mettre à jour une réservation. Cette
fonction permet de changer uniquement la date de début et la date de la fin de la réservation concernée.
Autrement dit, le client ainsi que le numéro de la chambre ne changent pas.
Figure 4. 18 : Page de mise à jour d’une réservation
4.3.4 Suppression d’une réservation
Le logiciel possède une fonction permettant de supprimer une réservation. Les paramètres requis
pour y parvenir sont le nom et prénoms du client ainsi que la date de début de la réservation et le numéro
de la chambre (Fig.4.19). La suppression d’une réservation n’affecte aucune autre entité.
45
Figure 4.19 : Formulaire pour la suppression d’une réservation
4.3.5 Facturation
L’application possède une fonction permettant de générer une facture pour une réservation
donnée. Cette fonction calcule le nombre de nuitées (différence entre date de début et date de la fin de
la réservation). Elle permet aussi de sélectionner des services optionnels définis lors de la configuration
du logiciel. La figure 4.20 illustre le formulaire correspondant. Ces données génèrent la facture qui
comporte les informations sur le client, la réservation et le montant total dû par le client (Fig. 4.21).
Figure 4.20 : Formulaire pour la génération d’une facture
46
Figure 4.21 : Exemple d’une facture
De ce qui précède, il apparait que l’utilisation du logiciel correspond exactement au modèle du
système. La conception de l’interface graphique a permis d’optimiser l’ergonomie de l’application. Toutes
les fonctionnalités ainsi que les normes d’authentification et de sécurité suivent le cahier des charges.
47
CONCLUSION
Le Cloud Computing est une solution assez récente car profitant des dernières évolutions
technologiques. Techniquement, il se base sur des technologies standards de la téléinformatique. Plus
précisément, les réseaux informatiques, la virtualisation, les infrastructures de traitement et de stockage.
A la différence des utilisations classiques de ces technologies, le Cloud Computing est orienté vers le
concept informatique ‘comme un service’ : IAAS (Infrastructure comme un Service), PAAS (Plateforme
comme un Service) et SAAS (Logiciel comme un Service).
Le Cloud Computing peut être prometteuse dans la mesure où il y a équilibre entre le service qu’il
peut offrir et son coût. Toutefois, nous avons observé durant ce travail que ce nouveau concept fait
profiter à la fois les informaticiens et les simples usagers. D’une part, il ouvre un nouveau marché pour
les sociétés Informatique voulant s’y mettre. D’autre part, elle peut élargir les possibilités d’une
application grand public car offrant mobilité, flexibilité et sécurité. Ainsi, son exploitation peut varier
d’une utilisation particulière à une autre. Il se présente notamment comme solution d’entreprise et est
déployé entre autres pour son faible coût, sa performance et sa portabilité avec comme unique condition
l’accès à Internet.
Les applications en mode Cloud Computing peuvent être développées avec un large choix de
langages de programmation selon les besoins. Le cahier des charges, les capacités techniques des
développeurs et les délais d’un projet peuvent influencer ce choix. Lors du développement du logiciel
Cloud public An-tànana réalisé au cours de ce mémoire, nous avons choisis la plateforme Google App
Engine et le langage Java pour le développement. Le logiciel effectue les principaux traitements qu’on
peut rencontrer dans une pareille application. En effet, conçu pour la gestion d’un hôtel pour en faire un
cas de démonstration, elle présente plusieurs fonctionnalités qui nécessitait d’approfondir le domaine du
développement d’application et du web. Ce logiciel concrétise un des principaux avantages d’une
application Cloud Computing: la mobilité. En fait, où qu’il soit, avec une connexion Internet, l’utilisateur
(authentifié) peut utiliser le logiciel à tout moment. Afin de se rapprocher le plus possible des cas réels
dans un établissement hôtelier, cette application pourra être munie de fonctionnalités additionnelles. De
la même façon, dans le but de faciliter sa manipulation, son ergonomie, sa sécurité ainsi que sa
performance pourront encore être optimisées.
Ce travail recouvre les principaux domaines de l’ingénierie informatique. Il m’a surtout permis
d’approfondir les réseaux informatiques, le développement logiciel et même la méthode d’élaboration et
d’accomplissement d’un projet. Il a aussi et surtout démontré la faisabilité d’une application Cloud et de
tirer profit de tous ses avantages. Il a montré les principales caractéristiques d’un logiciel Cloud Computing
déployé sur la plateforme Google App Engine particulièrement. Il est aperçu dans ce travail le réel
potentiel du Cloud Computing notamment l’utilisation d’un logiciel Cloud. Dans une perspective
d’amélioration, on peut étudier davantage le Cloud Computing afin de s’occuper de la plateforme, voire
de l’infrastructure et de la virtualisation. En effet, un logiciel opérationnel et commercial est plus rentable
avec une plateforme propre à lui. On peut espérer pour le cas de An-tanana un Cloud privé muni de son
propre infrastructure de traitement.
48
ANNEXES
49
ANNEXE 1 : OUTILS JAVA
A1.1 Descripteurs de déploiement
Les descripteurs de déploiement sont des fichiers généralement au format xml. Accompagnant
les fichiers transférés au serveur, ils servent de guide pour le conteneur web. Des indications au
fonctionnement et à la sécurité sont précisées dans leurs codes. Lors du développement d’An-tànana
v1.0, trois descripteurs ont été nécessaires : web.xml, appengine-web.xml et jdoconfig.xml :
- web.xml aide le conteneur web au fonctionnement général des servlets.
- appengine-web.xml est propre à Google, il est utilisé pour définir le nom et la version
d’une application appengine, activer des paramètres particuliers comme les sessions,
les threads.
- jdoconfig.xml sert à spécifier le l’utilisation de l’API de persistance Java, notamment
avec le Datastore et le mémoire cache.
Ci-après un modèle de code de descripteur web.xml.
Code web.xml:
<?xml version="" encoding=""?>
/* Détails du fichier et informations concernant l’application*/
<web-app xmlns:xsi=""
xmlns=""
xmlns:web=""
xsi:schemaLocation="">
/* Mapping du servlet avec son nom et le chemin url l’appelant */
<servlet>
<servlet-name>Nom_Servlet</servlet-name>
<servlet-class>package.Classe_servlet</servlet-class>
</servlet>
<* Contrainte de sécurité avec type de permission */
<servlet-mapping>
<servlet-name> Nom_Servlet </servlet-name>
<url-pattern>url_appelant_servlet</url-pattern>
</servlet-mapping>
<security-constraint>
<web-resource-collection>
<web-resource-name>Nom_Permission</web-resource-
name>
<url-pattern>url_fichiers_attribués</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>Nom_type_Permission </role-name>
</auth-constraint>
</security-constraint>
50
<welcome-file-list>
<welcome-file>nom_fichier</welcome-file>
</welcome-file-list></web-app>
A1.2 Servlets
Les servlets sont des classes Java surtout utilisées dans la technologie du web. Ci-après un modèle de
codage de cette classe particulière.
Code modèle d’un servlet :
package nom.package;
import java.io.IOException;
/*
public class NomServlet extends HttpServlet
{
/* initialisations nécessaires à la servlet
(facultatifs) */
public void init(ServletConfig config) throws
ServletException{
super.init(config);
public void doPost(HttpServletRequest request,
HttpServletResponse response)
{
/* On écrit ici l’algorithme nécessaire au traitement, le code
nécessaire à l’écriture de la réponse, etc...
Le code suivant récupère la valeur associée au paramètre PARAM
*/
String parametre=request.getParameter("PARAM");
try {
/*
(… traitement : algorithmes …)
/* syntaxes de base affichant un résultat */
Writer writer = response.getWriter();
writer.write("une reponse pour l’utilisateur");
writer.close();
*/
51
objetJsp =
this.getServletContext().getRequestDispatcher("/resultat.jsp");
objetJsp.forward(request, response);
} catch (Exception e){ traitement des erreurs, exceptions }
}
}
A1.3 Implémentation de données avec JDO et l’API Datastore
a) Persistance des données
Premièrement, pour définir une classe comme persistante, il faut la précéder de l’annotation
@PersistenceCapable définie dans la librairie javax.jdo.annotations. Autrement dit, cette
annotation annonce à Java que la classe indiquée est stockable et récupérable à partir du magasin de
données avec JDO. Deuxièmement, pour indiquer à JDO qu’un champ est persistant, il faut le précéder
de l’annotation @Persistent. Enfin, une classe de données doit comporter un champ dédié au stockage
de la clé primaire de l’entité correspondante. Celle-ci est indiquée par l’annotation @PrimaryKey.
@PersistenceCapable
public class Client {
/* Code des champs, constructeurs et méthodes */
}
Figure A. 1 : Exemple de classe de données persistante
Figure A. 2 : Exemple de champ persistant
@PrimaryKey @Persistent private Key key;
Figure A. 3 : Exemple de clé primaire
b) Clés des entités
Chaque entité dans Datastore possède sa propre clé. Cette clé peut prendre forme soit de type
Long, soit de type String et enfin soit de type Key défini dans la librairie
@Persistent private String nom ;
52
com.google.appengine.api.datastore.Key [20] . On la définit comme type Long lorsqu’on veut
qu’elle soit générée par le magasin de données. On la définit comme type String lorsqu’on veut la
définir via l’application. Enfin, le type Key est la plus polyvalente car elle peut être auto générée ou
définie par l’application. De plus, la clé d’une entité fille doit toujours comporter celle de son parent,
dans ce cas il est nécessaire que la clé de l’entité correspondante soit de type Key. Autrement dit, la
clé d’une entité fille doit être toujours de type Key. Dans le cas d’une Key auto générée, on ajoute dans
@Persistence la syntaxe valueStrategy = IdGeneratorStrategy.IDENTITY (Fig A1.4).
Figure A1.4 : Exemple de clé auto générée
Lors du traitement de données, la recherche d’une entité à l’aide de sa clé s’avère théoriquement plus
rapide qu’à l’aide d’une query. D’où notre choix de préférence d’adopter le plus souvent possible des
clés créées « manuellement », donc via l’application. Ainsi, on peut « contrôler » les clés de chaque
entité. Ce qui s’avère indispensable lors du traitement de données, notamment lors d’un algorithme
de lecture, de recherche et de mise à jour d’un objet.
A1.4 JSP (Java Server Page)
Les instructions Java d’un fichier JSP sont incluses dans des balises spéciales. Ils sont généré
dans la méthode _jspService() d’une classe qui implémente l’interface javax.servlet.jspHttpJspPage.
Voici les principales balises en JSP :
Tableau A. 1 : Balises JSP
BALISES DESCRIPTION EXEMPLE
DIRECTIVE :
(<%@ %>)
Directive ou instruction insérée dans des balises
HTML spécifiques.
<%@ page
import="java.util.List"%>
DECLARATION :
(<%! %>)
permet d’insérer du code déclaratif dans la JSP.
Elle peut être utilisée pour définir une variable
globale à la classe ou pour créer des méthodes
Java.
<%! int i = 0; %>
@PrimaryKey @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
private Key cleprimaire;
53
SCRIPTLET :
(<% %>)
utilisé pour placer du code dans la JSP. C’est
généralement l’élément utilisé pour placer tout
code Java, sauf les méthodes et les variables de
classe.
<% int i = 0;
out.println("On peut
aussi afficher une valeur
de variable : " X+ i); %>
L’EXPRESSION :
(<%= %>)
sert à afficher du texte ou un résultat. Ce code
est équivalent à un appel out.print().
<%= client.getNom() %>
A1.5 Outil de développement : Eclipse
Le développement du logiciel An-tànana est réalisé à l’aide de l’IDE Eclipse. Le développement
d’application App Engine en Java sur celui-ci se fait à l’aide du plug-in de Google App Engine.
L’installation de celui-ci s’effectue soit en ligne soit en téléchargeant le fichier sur le site officiel de
Google Developers [23]. Le développement se focalise généralement sur la création des classes de
données (à l’aide de JDO et API de Datastore), la création des servlets pour le traitement des données
et enfin la gestion des fichiers de déploiement (xml).
La création d’un projet App Engine sous Eclipse génère deux dossiers principaux : le ‘src’ et le
‘war’. Dans le premier se trouve les classes Java (classe de données et servlet). Dans le second se trouve
les fichiers statiques ainsi que les fichiers de déploiement. Les classes Java du projet « An-tànana »
sont réparties sous deux packages. Le premier contient les classes de données à manipuler tandis que
le second contient les servlet pour le traitement. Ils sont nommés respectivement ‘donnees’ et
‘traitements’. Un aperçu de l’arborescence des fichiers du projet est illustré dans la figure A1.5
suivante :
54
Figure A1.5 : Arborescence des fichiers (extrait) du projet An-tànana
55
ANNEXE 2 : MODELISATION DU LOGICIEL AN-TANANA v1.0
Description textuelle du Cas d’utilisation : « Gérer client »
1) Sommaire d’identification
Titre : Gérer client
Résumé : Permet à un utilisateur de créer/ rechercher/ supprimer/ visualiser un client.
Acteurs : utilisateur Employé et/ou Gérant sont les acteurs principaux, Système d’autorisation est
l’acteur secondaire
Version : 1
2) Description des scénarios
- Précondition : l’hôtel est configuré, les informations sont en tout cas
demandées par le logiciel lors de sa première utilisation.
- Scenario nominal :
1. L’employé ou le gérant s’authentifie et se connecte
2. Le logiciel, via le système d’autorisation, vérifie que les informations,
identifiant et mot de passe sont corrects.
3. Le logiciel affiche les pages de travail standard, c’est-à-dire pour un utilisateur
simple comme l’employé.
4. l’employé choisit les options d’édition de client comme l’ajout; la
suppression...
5. Le logiciel effectue les taches demandées et met à jour les données dans le
datastore.
- Scenario alternatif : Login erroné
Cet enchainement démarre au point 2. du scénario nominal.
3. Le logiciel indique à l’utilisateur que le login est erroné et demande s’il veut réessayer
4. Le logiciel renvoie la page de connexion, le scénario nominal reprend au point 1.
Description :
L’utilisateur gère les clients en créant de nouveaux ou en utilisant ceux qui existent déjà. Il peut les
modifier, les supprimer et les rechercher. Les éléments caractérisant un client sont les suivants :
• Un nom et un prénom permettant d’identifier de manière unique le client.
• Ses contacts, composés de son mail, son numéro de téléphone et son adresse.
Description du Cas d’utilisation : « Ajouter réservation » et « Visualiser/supprimer réservation »
1) Sommaire d’identification
Titre : Ajouter réservation
Résumé : Permet à un utilisateur de créer une réservation pour un client en le cherchant dans la liste
des clients (Il peut créer dans un premier abord si c’est un nouveau client).
Acteurs : utilisateur Employé et/ou Gérant sont les acteurs principaux, Système d’autorisation est
l’acteur secondaire
Version : 1
56
2) Description des scénarios
Tableau A. 2 : Description des scénarios
Utilisateur Logiciel An-tànana
1. L’utilisateur s’authentifie et se connecte
(s’il ne l’est déjà)
2. Le logiciel, via le système d’autorisation,
vérifie que les informations, identifiant et mot
de passe sont corrects (s’ils ne le sont déjà).
3. l’utilisateur choisit l’une des options
ajout, suppression ou visualisation des
réservations
4. Le logiciel effectue les taches
demandées et met à jour les données dans
le datastore.
Scenario alternatif : Login erroné
Cet enchainement démarre au point 2. du scénario nominal.
3. Le logiciel indique à l’utilisateur que le login est erroné et demande s’il veut réessayer
4. Le logiciel renvoie la page de connexion, le scénario nominal reprend au point 1.
Description :
L’utilisateur peut ajouter, visualiser ou supprimer les réservations à sa guise. Les éléments
caractérisant une réservation sont les suivants :
La durée de la réservation obtenue à partir de sa date de début et sa date de fin.
Le numéro de chambre que cette réservation occupe durant les dates indiquées.
La date de début et le numéro de chambre qu’il occupe forme l’identifiant unique
d’une réservation.
Description textuelle du Cas d’utilisation : « Demander facture »
1) Sommaire d’identification
Titre : Demander facture
Résumé : Permet à un utilisateur de demander une facturation pour des réservations ou des services
consommés par un client.
Acteurs : utilisateur Employé et/ou Gérant sont les acteurs principaux, Système d’autorisation est
l’acteur secondaire
Version : 1
2) Description des scénarios
Préconditions : Existence du client et des services consommées.
Scenario nominale :
1. L’employé ou le gérant s’authentifie et se connecte (s’il ne l’est déjà)
2. Le logiciel, via le système d’autorisation, vérifie que les informations, identifiant et
mot de passe sont corrects.
3. Le logiciel affiche les pages de travail standard, c’est-à-dire pour un utilisateur simple
comme l’employé.
4. L’utilisateur choisi la page pour demander une facturation.
57
5. Le logiciel renvoi la page correspondant à l’obtention d’une facture.
6. L’utilisateur remplit les informations nécessaires au logiciel pour pouvoir générer une
facture.
7. « An-tànana » vérifie que les renseignements sont bien remplis.
8. Le logiciel faits une requête des prix et des services consommées. Puis il effectue le
traitement.
9. Le logiciel renvoie la page affichant la facture, et en même temps propose une option
permettant l’impression de ce dernier.
Scenario alternatif :
A1. Login erroné
L’enchainement A1 démarre au point 2 du scénario nominal.
3. Le logiciel indique à l’utilisateur que le login est erroné et demande s’il veut réessayer
4. Le logiciel renvoie la page de connexion, le scénario nominal reprend au point 1.
A2. Renseignements incomplet
L’enchainement A2 démarre au point 7 du scénario nominal.
8. Le logiciel indique à l’utilisateur qu’il n’a pas rempli tous les champs nécessaire, et demande
de réessayer.
9. Le logiciel renvoi la page correspondant à l’obtention d’une facture, le scénario nominal
reprend au point 6.
Description :
L’utilisateur peut obtenir automatiquement la facturation après avoir donné au logiciel les
informations nécessaire. Il peut même imprimer ce dernier pour l’avoir en format papier. La
facturation détails chaque service consommé avec les prix correspondants. La facturation des
réservations dépend des particularités de la chambre occupée. Les chambres peuvent avoir différents
type de lit: simple, double ou twin (deux lits simples).
Description textuelle du Cas d’utilisation : « Configurer Hôtel » et « Modifier prix»
1) Sommaire d’identification
Titre : Configurer Hôtel / Modifier prix
Résumé : Permet à l’administrateur de configurer les paramètres concernant le logiciel/les prix et
l’hôtel.
Acteurs : l’acteur principal est l’utilisateur administrateur, c’est-à-dire le Gérant. L’acteur secondaire
est le Système d’autorisation.
a. Version : 1
2) Description des scénarios
Préconditions : accès Internet.
Scenario nominale :
1. L’utilisateur se connecte en tant qu’administrateur
2. Le logiciel, via le système d’autorisation, vérifie que ce n’est pas la première utilisation
du logiciel en cherchant qu’il existe bien un administrateur.
3. Le logiciel, via le système d’autorisation, vérifie que les informations, identifiant et
mot de passe sont corrects.
58
4. Le logiciel affiche les pages de configuration.
5. L’administrateur effectue les configurations et valide pour finir.
6. « An-tànana » met à jour le magasin des données.
7. Le logiciel affiche une page de confirmation.
Scenario alternatif :
A1. Administrateur inexistant
L’enchainement A1 démarre au point 2 du scénario nominal.
3. Le logiciel indique à l’utilisateur qu’il devrait d’abord configurer son profil.
4. Le logiciel renvoie la page de connexion administrateur, le scénario nominal reprend au point 1.
A2. Login erroné
L’enchainement A2 démarre au point 3 du scénario nominal.
3. Le logiciel indique à l’utilisateur que le login est erroné et demande s’il veut réessayer
4. Le logiciel renvoie la page de connexion administrateur, le scénario nominal reprend au point 1.
A3. Annulation des paramétrages
L’enchainement A3 démarre au point 5 du scénario nominal.
6. Le logiciel recharge la page de configuration pour attendre des modifications. Le scénario
nominal reprend au point 4.
Description :
La configuration de l’hôtel permet définir les informations initiales au logiciel. Il sert à ce dernier de
connaitre les clients, générer les factures, etc…. Les paramètres de configuration sont :
• Le profil de l’administrateur
• Le nombre de chambre
• Le prix des services disponibles
59
REFERENCES
[1]. Social success, the history of Cloud Computing, www.SalesForce.com, Juillet 2013
[2]. Cloud Computing Definition, http://www.cloud-entreprise.info, Juin 2013
[3]. Cloud Computing, http://fr.wikipedia.org/wiki/ , Juillet 2013
[4]. M. Besson, “ Virtualisation et Cloud Open Source », Edition Smile, 2012
[5]. Hyperviseur VMware, http://www.vmware.com/fr/products/esxi/, Juillet 2013
[6]. A. Folch, « Interface development for Eucalyptus based cloud », Master Thesis,
Vilnius Gediminas Technical University, 2011
[7]. M. Velte, « Cloud Computing », McGraw-Hill Education Pvt Limited, 2009
[8]. E551IA, Téléinformatique, Département Electronique, Ecole Supérieure
Polytechnique d’Antananarivo, Année Universitaire 20011-2012
[9]. D. Sanderson, « Programming Google App Engine », Edition O’Reilly, 2009
[10]. E. Ciurana, « Developing with Google App Engine », Edition Apress, 2009
[11]. Google Research Publication : Bigtable, research.google.com/archive/bigtable.html,
Juin 2013
[12]. Modeling Entity Relationship, https://developers.google.com/appengine/articles/ ,
Juin 2013
[13]. J. Douglas, « Beginning Java Google App Engine », Edition Apress, 2009
[14]. W. Abboud, « Modélisation et conception d’une base de données orientée objet pour
l’inspection automatisée de pièces manufacturées », Projet d’application, Ecole de
Technologie Supérieure, Université du Québec, Avril 1999
[15]. Google’s growing cloud just got a NoSQL database, http://gigaom.com/2013/, Août
2013
[16]. « Etude et conception d’une base de données d’application Cloud sur Google App
Engine - Cas de l’application an-tanana v1.0 – », RAZAFINDRABE Nionja, 2013
[17]. B. Basham, K. Sierra, B. Bates, « Head First Servlets and JSP », Edition O’reilly, 2008
[18]. E411, Génie Logiciel I, Département Electronique, Ecole Supérieure Polytechnique
d’Antananarivo, Année Universitaire 2010-2011
[19]. E550IA, Génie Logiciel II, Département Electronique, Ecole Supérieure Polytechnique
d’Antananarivo, Année Universitaire 2011-2012
60
[20]. A. Goncalves, « Les Cahiers du Programmeurs Java EE5 », Edition Eyrolles, 2007
[21]. E410, Programmation en langage orienté objet, Département Electronique, Ecole
Supérieure Polytechnique d’Antananarivo, Année Universitaire 2010-2011
[22]. Créer des objets persistables, http://www.siteduzero.com/informatique/tutoriels/
montez-votre-site-dans-le-cloud-avec-google-app-engine/creer-des-objets-persistables, Juin
2013
[23]. Installation du SDK Java, https://developers.google.com/appengine/docs/java/, Mai
2013
61
Auteur: TSIFERANARIVO Nasolo Michel
Contact: [email protected]
Titre: Conception d’application Cloud sur Google App Engine – Developpement de la partie
traitement de An-tànana v1.O -
Nombre de pages: 60
Nombre de figures: 45
Nombre de tableaux: 5
Résumé
Le Cloud Computing est un concept qui consiste à accéder à des ressources situées
dans des infrastructures distantes par l’intermédiaire d’un réseau informatique,
généralement Internet. Le logiciel An-tànana est une application Cloud public développée et
hébergée sur la plateforme Google App Engine. Il exploite les ressources de Google et peut
être utilisé depuis n’importe quel terminal ayant accès à Internet.
Mots clés : Cloud Computing, IAAS, PAAS, SAAS, Serveur, Datacenter, Application, Google App
Engine, Logiciel, HTTP, Java, Servlet, An-tànana, Réservation, Client.
Abstract
Cloud computing is a concept based on the use of remote resource as a service. Thus
it use network, usually Internet. An-Tanana software is a public cloud application developed
and hosted on the Google App Engine platform. This way, the software uses the resources of
Google. It can be used from any device within an Internet access.
Keywords: Cloud Computing, IAAS, PAAS, SAAS, Server, Datacenter, Application, Google App
Engine, Software, HTTP, Java, Servlet, An-tànana, Booking, Client.
Rapporteur: Madame RABEHERIMANANA Lyliane Irène