Table Des Matières Cloud1

Thème
:Mise en place d’une solution Cloud

(SaaS)
Présenté par
SOULEYMANE ADAMOU MAHAMADOU SAYOUDI
Encadran Jurys :
t : AL
Mr Rachid
AZAMI Boukharrazi
Mr Wail Bassou
Année 2015/2016
Dédicace
Au nom d'Allah, le Tout Miséricordieux, le Très Miséricordieux. Louange à Allah, Seigneur de

l'univers, le tout Puissant, le Sage de m’avoir facilité la rédaction de ce mémoire.
Je dédie ce travail :
 A ms chers parents qui m’ont donnés la vie grâce à Allah et qui m’ont apportés les
soutiens nécessaires à mon bonne éducation et à mes succès scolaires, au prix de nombreux
sacrifices, qu'ils trouvent ici l'expression de mon entière reconnaissance.
 A mes frères et sœurs pour leur soutien qu’ils trouvent ici l’expression de ma gratitude.
 A tous mes frères et sœurs en Islam qui m’ont aidé d’une manière ou d’une autre.
Mise en place d’une solution Cloud(SaaS) Page i

Mise en place d’une solution Cloud(SaaS) Page ii
Mise en place d’une solution Cloud(SaaS) Page iii
Remerciements
Tout d’abord je remercions ALLAH de m’avoir accordé toutes les facultés afin d’arrivé au
terme de notre cycle.
Nos remerciements vont également :
 A ma famille, aux connaissances et à tous ceux qui m’ont aidé d’une

quelconque manière à l’aboutissement de ce travail.
 A l’ensemble du corps professoral de Sup Management qui ont fait preuve de
patience afin de m’apporter une attention particulière, qu’il trouve sincèrement ma
satisfaction.
 Aux dirigeants de Sup Management pour m’avoir accueillis au sein de ses
locaux et de m’avoir mis à disposition toutes les informations pour la bonne marche de
mes études.
 Au vice doyen de la faculté informatique Mr Basso je lui dis merci infiniment.
 A Mr Al Azami mon enseignant et Directeur de mémoire qu’il trouve ici
toutes mes reconnaissances de m’avoir accordé son temps malgré son emploi du temps
surchargé, qu’il trouve ici tout mes remerciement,
 A Mr Arrahmani notre enseignant de télécommunication pour m’avoir appris
beaucoup sur le domaine de télécom, qu’il trouve ici tous mes remerciement.
 A Mr Naanaani notre enseignant de réseaux pour m’avoir appris beaucoup sur
le domaine de réseau, qu’il trouve ici tous mes remerciements.
 A Mr Ibriz notre enseignant de réseaux aussi pour m’avoir appris beaucoup sur
le domaine de réseaux, qu’il trouve ici tous mes remerciements.
 A Mademoiselle Senhaji Salwa, qu’elle trouve ici tous mes remerciements.
 A Madame Mouhib, qu’elle trouve ici tous mes remerciements.
 Enfin je remercie le gouvernement nigérien qui a financé ma bourse d’étude,
de cette formation.
Mise en place d’une solution Cloud(SaaS) Page iv

Mise en place d’une solution Cloud(SaaS) Page v
SOMMAIRE
Dédicace---------------------------------------------------------------------------------------------------i
Remerciements-----------------------------------------------------------------------------------------ii
Liste des tableaux--------------------------------------------------------------------------------------v
Listes des figures--------------------------------------------------------------------------------------vi
Listes des sigles et abréviations-------------------------------------------------------------------vi
Résume---------------------------------------------------------------------------------------------------ix
Introduction générale---------------------------------------------------------------------------------1
Chapitre 1 : Etat de l'art sur le Cloud computing----------------------------------------------3
Introduction-------------------------------------------------------------------------------------------- 4
I. Définition du Cloud computing----------------------------------------------------------------4
II. Historique du Cloud Computing--------------------------------------------------------------5
III. Les différents services du Cloud computing---------------------------------------------6
IV. Les Modèles de déploiement du Cloud computing-------------------------------------9
V. Avantages et inconvénients du Cloud computing----------------------------------------11
VI. Cloud Computing et le Cluster------------------------------------------------------------13
VII. Sécurité dans le Cloud Computing-------------------------------------------------------13
VIII. Le Cloud Computing : les Différents Acteurs-------------------------------------------18
Conclusion--------------------------------------------------------------------------------------------- 20
Chapitre 2 : Mise en place d’une solution Cloud (SaaS)------------------------------------21
Introduction------------------------------------------------------------------------------------------ 22
I. Solutions existantes---------------------------------------------------------------------------- 22
II. Etude comparative des différentes solutions existantes-------------------------------23
III. Choix de la solution retenue---------------------------------------------------------------24
IV. Présentation détaillée de la solution choisie retenue ( Google App Engine)----24
Conclusion--------------------------------------------------------------------------------------------- 37
Chapitre 3 : Implémentation de la solution---------------------------------------------------38
Introduction------------------------------------------------------------------------------------------ 39
I. Installation de Google App Engine avec Eclipse----------------------------------------39
II. Mise en place du projet------------------------------------------------------------------------ 43
III. Utilisation du service Users---------------------------------------------------------------48
Mise en place d’une solution Cloud(SaaS) Page vi

IV. Utilisation des JSP---------------------------------------------------------------------------50
V. Déclaration de l'application auprès de Google-------------------------------------------54
VI. Manipulation du DataStore avec Objectify---------------------------------------------55
Conclusion--------------------------------------------------------------------------------------------- 70
Chapitre 4 : Mise en œuvre de la solution implémentée----------------------------------71
Introduction------------------------------------------------------------------------------------------ 72
I. Exécution de l’application en local----------------------------------------------------------72
II. Authentification des utilisateurs------------------------------------------------------------74
III. Envoi des messages sur le furum---------------------------------------------------------77
IV. Console d‘administration------------------------------------------------------------------82
Conclusion générale et perspective-------------------------------------------------------------84
WEBOGRAPHIE/BIBLIOGRAPHIE----------------------------------------------------------------87
Table des matières--------------------------------------------------------------------------------------I
Mise en place d’une solution Cloud(SaaS) Page vii

Liste des tableaux
Mise en place d’une solution Cloud(SaaS) Page viii

Listes des figures
Mise en place d’une solution Cloud(SaaS) Page ix

Listes des sigles et abréviations
API Application Programmable Interface

BPaaS Business process as a service
CaaS Communication as a service
CPU Processeur
CDMI Cloud Data Management Interface
CRM Gestion de la Relation Clients Campagnes e-mailing
CSS Cascading Style Sheets
CDN un ensemble de serveurs répartis sur la planète
DaaS Desktop as a service
DSI Direction des Systèmes d’Informations
ERP Établissement recevant du public
EC2 ElasticCompute Cloud
EC2 ElasticCompute Cloud
Go C’est un langage créé par Google assez spécifique et encore expérimental.
GRH Gestion des Ressources Humaines
HRD High ReplicationDatastore
IT Technologies de l'information
IBM International Business Machines
IDS Intrusion System Detection
IHM Interface homme machine
IaaS Infrastructure as a Service
JS JavaScript
JSP JavaServer Pages
JDO Java Data Objet
JPA Java Persistence API
NaaS Network as a service
NoSQL Not Only SQL
NIST National Institue of Standards and Technology
PaaS Plateform as a Service
Python C’est un langage de programmation objet, multi-paradigme et multiplateformes
Payment Card Industry Data Security Standard
PCI DSS
PME Petite et Moyen Entreprise
REST Representational State Transfer
SaaS Software as a Service
SDN Software-defined networking
STaaS Storage as a service
SOAP Simple Object Access Protocol
SDK Software Development Kit
SQL Google Cloud SQL
Mise en place d’une solution Cloud(SaaS) Page x

XML EXtensibleMarkupLanguage.
Résume
Le mémoire de fin d'étude est un prolongement naturel de l'immersion de l'étudiant dans le

monde professionnel, qui comme de coutume, permet à celui-ci de couronner sa dernière
année du premier cycle universitaire. Il met en exergue les qualités de réflexion de l'étudiant
et souligne ses aptitudes d'analyse globale à partir d'une expérience professionnelle.
La réalisation de ce document répond à l'obligation pour tout étudiant en fin de cycle au Sup
Management de présenter un projet de fin d'étude en vue de la validation de l'année
académique. Ce mémoire rend compte simultanément de la découverte du milieu
professionnel et de la conduite d'une mission attribuée à l'étudiant.
Le thème sur lequel s'appuie ce document est «Mise en place d'une solution Cloud
Computing(SaaS) ». Le choix de ce thème se justifie par l'absence de solution de stockageet
de service à temps réel pour les internautes.
Le premier chapitre de ce document parle del’état de l'art sur le Cloud computing. Le
deuxième sur la mise en place d’une solution Cloud (SaaS). Le troisième chapitre portera sur
l’implémentation et le quatrième sur la mise en œuvre de la solution implémentée qui présente
les réalisations pratiques effectuées et les directives d'exploitation.
.
Mise en place d’une solution Cloud(SaaS) Page xi

Introduction générale
Mise en place d’une solution Cloud (SaaS) Page 1

Les étudiants en fin de cycle de l’école Sup Management doivent réaliser un projet de fin
d’étude qui consiste en la résolution d'un problème scientifique et technique. Ce travail doit
être l'occasion pour l'étudiant de mettre au service d'un organisme public ou privé une
démarche synthétique, faisant intervenir tout ou partie des connaissances qui lui ont été
enseignées au cours de sa formation. La période de mémoire est divisée en deux parties: une
première partie qui se déroule à la faculté, parallèlement aux cours théoriques, et pendant
laquelle l'étudiant est supposé faire des recherches bibliographiques concernant son thème de
mémoire et une deuxième partie qui se déroule au sein de l'organisme concerné par le thème
de mémoire. C'est au cours de cette seconde partie que l'étudiant procède à la réalisation
concrète du travail qui lui est demandé.
Le sujet qui m’a été proposé s'intitule donc avec raison « Mise en place d'une solution Cloud
Computing(SaaS) » dans le but d’obtention d’un diplôme d’ingénier en Réseau Sécurité et
Telecom.
Avec l’apparition dans les années 1980 de la virtualisation, de l’infogérance et de

l’externalisation, avec la démocratisation de l’informatique dans les années 90 , et au cours
de la dernière décennie avec la généralisation d’Internet, le développement des réseaux à haut
débit, la location d’application, le paiement à l’usage et la quête sociétale de mobilité,
actuellement, une nouvelle "tendance" a fait son apparition dans le monde des IT
(Technologies de l'information et de la communication), il s'agit du Cloud computing.
Le terme Cloud Computing, ou « informatique dans les nuages », est un nouveau modèle
informatique qui consiste à proposer les services informatiques sous forme de services à la
demande, accessibles de n'importe où, n'importe quand et par n'importe qui. Cette nouvelle
technologie permet à des entreprises d'externaliser le stockage de leurs données et de leur
fournir une puissance de calcul supplémentaire pour le traitement de grosse quantité
d'information.
C'est certainement ce qui a motivé mon Directeur de mémoire Mr Akram Elazami a proposé
ce thème que moi aussi j’ai choisie et que nous avons réalisé sous sa supervision.
Mon travail sera divisé en quatre chapitre, chaque chapitre sera subdivise en des points. Le
premier chapitre portera sur l’état de l'art sur le Cloud computing, le deuxième chapitre sur la

mise en place d’une solution Cloud (SaaS), le troisièmeportera sur l’implémentation de la

solution et le quatrième sur la mise en œuvre de la solution implémentée.

Chapitre 1 : Etat de l’art sur le Cloud computing
Chapitre 1 : Etat de l'art sur le Cloudcomputing

Introduction
Le Cloud computing, s'appuyant sur le WEB 2.0, offre des occasions aux sociétés de réduire
les coûts d'exploitation des logiciels par leurs utilisations directement en ligne. Celui-ci
consiste en une interconnexion et une coopération de ressources informatiques, situées au sein
d’une même entité ou dans diverses structures internes, externes ou mixtes. Et dont les modes
d’accès sont basés sur les protocoles et standards Internet.
Divers fournisseurs comme Google, Amazon, IBM offrent une vaste gamme de services de
Cloud Computing. Cette technologie vient juste d'éclore, elle est au début de son exploitation
mais déjà plusieurs acteurs majeurs cités précédemment adoptent leurs propres stratégies de
pionnier qui déterminera l'utilisation du Cloud computing des entreprises souhaitant investir.
De plus, on remarque aussi que des plus petits acteurs se battent pour une part de marché.
Beaucoup d'entreprises restent cependant sceptiques sur le Cloud computing. La principale

raison est l'intégrité et la sécurité des données car les DSI (direction des systèmes
d'informations) restent frileuses de penser que leurs données critiques sont dans un endroit
incontrôlé et souvent inconnu.
I. Définition du Cloud computing
Le National Institue of Standards and Technologie (NIST) en a donné une définition qui est
souvent citée comme référence. Cette définition a été reprise dans le magazine Global
Security Mag :
« L’informatique dans les nuages » est une nouvelle façon de délivrer les ressources
informatiques, et non une nouvelle technologie. »

C’est un modèle qui permet l’accès au réseau à la demande. Les ressources sont partagées et
la puissance de calcul est configurable en fonction des besoins. Le client peut bénéficier d’une
flexibilité importante avec un effort minimal de gestion. Il se caractérise par :
 Un accès en libre-service à la demande aux capacités de calcul. Ce service

sera le plus souvent effectué par le fournisseur de service de façon automatique sans
nécessiter d’interaction humaine.
 Un accès ubiquitaire au réseau : les capacités sont disponibles sur le réseau et
accessibles par des mécanismes standards, qui favorisent l’accès au service par des
clients lourds, légers, des smartphones… via des plates-formes hétérogènes.
 Une mise en commun des ressources : les ressources de calcul sont mises à
disposition des clients sur un modèle multi-locataires, avec une attribution dynamique
des ressources physiques et virtuelles en fonction de la demande. Le client n’a
généralement aucun contrôle ou connaissance sur l’emplacement exact des ressources
fournies.
 Une « Elasticité rapide » : les capacités proposées peuvent rapidement
augmenter ou diminuer en fonction des besoins.
 Un service mesuré en permanence : les systèmes contrôlent et optimisent
automatiquement l’utilisation des ressources par rapport à une moyenne estimée de
consommation du service. L’utilisation des ressources peut être gérée, contrôlée et
communiquée, fournissant ainsi de la transparence au client et au fournisseur.
II. Historique du Cloud Computing
Le Cloud computing n'est pas nouveau, il est exploité depuis les années 2000, les
changements qui ont permis l'apparition du Cloud computing sont nombreux. Ainsi on peut
citer l'apparition du SaaS (Software as a Service), le produit délivré par le Cloud.
Puis il y a le concept de virtualisation qui permet une mutualisation des serveurs et offre donc
une mise en production simplifiée et un meilleur ratio d'utilisation des ressources.

Le Cloud computing est donc la juxtaposition de ces technologies pour passer à la vitesse
supérieure sur l'exploitation de données à travers Internet.
Le concept du Cloud Computing a été mis en œuvre en 2002 par Amazon, un leader du e-
business, à travers l'histoire d'Amazon Web Services pour absorber la charge importante des
commandes faites sur leur site au moment des fêtes de Noël en mettant en place une très
grosse infrastructure technique qui est constituée de plusieurs serveurs regroupés dans des
grands entrepôts appelés Datacenter.
Aujourd’hui des grandes entreprises du secteur informatique comme IBM, Microsoft, Google,
SAP, DellOracle, Apple, Hewlett-Packard, Thales Services ou Orange Business Services font
aussi la promotion du Cloud computing, qui constitue un important changement de
paradigmedes systèmes informatiques, jusque-là constitués de serveurs situés au sein même
de l'entreprise.
III. Les différents services du Cloud computing
Du point de vue économique, le Cloud computing est essentiellement une offre commerciale
d'abonnement économique à des services externes. Selon le National Institute of Standards
and Technology il existe quatre catégories de services qui peuvent être offerts en Cloud
computing.
III.1. Infrastructure as a Service (IaaS)
C'est le service de plus bas niveau. Il consiste à offrir un accès à un parc informatique
virtualisé. Des machines virtuelles sur lesquelles le consommateur peut installer un système
d'exploitation et des applications. Le consommateur est ainsi dispensé de l'achat de matériel
informatique.

Ce service s'apparente aux services d'hébergement classiques du centre de traitement de

données, et la tendance est en faveur de services de plus haut niveau, qui fait d’avantage
abstraction de détails techniques.
L’IaaS a des avantages et inconvénients :
Avantage : grande flexibilité, contrôle total des systèmes (administration à

distance par SSH ou Remote Desktop, RDP), qui permet d'installer tout type de logiciel
métier.
Inconvénient : besoin d'administrateurs système comme pour les solutions de

serveurs classiques sur site.
III.2. Plateform as a Service (PaaS )
Dans ce type de service, situé juste au-dessus du précédent, le système d'exploitation et les
outils d'infrastructure sont sous la responsabilité du fournisseur. Le consommateur a le
contrôle des applications et peut ajouter ses propres outils. La situation est analogue à celle de
l'hébergement web où le consommateur loue l'exploitation de serveurs sur lesquels les outils
nécessaires sont préalablement placés et contrôlés par le fournisseur. La différence étant que
les systèmes sont mutualisés et offrent une grande élasticité - capacité de s'adapter
automatiquement à la demande, alors que dans une offre classique d'hébergement web
l'adaptation fait suite à une demande formelle du consommateur.
Le PaaS a des avantages et inconvénients :
Avantage : le déploiement est automatisé, pas de logiciel supplémentaire à

acheter ou à installer.
Inconvénient : limitation à une ou deux technologies (ex. : Python, GO ou Java
PHP pour Google AppEngine, .NET pour Microsoft Azure, propriétaire pour
force.com). Pas de contrôle des machines virtuelles sous-jacentes.
Pour ce genre de service les cibles sont les développeurs. Google App Engine est le principal
acteur proposant ce genre d'infrastructures.
III.3.Software as a Service (SaaS)
Dans ce type de service, des applications sont mises à la disposition des consommateurs. Les
applications peuvent être manipulées à l'aide d'un navigateur web ou installées de façon
locative sur un PC, et le consommateur n'a pas à se soucier d'effectuer des mises à jour,
d'ajouter des patches de sécurité et d'assurer la disponibilité du service. Gmail est un exemple
de tel service. Il offre au consommateur un service de courrier électronique et le
consommateur n'a pas à se soucier de la manière dont le service est fourni. Autre
exemple, Office 365 propose un ensemble de services en abonnement dont la suite logicielle
Office qui se met automatiquement à jour, l'utilisateur ne se soucie pas de racheter un
nouveau logiciel ou de le mettre à jour. On parle ici de location de services hébergés par
Microsoft. D'autres exemples de logiciels mis à disposition en Saas sont Google Apps, Office
Online ou LotusLive (IBM). Un fournisseur de software as a service peut exploiter des
services de type platform as a service, qui peut lui-même se servir de infrastructure as a
service.
Le SaaS a des avantages et inconvénients :
Avantage : plus d'installation, plus de mise à jour (elles sont continuées chez le
fournisseur), plus de migration de données etc. Paiement à l'usage. Test de nouveaux
logiciels avec facilité.
Inconvénient : limitation par définition au logiciel proposé. Pas de contrôle sur
le stockage et la sécurisation des données associées au logiciel. Réactivité des
applications Web pas toujours idéale.
Les cibles sont les utilisateurs finaux. On retrouvera des entreprises comme Sales Force ou
Diva (projet lancé par une équipe de l'école d'ingénieur EPITECH).
III.4.Data as a Service (SaaS)

Correspond à la mise à disposition de données délocalisées quelque part sur le réseau. Ces
données sont principalement consommées par ce que l'on appelle des mashups. C'est le cas
d'Amazon S3 (un service d'Amazon Web Services) qui vous propose autant d'espace de
stockage que nécessaire.
Il existe plusieurs dont on peut citer entre autre :
Business process as a service (BPaaS) : il s'agit du concept de (BPaaS) qui

consiste à externaliser une procédure d'entreprise suffisamment industrialisée pour
s'adresser directement aux managers d'une organisation, sans nécessiter l'aide de
professionnels de l'informatique
Desktop as a service (DaaS) : c’est l’externalisation d’une virtual desktop
infrastructure auprès d’un fournisseur de services. Généralement, le desktop as a service
est proposé avec un abonnement payant.
Network as a service (NaaS) : lenetwork as a service correspond à la fourniture
de services réseaux, suivant le concept de software defined networking (SDN).
Storage as a service (STaaS) : stockage de fichiers chez des prestataires
externes, qui les hébergent pour le compte de leurs clients. Des services grand public,
tels que Microsoft OneDrive, SugarSync et Box.net, proposent ce type de stockage, le
plus souvent à des fins de sauvegarde ou de partage de fichiers. Voicid'autresexemples :
Microsoft SharePoint, Amazon S3, Dropbox, Google Drive, HubiC, iCloud, Ubuntu
One, Windows Live Mesh, Wuala.
Communication as a service (CaaS) : correspond à la fourniture de solutions de
communication substituant aux matériels et serveurs locaux (PABX, ACD, SVI…) des
ressources partagées sur Internet.

Figure 1 : Les différents types de Cloud
IV. Les Modèles de déploiement du Cloud computing
Par ailleurs, le NIST distingue quatre modèles de déploiement pour le Cloud : privé, public,
communautaire ou hybride, correspondant à des usages différents.
IV.1. Le Cloud privé
Le Cloudcomputing prive est subdivise en deux : interne et externe.
IV.1.1. Cloud privé internalisé
Plateforme de Cloud Computing interne à l’entreprise ou Cloud entièrement dédié à cette

même entreprise,accessible via des réseaux sécurisés, opérés par des équipes internes.

Le Cloud privé internalisé permet de :
conserver la maîtrise des infrastructures tout en proposant en interne à

l’entrepriseun modèle orienté services pour la fourniture d’infrastructures ou de
plateformes métiers,
garantir un très haut niveau de confidentialité et de sécurité des infrastructures,
simplifier la gestion du provisionnement en créant une couche d’abstraction
vis-à-vis des ressources physiques,
réduire les coûts, d’améliorer les niveaux de service et réduire les risques.
IV.1.2. Cloud privé externalisé
Plateforme de Cloud Computing qui vise à fournir de manière externalisée, les services et
garanties équivalents à ceux offert par un Cloud privé interne tout en ajoutant le bénéfice d’un
hébergement et de services de gestion opérés par un tiers. Il peut être accessible par Internet
ou par un réseau privé.
Le Cloud privé externalisé permet de :
conserver la maîtrise des infrastructures tout en proposant à l’entreprise un

modèle orienté services pour la fourniture d’infrastructures ou de plateformes métiers,
garantir un très haut niveau de confidentialité et de sécurité des infrastructures,

simplifier la gestion du provisionnement en créant une couche d’abstraction
vis-à-vis des ressources physiques,
réduire les coûts, d’améliorer les niveaux de service et réduire les risques,
bénéficier d’une architecture technique complète hautement disponible avec
souvent
Des plans de continuité d’activité possibles et optionnels.

IV.2. Le Cloud communautaire
Le Cloud Communautaire, est un Cloud utilisé par plusieurs entités ou organisations, qui sont
animées de besoins communs. Il peut être employé pour des applications génériques, avec des
particularités ajustées aux contraintes du groupe. Nous pouvons trouver en exemple le
stockage Communautaire monté par la GSA aux Etats Unis, pour les organisations
gouvernementales américaines. Ce type de plateforme peut héberger une application métier
spécifique, louée en commun par plusieurs entreprises.
IV.3.Le Cloud public.
Le Cloud public (public Cloud) : les ressources sont fournies par un prestataire et mutualisées
pour un usage partagé par plusieurs clients. L'infrastructure est mise à la disposition du grand
public (c'est-à-dire de plusieurs entreprises) mais elle appartient à un fournisseur de services
informatiques, le niveau de service étant défini par le fournisseur et identique pour tous les
utilisateurs.
IV.4.Le Cloud hybride
L’idée de combiner le Cloud privé avec le Cloud public, a entraîné la conception d’un autre
pseudo-type de Cloud, le Cloud hybride ou mixte. En réalité, ce type de plateforme hybride
n’est pas un Cloud à part entière. Puisqu’on cherche à mettre ensemble et à faire
communiquer les deux modes précités, le Cloud hybride sert donc uniquement de liaison entre
eux. La tendance actuelle des services de stockage s’oriente vers l’adoption du Cloud hybride.
Dès que nous pensons à déployer un Cloud privé, nous devons considérer également celui
public en excès, en prévision des surcharges de nos capacités internes. Et l’hybride vient
compléter l’ensemble. Mais la mise en place d’une plate-forme de fédération des identités, ou
l’utilisation d’un service Cloud, n’est pas un Cloud hybride.
V. Avantages et inconvénients du Cloud computing
V.1. Avantages

Le Cloud computing est généralement associé à une multitude d’avantages qui créent
l’unanimité parmi les professionnels de l’entreprise. Notons toutefois que ces avantages
demeurent théoriques, étant donné la nature même du concept :
La possibilité de déployer et de rendre disponibles des applications majeures et

des environnements de travail de manière immédiate. La mise à jour des applications est
systématique, et le fournisseur décharge son client de toute responsabilité de
maintenance. Une simplicité imbattable donc, qui nous épargne en plus les
développements coûteux,
Les données peuvent être partagées, puisque tout utilisateur du Cloud
computing peut aisément rendre disponibles ses données à un ou plusieurs autres
utilisateurs du Cloud computing. Il est donc possible de créer une plateforme virtuelle
collaborative en un temps record.
Un calcul particulièrement puissant, ce qui constitue probablement l’argument
de choc en faveur de ce type de solution. Il faut effectivement garder à l’esprit que les
structures limitées à ce niveau (puissance de calcul) peuvent ici se permettre une
délocalisation de leurs traitements, et bénéficier ainsi de toutes les ressources et
performances mises à leur disposition par le serveur du Cloud computing. Bien qu’il ne
concerne qu’un nombre assez réduit d’entreprises, cet avantage demeure l’un des plus
importants du Cloud computing,
Un accès libre et ouvert au client, qui peut établir sa connexion de n’importe où
et avoir accès à ses données immédiatement, sans passer par la mise en place d’un VPN
(réseau privé virtuel) dans l'entreprise.
Un suivi constant du développement de notre espace Cloud computing. Nous
sommes généralement informé, en temps réel, de l’évolution de notre plateforme de
Cloud computing, puisque l’installation d’un logiciel n’est pas nécessaire et que l’accès
est effectué via un simple navigateur web,
Une liberté totale, puisque nous ne sommes lié à notre fournisseur par aucun
engagement à long terme. Les services du Cloud computing sont soit facturés à la
demande ou par abonnement mensuel. Nous demeurons donc libre de mettre un terme à
ce service à tout moment, si nous jugeons n’en avoir plus besoin, ou si nous désirons
simplement changer de fournisseur.
Coût : du fait que le même service est proposé à de nombreux utilisateurs, son
coût en est nettement amoindri.

V.2. Inconvénients
La question controversée de la confidentialité et de la sécurité de nos données demeure la

limite majeure de cette solution. L’hébergement de nos données se fait en effet en dehors de
l’entreprise, dans un service de base mis à notre disposition par notre fournisseur. Le risque de
voir nos données finir en situation de vol ou de mauvaise utilisation demeure donc une
possibilité.
Notre rôle, à ce niveau, consiste à veiller à ce que notre fournisseur propose une sécurité
suffisamment exhaustiveet à ce qu’il mette à notre disposition une politique de confidentialité
englobant toutes nos données.
En fonction du fournisseur choisi, notre marge de manœuvre peut être limitée par la nature de
l’offre proposée. Par exemple, si nous souhaitons accéder à certaines fonctionnalités de notre
choix, notre fournisseur pourrait être dans l’impossibilité de les proposer. A vérifier avec
notre fournisseur.
VI. Cloud Computing et le Cluster
Le but du Cloud computing est de construire un nuage de clusters, c'est à dire d'interconnecter
un ensemble de machines sur un réseau défini. Les utilisateurs peuvent ensuite déployer des
machines virtuelles dans ce nuage, ce qui leur permet d'utiliser un certain nombre de
ressources.
Par exemple de l'espace disque, de la mémoire vive, ou encore du CPU (processeur).

Figure 2:Cloud Computing et Cluster
VII. Sécurité dans le Cloud Computing

L'utilisation de plus en plus fréquente du Cloud computing fait apparaître de nouveaux risques
de sécurité. Augmentant ainsi l'intérêt des criminels à trouver de nouvelles vulnérabilités et
exposant les utilisateurs à voir leurs données compromises. Pour atténuer cette menace, les
intervenants du Cloud devraient investir massivement dans l'évaluation des risques
informatiques afin de s'assurer que les données sont bien protégées. Établir des bases fiables
et des normes pour sécuriser leur infrastructure. Tout ceci afin d'établir la confiance dans cette
nouvelle technologie qu'est le Cloud computing.
En 2009, le groupe "Cloud security alliance" a été formé pour promouvoir les bons usages en
matière de sécurité dans le milieu du Cloud. Depuis ce groupe compte 40 000 membres.
VII.1.La sécurité des données
La non-interopérabilité des fournisseurs

Un client peut éprouver le besoin de changer de fournisseur de Cloud. Celui-ci ne peut

aujourd'hui pas effectuer un transfert de stockage directement de son fournisseur vers un
autre. Néanmoins, la norme CDMI (Cloud Data Management Interface) décrit un format
d'échange qui permet de déplacer les données d'un environnement Cloud vers un autre.
Le chiffrement dans le Cloud
Le client peut utiliser le chiffrement des données pour le stockage dans le Cloud, mais il
reste à définir qui doit contrôler les clés de chiffrement et de déchiffrement. En toute
logique, ceci doit être géré par le client.
L'intégrité des données
Dans le Cloud, il est nécessaire d'assurer l'intégrité des données pendant un transfert ou
un stockage. Il faut donc que les opérations sur les données soient contrôlées afin de
n'effectuer que les opérations qui sont autorisées. Il n'existe actuellement pas de
standard commun entre les fournisseurs de Cloud.
La gestion des logs
Dans le respect du PaymentCardIndustry Data Security Standard (PCI DSS), les logs
doivent être fournis au gestionnaire de sécurité.
Le stockage
Les données peuvent être transférées entre plusieurs datacenter géographiquement

éloignés. Le particulier ou l'entreprise ne connait pas la position des données entre
chaque datacenter.

La confidentialité
Le propriétaire des données doit savoir quelles informations sont gardées et dans
certains cas être capable de demander leur suppression. Pour ce qui est du paiement
sécurisé ou PaymentCardIndustry Data Security Standard (PCI DSS), les données
bancaires et la trace des transactions doivent pouvoir être transférées aux autorités et
personnes chargées des régulations.
VII.2. La sécurité des infrastructures
La sécurité physique
La sécurité physique est rompue avec le modèle du Cloud, à cause de la notion de

partage de ressources et de virtualisation. Une machine physique partage ses ressources
avec les différentes machines virtuelles qu'elle héberge et ceci indépendamment du
client de la machine. Il revient logiquement au fournisseur de choisir ou mettre en place
son architecture et quelle sécurité physique est déployée, mais aussi protéger et
documenter l’accès aux données utilisateur.
L'audit
Le fournisseur de Cloud doit être audité sur la sécurité de ses infrastructures et de ses
solutions par une société externe ou passer acquérir une certification.
Les mises à jour
Afin de bénéficier des mises à jour de sécurité sur les produits qui sont installés ou
utilisés sur l'infrastructure Cloud, le client doit s'assurer d'effectuer régulièrement les
mises à jour.

Test de sécurité de l'image de base
Le Cloud est basé sur la virtualisation, ceci permet au fournisseur de créer une image de
base sécurisée et à jour afin de déployer à la demande d'un client une machine ou un
service. Elle permet au fournisseur de mettre en place des patchs de sécurité mais
également de tester les impacts de l'installation de celui-ci
VII.3. La justice et le Cloud
La sécurité de la localisation des données
Dans le Cloud, les données d'un particulier ou d'une entreprise sont hébergées chez le
fournisseur. Les lois concernant le transfert de données personnelles ainsi que la
conservation des données peuvent différer d'un pays à l'autre. Dans le cas où des
données violent la loi de l’État où elles résident il y a un risque potentiel de saisie par le
gouvernement.
La confidentialité des données
Le client doit connaître l'utilisation de ses données et pouvoir faire valoir ce droit de
confidentialité devant la justice afin que le fournisseur justifie de l'utilisation de ses
données.
Les données confidentielles

 Toute information permettant d'identifier un individu.
 Toute information récoltée par le biais d'un ordinateur personnel.
 Toute information permettant la localisation d'un périphérique personnel.
 Toute information personnelle d'un individu.
VII.4. L'isolation

Le Cloud computing introduit le partage de ressources, ce qui peut potentiellement mener à

des attaques de type attaque par canal auxiliaire (écoute passive d'informations) ou canal
caché (envoi d'informations) entre différentes machines virtuelles évoluant dans le même
environnement.
Le problème d'isolation réside dans le fait que l’environnement (machine virtuelle) d'un
attaquant peut potentiellement se retrouver sur la même machine physique d'un utilisateur
cause que cette dernière héberge de multiples machines virtuelles. Cela lui permet de mettre
en place différentes attaques matérielles ou logicielles pour écouter ou perturber les autres
machines virtuelles
VII.5. Les attaques et l'impact sur le Cloud
Les composants de sécurité telle que les pare feu ou les systèmes de détection d'intrusion, ne
sont pas adaptés pour détecter les attaques distribuées. Ces attaques sont donc subdivisées en
sous attaques afin d'être indétectable par de tel système de sécurité :
Balayage de port
L'attaque par balayage de port permet à celui-ci de découvrir des ports de communication
exploitables. Cette attaque peut être évitée grâce à des systèmes de sécurité comme un pare-
feu ou encore un système de détection d'intrusion( IDS) : Intrusion System Détection. Les
infrastructures du Cloud sont sensibles à ce type d'attaque si celle-ci est effectuée en parallèle.
Un système tel que l'IDS analyse une partie du trafic et ne détecte donc pas une attaque par
scan de port si celle-ci est effectuée avec différents scanner. Les solutions de sécurité actuelle
ne sont pas adaptées pour ce type d'attaque sur une telle infrastructure.
Déni de service
L'attaque par déni de service a pour but de rendre un service indisponible par une surcharge
réseau par exemple. Le fournisseur doit mettre en œuvre les solutions contre ces attaques.
Cette attaque peut être évitée grâce à la scalabilité du Cloud. Des services comme Amazon
permettent dynamiquement de mettre davantage de ressources ou d'instances suivant le
besoin. Néanmoins, les clients n'utilisant pas les services de scalabilité sont soumis aux
risques de ces attaques, il est dans ce cas difficile de détecter ces attaques pour les bloquer
cause du potentiel nombre d'attaques simultanées.

L'exploitation de bogue logiciel
Le client et le fournisseur doivent s'assurer que les logiciels qu'ils utilisent sont à jour afin
d'éviter l'exploitation des bogues logiciels. Cette action ne permet pas de les éviter mais de
limiter les risques.
Attaque de l'homme du milieu
L'attaque de l'homme du milieu est dans le but d'intercepter les communications entre un
client et un serveur afin de consulter, capturer et contrôler la communication en toute
transparence.
Analyseur de paquets
L'analyseur de paquets est une application ou un périphérique qui permet de lire, capturer les
données qui transitent sur un réseau. Cette attaque permet à l'attaquant de récupérer les
données puis les lire.
Attaque par injection de malicielCloud
Le principe de cette attaque est d'injecter sur une des plateforme du Cloud (Saas, Iaas, Paas)
du code malicieux afin de compromettre l'infrastructure victime.
VIII. Le Cloud Computing : les Différents Acteurs
Amazon, Microsoft, Google, Salesforce, IBM : autant d'acteurs majeurs dont il faut parler
pour comprendre les directions que prendra le Cloud Computing d'ici peu. Car, qu'on le
veuille ou non, le Cloud dépend en grande partie de ces géants du web et de l'informatique,
mais également de nos équipements de télécommunications.
VIII.1. Les acteurs de IAAS (Infrastructure as a Service)
Il s'agit de sociétés mettant à la disposition du marché des ressources d'infrastructure

mutualisées et localisées dans des datacenters distants telles que des ressources de stockage
de calcul ou encore de puissance machine. Dans cette catégorie, on recense des acteurs
comme Amazon Web services, Windows Azure, IBM ou encore Orange. Sur ce marché, les
opérateurs télécoms, spécialistes des réseaux, ont leur carte à jouer et certains proposent déjà

des solutions d'accès réseaux à la carte ou à la demande. Ce segment de marché du Cloud,

encore peu important, n'intéresse encore que les très grandes entreprises. Et pourtant, l'IaaS
est nécessaire pour offrir la flexibilité et l'automatisation promise par le Cloud : d'où son fort
potentiel de croissance auprès des entreprises clientes mais aussi auprès des autres
fournisseurs de briques Cloud tels que les éditeurs de logiciels qui ont besoin d'infrastructures
de type IaaS pour déployer leur propres solutions Cloud.
VIII.2. Les acteurs du PAAS (Plateforme as a Service).
Ils sont spécialisés dans la fourniture d'environnements middleware et de plateformes de

développement en mode Cloud. La plateforme est hébergée et mise à disposition pour des
tests ou proposée dans un environnement de production pour les développements. On y trouve
des acteurs comme Salesforce.com ou Google qui proposent des plateformes PaaS autour de
leurs solutions SaaS permettant notamment d'en étendre le périmètre fonctionnel (Force.com
dans le cas de Salesforce, GoogleAppEngine dans le cas de Google), ou des acteurs comme
Heroku ou Microsoft avec Windows Azure qui offrent des environnements de développement
complets en mode Cloud. Mais ce segment du Cloud, le plus récent, n'en est encore
aujourd'hui qu'à ses balbutiements même s'il promet d'être un segment extrêmement
compétitif au vu du nombre important d'acteurs, pure players ou éditeurs historiques, qui se
positionnent sur ce marché.
VIII.3.Les acteurs du SAAS (Software as a Service).
Les éditeurs et autres fournisseurs de logiciels de gestion en mode Cloud (souvent d'anciens
pionniers de l'ASP) constituent de loin le principal moteur de croissance de ce marché. Le
SaaS génère à lui seul plus de 80% des revenus du monde du Cloud aujourd'hui. Sa cible est
large : les entreprises de toutes tailles, et en particulier les PME. Ces dernières années, nous
assistons à la multiplication des offres SaaS, avec une accélération en 2010. Les domaines
applicatifs les plus touchés par la vague du SaaS sont historiquement les applications de
collaboration d'entreprise (messagerie, agenda partagé, gestion de projet, conférence web,
etc.), la GRH (gestion de la paie et des ressources humaines ), le CRM (gestion de la relation
clients, campagnes e-mailing...), la finance (gestion de trésorerie, des notes de frais, de la
facturation, etc.), la gestion des achats (gestion d'appels d'offres, e-sourcing, e-procurement,

etc.). Plus récemment, l'ERP, pourtant plus difficile à externaliser vu son caractère critique
pour l'entreprise, devient lui aussi candidat au SaaS, surtout à destination des PME ou des
départements de grands comptes.

Conclusion
En conclusion nous pouvons dire que le Cloud computing est actuellement un hype qui n'est
pas prêt à disparaître. On ne peut toutefois qu'apprécier le fait de pouvoir synchroniser tous
types d'appareils vers des espaces de stockage, qu'il s'agisse de PC, de smartphones ou autres :
tout est fait pour centraliser le traitement et la gestion des données, et c'est plutôt une bonne
chose. Laissons les différents acteurs contribuer au développement du Cloud Computing, en
espérant toutefois que le succès du concept ne crée pas une trop forte demande de plus en plus
avantageuse pour les prestataires et éditeurs, mais de plus en plus pénible pour la
compréhension des internautes.

Chapitre 2 : Mise en place d’une solution Cloud (SaaS)

Introduction
Dans le domaine du Cloud computing, plusieurs acteurs sont impliqués : les fournisseurs
d’offres publiques et ceux proposant le système sous forme de logiciels pouvant être
employés en privé. Les solutions du Cloud sont ainsi classées en deux grandes catégories : les
solutions propriétaires et les solutions open source.
I. Solutions existantes
Actuellement, trois acteurs potentiels existent sur le marché du Cloud computing public.
Windows par sa plateforme Azure, Google par sa plateforme de développement
d’applications AppEngine et Amazon par ses services EC2 de l’informatique virtuelle.
I.1. Windows Azure
Azure est une plateforme de Microsoft pour les services PaaS du Cloud computing. Il s’agit
d’une plateforme de développement d’applications fournissant les services d’exécution et
d’administration d’applications en offrant les outils nécessaires. Elle permet aux développeurs
de programmer et de stocker directement leurs applications sur Internet en leur allouant
dynamiquement des machines virtuelles de son centre de données (data center). Windows
Azure est une plateforme flexible qui supporte plusieurs langages de programmations tels que
Java, PHP, Python, etc. De plus, elle supporte les standards et protocoles tels que SOAP,
XML, etc.
L’infrastructure soutenant la plateforme Azure est basée sur la solution de virtualisation Xen.
I.2. Google AppEngine
AppEngine est une offre de Google pour les services de type PaaS. Le développement et le
déploiement d’applications sur la plateforme de Google sont rendus possibles grâce à un
SDK(22) conçu par Google et mis à la disposition des utilisateurs afin de leur permettre de
développer en local pour ensuite déployer l’application vers l’Internet. L’idée est de permettre
aux utilisateurs d’employer l’infrastructure de Google pour héberger leurs applications avec la
possibilité de définir le groupe d’utilisateurs de cette dernière. Ces applications bénéficient de
la haute disponibilité des infrastructures de Google.
I.3. La plateforme EC2 d’Amazon

Les services d’Amazon EC2 (ElasticCompute Cloud) concernent l’exposition de machines

virtuelles pour les activités telles que l’hébergement, les grilles de calcul ou les tests en
réseaux informatiques.
L’utilisation des services d’Amazon est facturée selon le temps d’utilisation des machines
louées.
II. Etude comparative desdifférentes solutions existantes

Le tableau ci-dessous nous dons une étude comparatives des trois grandes solutions
existantes du PaaS.
Tableau n°1 : Etude comparatives des trois grandes solutions existantes du PaaS
Avantages Inconvenie
Service Langages IDE nts
Editeur Basesdedonnées
Amazon Amazon Web Containers Extensions AWS Amazon RDS, Richesse des Complexité
ElasticBe Services Docker, Java Toolkit pour DynamoDB, offres et de du pricing
anstalk (Tomcat), Eclipse et SimpleDB, SQL l'écosystème
.NET, Microsoft Visual Server, Oracle, Amazon Web
Node.js, PHP, Studio IDBM DB2, Services,
Python, Ruby Informix disponible
(Passenger) tant sur les
architectures
Linux que
.NET
Google Google Java, Google Plugin for Cloud SQL Richesse du Peu de
App Python, PHP Eclipse pour Java catalogue langages
Engine 5.4, Go d'offres supportés,
Cloud pricing
Google complexe
Azure Microsoft Java, WebMatrix, Data Services Nombreux Complexit

Cloud Node.js, Visual Studio + Microsoft : langages é du
Services PHP, Azure SDK Blobs, base supportés, pricing
Python, SQL, SQL richesse de appliqué
.NET, Ruby Server, l'offre
MongoDB CloudMicros

oft
III. Choix de la solution retenue

Au vu de ce comparatif des différentes solutions du PaaS, Google App Engine apparaît
comme la plus performante et évolutive s'adaptant aux attentes des entreprises. Elle répond
également aux critères de sécurité dont nous avons besoin.
IV. Présentation détaillée de la solution choisie retenue ( Google App

Engine)
Google a mis à disposition la première version Google App Engine en avril 2008. Au grand
désappointement de beaucoup de développeurs Java, cette version initiale était réservée aux
programmeurs Python - des gens qui pensent que les espaces sont là pour délimiter des blocs.
Google a répondu à la pression populaire en sortant Google App Engine pour Java en avril
2009.
Google App Engine pour Java est une solution complète pour le développement Java
d'entreprise: une IHM Ajax dans un navigateur pour la facilité d'utilisation, le support des
outils Eclipse, et Google App Engine en bout de chaine. La facilité d'utilisation et l'outillage
sont les points forts de Google App Engine pour Java par rapport à d'autres solutions de Cloud
computing. Le développement d'applications dans App Engine pour Java implique l'utilisation
des ressources de Google pour stocker et retrouver les objets Java. Le stockage des données
est basé sur BigTable, mais les intarfaces JDO et JPA permettent d'écrire du code qui n'est pas
directement lié à Big Table.
En fait, Google fournit un support pour bon nombre d'APIs standards afin que nous puissions
écrire du code qui n'est pas lié à 100% à la plateforme App Engine pour Java.
App Engine pour Java repose sur les APIs Java standards qui suivent:
 java.net.URL pour appeler des services
 JavaMail pour envoyer des courriers électroniques
 Une interface JCache (JSR 107) implémentée par Memcache pour fournir un stockage
temporaire à la fois rapide et distribué pour les requêtes et les calculs.

Pour rentrer un peu plus dans le détail du fonctionnement de Google App Engine,
commençons par savoir que Google propose plusieurs services Cloud :
 App Engine : le service PaaS de Google, la star de la maison.

 ComputeEngine : le service IaaS de Google. Si vous avez besoin de puissance
de calcul brute (pour calculer des modèles mathématiques par exemple), c’est ce qu’il
faut utiliser.
 Cloud Storage : un service potentiellement « illimité » de stockage de fichiers
dans le Cloud.
 BigQuery : des fonctionnalités permettant d’analyser de grosses quantités de
données en peu de temps (on parle de Big Data).
 Cloud SQL : une base de données MySQL distribuée dans le Cloud.
Figure 3 : Les services de Cloud de Google

Nous allons présenter un peu plus en détails Google appengine.
IV.1.Qu'est-ce que Google App Engine ?
Google App Engine permet d'exécuter nos applications web sur l'infrastructure de Google.
Les applications App Engine sont faciles à construire, faciles à maintenir, et supportent
facilement la montée en charge de notre trafic et de nos besoins croissants de stockage de
données. Avec App Engine, il n'y a pas de serveurs à maintenir: Nous chargeons juste nos
applications, et elles sont aussitôt disponibles pour nos utilisateurs.
IV.1.1. Le fonctionnement d’ App Engine

Le rôle d'App Engine est de "masquer" le fonctionnement et la complexité des serveurs de
Google. Lorsqu'un visiteur se connecte à notre site, il arrive sur le loadbalancer (répartiteur
de charge) de Google, qui va chercher un serveur disponible et pas trop chargé pour gérer la
demande de notre visiteur. Si notre site a besoin d'accéder à des données, ce qui est fréquent,

il fera appel à une autre zone de serveurs appelée DataStore (c'est en quelque sorte la base de
données).
Ceci est résumé dans ce schéma fourni par Google :
Figure 4 :Architecture de Google App Engine
IV.1.2. Les langages supportés par App Engine

Les plateformes PaaS comme Google App Engine supportent un nombre limité de langages
de programmation. En effet, elles fournissent des fonctionnalités supplémentaires sous la
forme de bibliothèques, il faut donc que Google ait développé les fonctionnalités
correspondantes pour ces langages.
Voici les 4 langages supportés par Google à l’heure actuelle (cette liste est susceptible
de s'agrandir à l'avenir) :
Java : Basés sur un site Java EE développé en Java.

Python : C’est un langage de programmationobjet, multi-paradigme et
multiplateformes.

Go : C’est un langage créé par Google assez spécifique et encore expérimental.
PHP 5.4
En réalité, tout langage pouvant utiliser la machine virtuelle Java peut aussi fonctionner : c’est
le cas de Ruby et de Scala par exemple. Dans la pratique, la plupart des gens utilisent soit
Java, soit Python.
IV.1.3. Les services de stocker des données App Engine

Le stockage de données est le point le plus important, le plus fondamental, le plus
cruciald'une application web.
App Engine nous offrent beaucoup d'autres services. Mais Notre site web ne sert à rien si
vous ne savons pas comment y stocker des données. Nous allons donc passer du temps à
découvrir les choix qu’App engine offre à nous, puis à apprendre à nous servir des différents
moyens de stockage à travers une architecture Cloud qui est une notion indispensable pour
comprendre ce service.
Les serveurs peuvent fournir différents services:
Le serveur web : c'est lui qui répond directement aux requêtes des clients et
qui exécute les instructions de la page en Java, Python, PHP... Son rôle et de renvoyer
une page HTML au client.
Le serveur de stockage de fichiers : il se contente de stocker des fichiers
statiques (donc pas de Java, Python ou PHP là). Ca concerne aussi bien les images de
notre site, les images uploadées par nos visiteurs, les fichiers CSS, les fichiers JS, etc.
Ces fichiers peuvent être efficacement servis via un CDN (un ensemble de serveurs
répartis sur la planète).
Le serveur de base de données : il enregistre les informations de façon
structurée. Il stocke la liste des membres, la liste des messages, la liste des commandes,
etc.
Ces serveurs peuvent être tous regroupés au sein d'une même machine physique. Une
seule machine peut en théorie faire toutes ces choses-là à la fois. C'est l'architecture
serveur la plus simple.

Figure 5 : Architecture complexe :Plusieurs serveurs dans le Cloud
App Engine nous fournit une flopée de services pour résoudre nos problèmes les plus
courants.
On pourrait distinguer deux types de besoins :
Stocker des informations : on a très régulièrement besoin d'enregistrer des

informations. Ca peut être le nom d'un nouveau membre, un message qu'il laisse, une
commande qu'il effectue sur le site.
Stocker des fichiers : on a parfois besoin de stocker de nouveaux fichiers, que
ce soient des images, des .zip, etc. Ces fichiers sont le plus souvent uploadés par les
utilisateurs du site web.
Pour répondre à ces besoins, Google App Engine fournit différents services :
Pour le stockage d'informations, on a en général besoin d'une base de

données. C'est en effet le moyen le plus sûr et le plus structuré pour "ranger" les
informations. Google App Engine propose 2 types de bases de données :

 Une base de données relationnelle SQL : c'est le service Google Cloud SQL. Il
s'agit en fait d'une base de données MySQL gérée en Cloud.
 Une base de données non relationnelle NoSQL : c'est le service Datastore. Il
est basé sur Big Table, le système de stockage créé par Google pour ses propres
services pour des besoins de performance.
Pour le stockage de fichiers, on utilisera le service Google Cloud Storage.
A noter qu'il existe aussi le Blobstore qui fait globalement la même chose mais avec moins de
fonctionnalités.
IV.1.3.1.Google Cloud SQL

Google Cloud SQL est donc un bon moyen pour nous de découvrir un service de stockage
Cloud sans être trop dépaysés.Google Cloud SQL a les caractéristiques suivant :
Les bases de données SQL sont en général connues des développeurs web,
Google Cloud SQL est en fait d'une base de données MySQL dans le Cloud. Si
nous avons un dump (une sauvegarde) d'une base MySQL, nous pouvons le stocker
dans Google Cloud SQL et commencer à l'utiliser tout de suite.
On peut aussi utiliser Google Cloud SQL de façon totalement indépendante. Si
nous avons "juste" besoin d'une base de données gérée dans le Cloud (pour ne pas avoir
à nous occuper de l'installation, de la configuration et de la maintenance), Google Cloud
SQL est la réponse que nous cherchons.
Google Cloud SQL ne peut pas être utilisé gratuitement même si on a un petit
trafic. Il faut payer pour pouvoir l'utiliser. Le prix dépend de la puissance nécessaire et
du temps que vous souhaitez l'utiliser
IV.1.3. 2. La base de données ("Datastore")

Le Datastore est la voie royale pour stocker des données sur Google App Engine. C'est
clairement l'outil que Google nous conseille d'utiliser. Vous pouvez vous en servir
gratuitement (jusqu'à une certaine limite de trafic) et on ne vous en dit que du bien : il serait
rapide, capable de gérer de fortes charges, réparti sur de multiples datacenters... On dit même
qu'il serait basé sur Big Table, la technologie qu'utilise Google pour stocker toutes ses
données, notamment les résultats d'indexation des milliards de pages web par le Google.

Le Datastore fonctionne en mode High ReplicationDatastore (HRD). Ce système est très

résilient aux erreurs : il fait en sorte que vos données soient copiées sur de multiples
datacenters ! L'objectif est que votre application puisse continuer à fonctionner même en cas
d'évènement catastrophique.
IV.1.3. 3. Google Cloud Storage

Nous avons vu de long en large le service stocker des données sur Google App Engine : via
Cloud SQL, dans le Datastore, Nous verrons maintenant le service de stockage des fichiers
sur le Cloud de Google.
Google Cloud Storage est une service Web en ligne de stockage de fichiers et l' accès aux
données sur l’infrastructure de google.Le service combine les performances et l'évolutivité du
Cloud de Google avec des capacités de sécurité et de partage avancés.Il est une infrastructure
en tant que service ( IaaS ), comparable à Amazon S3 service de stockage en ligne.
Notons qu’App Engine ne nous permet pas de stocker les données sur leurs serveurs web
pour une raison simple : ceux-ci ne communiquent pas entre eux et chaque serveur peut être
arrêté à tout instant.

Figure 6 : Serveurs frontaux App Engine

La solution passe par l'utilisation d'un service externe comme Google Cloud Storage qui est
fait pour stocker ces fichiers :

Figure7 : Serveurs spéciaux permettant a tout le monde de retrouver ses fichiers

Noter que Google propose 2 méthodes de stockage de fichiers :
Le Blobstore : c'est un système de stockage de fichiers intégré à App Engine.

Pratique et stable, il est intégré à notre application et rapidement utilisable, tout comme
le Datastore. Nous pourrons stocker des fichiers d'une taille de 2 Go chacun maximum.
Nous disposons de 5 Go de stockage gratuit avec notre application App Engine.
Google Cloud Storage : c'est un autre système de stockage de fichiers qui
utilise une autre architecture de serveurs. Il possède plus de barrières à l'entrée : il s'agit
d'un autre service qu'il faut activer (via API Console), il ne propose pas de stockage
gratuit et il est encore assez jeune.
Malgré ces éléments qui peuvent être rebutants au début, il possède de nombreux avantages :
 nous pourrons uploader de très gros fichiers (jusqu'à plusieurs To),

 gérer plus finement les droits d'accès
 et nous disposons d'une API REST complète pour l'utiliser depuis des
applications externes.
Google Cloud Storage est clairement la solution la plus complète. Elle constitue le futur du
stockage de fichiers pour les applications App Engine. Néanmoins, le Blobstore ne manque

pas d'intérêt lui aussi, parce qu'on peut l'utiliser gratuitement (jusqu'à une certaine limite) et
qu'il est plus simple à configurer au sein d'une application App Engine.
Nous présenterons donc les deux solutions, en commençant par le Blobstore qui nous
permettra de gérer nos premiers uploads rapidement.
IV.1.3. 3.a. Le Blobstorage

Le Blobstore est un système de stockage déjà intégré à notre application. De la même façon
que le Datastore stocke des données, le Blobstore stocke des fichiers.
Le principe du Blobstore et qu’on l’utilise en combinaison avec des formulaires d'upload de

fichiers. Dans ce cas, on crée un formulaire qu'on redirige vers une URL qui nous est fournie
par le Blobstore.
C'est le Blobstore qui récupère le formulaire et non notre application directement. Le

Blobstore se charge de stocker les fichiers soumis avec le formulaire.
Une fois qu'il a fini de stocker les fichiers uploadés par le visiteur, il renvoie le reste du
formulaire à votre application... sans les fichiers mais avec des informations sur
l'emplacement où les fichiers ont été sauvegardés. Notre application peut ensuite effectuer le
reste du traitement, comme sauvegarder les données du formulaire dans le Datastore.
Le schéma suivant nous résume cela.

Figure 8 : Le Blobstore stocke les fichiers transmis et renvoie le formulaire à traiter
IV.1.3. 3.b.Google Cloud Storage

Nous venons de voir comment utiliser le Blobstore, qui est un moyen pratique et rapide de
stocker des fichiers avec App Engine.
Nous allons nous 'intéresses maintenant à un autre service de stockage, Google Cloud
Storage, qui est plus récent et pluscomplet (mais aussi plus complexe à prendre en main).
Google Cloud Storage nous permet de stocker sur les serveurs de Google toutes sortes de
fichiers d'une taille pouvant allerjusqu'à plusieurs Teraoctets. Les fichiers peuvent être stockés
soit aux Etats-Unis soit en Europe, ce qui peut être pratique pouroptimiser les temps d'accès et
pour la confidentialité des données. Les fichiers sont eux-mêmes répartis sur plusieurs
datacenterspour éviter les pertes accidentelles de données.
Cloud Storage est un peu l'équivalent du service Amazon S3 chez Google.
Il y a 3 types d'éléments sur Cloud Storage :
Les projets : nous pouvons gérer plusieurs projets Cloud Storage. En général,
un projet correspond à un site web. On créeces projets dans l'API Console de Google.

Les buckets: chaque projet peut gérer plusieurs buckets, qui sont des espaces
de stockage différents. On peut les voircomme des dossiers mais les buckets ne peuvent
pas être imbriqués contrairement aux dossiers. Chaque bucket définitdes droits d'accès
différents.
Les objets : ce sont les fichiers et dossiers que vous stockez. Les fichiers
peuvent peser jusqu'à plusieurs Teraoctets. Unfichier se trouve dans un et un seul bucket
à la fois.
IV.1.4. Objectify
On vient de voir que le Datastore est un système puissant mais son API bas niveau est assez
délicate à utiliser, notamment son système de requêtes. De l'avis de plusieurs développeurs de
de Google, il estrecommandé d'utiliser la bibliothèque Objectify pour travailler avec le
Datastore aujourd'hui.
Contrairement au Datastore lui-même, la lib Objectify n'est pas maintenue par Google lui-
même mais par un développeur externe. Objectify est particulièrement suivi et maintenu, c'est
donc un excellent choix pour développer avec le Datastore.
Objectify se veut être une API "ni trop bas niveau, ni trop haut niveau". Elle est
(heureusement) plus haut niveau que l'API debase que nous venons de découvrir, mais elle ne
nous empêche pas d'effectuer des actions basiques si nécessaire.
Objectify est un peu comme un ORM pour le Datastore : son rôle est de persister (stocker) nos
objets dans le Datastore.
Figure 9 : Objectify permet de stocker des objets dans le Datastore et de les ressortir
Objectify s'occupe de la création d'entités et de clés et de la relation entre ces éléments.

Mieux : il utilise automatiquement leservice Memcache de Google qui permet de mettre en

cache des données pour aller encore plus vite et nous éviter d'appelersystématiquement le
Datastore.
IV.1.5.Les services de googleappengine
IV.1.5.1.Google Accounts API : authentification des visiteurs

Les services d'App Enginene se limitent pas au stockage, on peut aussi télécharger des
fichiers, manipuler desimages, planifier des tâches, générer des APIs... et authentifier nos
utilisateurs facilement.
Google App Engine nous permet en un rien d'effort de créer une section membres sur notre
site. Nos membres pourront seconnecter avec leur compte Google ou même avec un OpenID,
et nous n'avons presque rien à coder pour ça.
IV.1.5.2. Google Accounts API : authentification des visiteurs

Parmi les services fournis par App Engine, l'un d'eux devrait éveiller notre intérêt : la Mail
API. Ce service permet :
D'envoyer des e-mails : notre application peut envoyer des e-mails en bénéficiant de
l'architecture de serveurs mail deGoogle (la même que GMail !).
De recevoir des e-mails : notre application peut recevoir et traiter automatiquement
des e-mails qu'on lui envoie.
Les deux fonctionnalités sont réellement puissantes et nous permettent d'imaginer de

nouvelles interactions avec nos visiteurs.

Conclusion
Apres avoir vu les différentes solutions existantes du PaaS, nous avons choies la plateforme
de Google qui est une plateforme performante et nous avons fait une présentation détaillée de
cette dernière, nous avons une vue générale de ce que propose l'App Engine pour Java et nous
avons vu aussi les différentes services de stockage offert par googleappengine.
Dans le chapitre suivant,nous allons explorer les possibilités offertes aux développeurs Java
qui travaillent sur l'App Engine, pour mettre en application toutes ces connaissances que nous
avons apprises sur appengine, nous allons mettre en place deux applications à base d’app
engine. La première application permet a des utilisateurs de poster des message en ligne sur
un forum de discussion et une seconde application Ecommerce de vente en ligne qui permet
a des utilisateur d’effectuer des achat en ligne.

Chapitre 3 : Implémentation de la solution

Introduction
Dans ce chapitre, nous commencerons la plateforme assez excitante pour développer en Java:
Google App Engine pour Java, en exploitantles différents types de services applicatifs qu'il
propose en utilisant le plugin Eclipse fourni par Google, nous créerons une application de
gestion de message sur un forum et une seconde application Ecommerce de vente en ligne
qui permet a des utilisateur d’effectuer des achat en ligneen utilisant ces technologies.
I. Installation de Google App Engine avec Eclipse
Google nous fournit tous les outils dont nous avons besoin pour développer. Ces outils varient
en fonction du langage que nous utilisons : Java, Python ou GO. La plupart des développeurs
Java utilisent un IDE comme Eclipse. Google y a pensé et nous fournit un kit de
développement App Engine sous la forme d'un plugin Eclipse.
I.1. Installation d’eclipse
La version la plus téléchargée est "Eclipse for Java EE developers", c'est celle qui convient le
mieux dans notre cas. Lors du premier lancement, Eclipse nous demande de choisir un
"workspace", un dossier dans lequel il déposera nos projetsde développement Java. nous
pouvez laisser la valeur proposée par défaut et continuer.
I.2. Installation du plugin Google App Engine
Installer le plugin Google App Engine dans Eclipse est vraiment très simple. Nous allons dans
le menu Help > Install New Software. Une fenêtre apparaît, où l'on nous demande où trouver
de nouveaux plugins.
Avez la version4.2 d'Eclipse on entre d’adresse suivante:
http://dl.google.com/eclipse/plugin/4.2
Appuyons sur Entrée. La liste des plugins disponibles se charge, et on coche ceux-ci :
 Google Plugin for Eclipse

 SDK > Google App Engine Java SDK
 SDK > Google Web Toolkit SDK (facultatif)

Figure 10 : Sélection des plugins à installer
Nous pouvons installer d'autres plugins si nous le voulons mais ça ne nous sera pas nécessaire
dans ce projet. Cliquons ensuite sur Next.

Figure 11 : Validation des éléments à installer
On nous demande de vérifier ce que nous allons installer. Cliquons encore sur Next.

Figure 12 : Validation de la licence
Nous devons valider la licence d'utilisation. Cliquons sur "I accept the terms of the license
agreements" et cotunions.
L'installation commence.
Au bout d'un moment, nous verrons le message suivant :

Figure 13 : Validation de la signature
Eclipse avertit qu'il y a du contenu non signé (qui pourrait ne pas provenir de Google) dans
ce que noustéléchargeons. En réalité il n'y a pas de problème, cliquons sur OK pour continuer
l'installation.
A la fin, on nous demandera de redémarrer Eclipse pour finaliser l'installation :
Figure 14 : Redémarrage d'Eclipse
Une fois Eclipse redémarré, c'est fini ! Si nous lançons un nouveau projet ou que nous
fermons simplement l'écran de bienvenue, nous devrions voir une icône Google (représentée
par un "g") qui nous donne accès aux fonctionnalités de Google App Engine que nous avons
installé :

Figure 15 : Le menu Google dans Eclipse
II. Mise en place du projet
La création du projet se fait en deux etapes :
 Créationd’un nouveau projet en cliquant sur le New Web Application (bouton dans la
barre d'outils:
 Attribution du nom au projet le nom furumappet dans un package furumapp.

Décochons la case "Using Google Web Toolkit" et assurons-nous que "User Google App
Engine" est cochée.

Figure 16 : Démarrage d'un nouveau projet
II.1. LA Classe FurumappServlet
Java App Engine utilise l'API Java Servlet pour interagir avec le serveur web. Une servlet
HTTP est une classe d'application qui peut traiter et répondre à des requêtes Web. Cette classe
doit hériter soit de la classe javax.servlet.GenericServlet soit de la classe
javax.servlet.http.HttpServlet.
Notre projet commence avec une classe servlet simple qui affiche un message.

Dans le répertoire src du projet, le plugin a crée un fichier nommé FurumappServlet.java de

contenu suivant :
Figure 17 : La classe FurumappServlet
II.2.LE Fichier WEB.XML
Lorsque le serveur Web reçoit une requête, il détermine la classe servlet à appeler en utilisant
un fichier de configuration appelé «descripteur de déploiement d'application web ». Ce fichier
est nommé web.xml réside dans le war/WEB-INF/ WEB-INF / et web.xml font partie de la
spécification des servlets.

Figure 18 : Le Fichier Web.XML
Le fichier déclare une servlet nommée Furumapp, et lui associe un chemin d’url /Furumapp.
web.xml donne le chemin à l’intérieur de l’application WAR d’un fichier htlm (ici
index.html) qui sera utilisé par le serveur chaque fois que l'utilisateur récupère une URL qui
n'est pas déjà associé à une servlet.

Figure 19 : Le projet Furumapp
II.3.Le fichier APPENGINE-WEB.XML
App Engine a besoin d'un fichier de configuration supplémentaires pour trouver la façon de
déployer et d'exécuter l'application. Ce fichier est nommé appengine-web.xml réside dans
WEB-INF/ à côté de web.xml. Il inclut un identificateur (l'ID de application), le numéro de
version de notre application, et des listes de fichiers qui doivent être traités comme des
fichiers statiques (tels que des images et des feuilles de style CSS) et les fichiers de ressources
(telles que les JSP et autres données d'application). Eclipse crée une zone vide, à nous de la
remplir plus tard,appengine-web.xml est spécifique à App Engine et ne fait pas partie de la
norme servlet. Les schémas XML décrivant le format de ce fichier est dans le répertoire du
sdk App Engineappengine-java-sdk/docs.
Figure 20 : Fichier APPENGINE-WEB.XML
II.4.Exécution du projet

Le SDK App Engine inclut un serveur Web de développement utilisé pour tester votre
application. Le serveur simule l'environnement App Engine et les services correspondants, y
compris les restrictions du bac à sable (sandbox), le stockage des données, et les services.
Pour démarrer le serveur de développement dans le débogueur Eclipse sélectionner le projet

Furumapp, puis clic droit et choisir Run As> Web Application et exécutons puis démarrons
le serveur.
Pour lancer :
 le fichier index.htlm, entrer l'url suivante dans votre navigateur

:http://localhost:50799/.
 directement la servlet, entrer l’url dans notre navigateur : http://localhost:50799/.
Figure 21 : Aperçu de la page web
III. Utilisation du service Users
Google App Engine fournit de nombreux services très utiles basés sur l'infrastructure Google
et accessibles aux applications utilisant les bibliothèques du kit de développement de logiciels
(SDK). Parmi eux, le service Users permet d'intégrer les comptes d'utilisateurs Google à notre
application. Avec le service Users, les internautes peuvent se connecter à notre application à
l'aide d'un compte Google existant.
Nous allons maintenant faire appel au service Users pour personnaliser le message de
bienvenue de cette application.
III.1.Mise en œuvre du service Users

Modifions le fichier src/furmapp/FrumappServlet.java, comme suit :
Figure 22 : Aperçu après modification
Lorsque nous enregistrons nos modifications dans ce fichier, Eclipse compile

automatiquement le nouveau code puis il tente de l'insérer dans le serveur en cours
d'exécution.
Toutes les modifications apportées aux classes, aux pages JSP, aux fichiers statiques et au
fichier appengine-web.xml sont immédiatement prises en compte sans avoir besoin de
redémarrer le serveur en cours d'exécution.
III.2. Test de connexion de l’utilisateur
Maintenant recompilons notre projet et redémarrons le serveur, si nécessaire. Testons

l'application en tapant l'URL de servlet suivante dans notre navigateur :
http://localhost:8888

Au lieu d'afficher le message, le serveur nous invite à saisir une adresse e-mail. Entrons une
adresse e-mail (par exemple, sayoudi@example.com), puis cliquons sur "Log In"
(Connexion). L'application affiche un message, avec l'adresse e-mail que nous avons saisie.
Le nouveau code de la classe FrumappServlet utilise l'API Users pour vérifier que l'utilisateur
est connecté à un compte Google. Si ce n'est pas le cas, l'utilisateur est redirigé vers la page de
connexion de Google Accounts. userService.createLoginURL(...) renvoie l'URL de l'écran de
connexion. Le système de connexion redirige l'utilisateur vers l'application à l'aide de l'URL
transmise à createLoginURL(...), qui correspond dans notre cas à l'URL de la page en cours.
Lorsque nous exécutons l'application sur App Engine, nous sommes redirigés vers l'écran de
Google Accounts.
Nous sommes maintenant connectés à notre application de test. Si nous rechargeons la page,
le message s'affiche de nouveau.
Pour permettre à l'utilisateur de se déconnecter, nous devons fournir un lien vers l'écran de
déconnexion, généré par la méthode createLogoutURL(), ce lien déconnectera l'utilisateur de
l'ensemble des services Google.

Figure 23 : Aperçu de la page de connexion
IV. Utilisation des JSP
Bien qu'il soit possible de générer une sortie HTML pour l'interface utilisateur directement à
partir du code de servlet Java, cela serait trop difficile et compliqué. À la place, nous allons
utiliser un modèle, avec l'interface utilisateur conçue et implémentée dans des fichiers séparés
avec une logique et des emplacements réservés pour insérer les données fournies par
l'application. Un grand nombre de modèles disponibles sous Java sont compatibles avec App
Engine.
Nous utiliserons les pages JavaServer (JSP) pour implémenter l'interface utilisateur du furum
de discutions.
Notre application écrit les chaînes dans un flux de sortie standard, mais elles pourraient
également être écrites en tant que page JSP. Commençons par adapter la dernière version de
l'exemple à JSP.
Dans le répertoire war/, créons un fichier appelé furumapp.jsp avec les éléments suivants :

Figure 24 : Aperçu de la page furumaap.jsp
Dans le cadre de notre furum de discussion, nous voulons que cette page soit la page d'accueil
qui s'affiche lorsqu'un utilisateur accède à l'URL /. La méthode la plus simple consiste à
déclarer dans web.xml que furmapp.jsp est le servlet de "bienvenue" associé à ce chemin.
Modifions le fichier war/WEB-INF/web.xml et remplaçons l'élément <welcome-file> actuel

dans la liste <welcome-file-list>. Supprimons index.html de la liste, compte tenu que les
fichiers statiques sont prioritaires sur les servlets et les pages JSP.
<welcome-file-list>
<welcome-file>furumapp.jsp</welcome-file>
</welcome-file-list>
Arrêtons, puis redémarrons le serveur de développement. L'application affiche le contenu du

fichier furumapp.jsp, notamment le pseudonyme de l'utilisateur si ce dernier est connecté.
Figure 25 : Aperçu de la page web après déclaration du chemin
Notre furum nécessite maintenant un formulaire Web pour que les utilisateurs puissent poster
un nouveau message, ainsi qu'une méthode de traitement de ce formulaire. Le contenu HTML
du formulaire sera transmis à la page JSP. La destination du formulaire sera une nouvelle
URL, /sign, traitée par une nouvelle classe de servlet, SignfurumappServlet.
SignfurumappServlet traitera le formulaire, puis redirigera le navigateur de l'utilisateur vers
/furumapp.jsp. Pour le moment, le nouveau servlet consignera simplement le message posté
dans le fichier journal.

Modifions le fichier furumapp.jspet insérons les lignes suivantes juste avant la balise </body>
fermante :
<form action="/sign" method="post">
<div><textarea name="content" rows="3" cols="60"></textarea></div>
<div><input type="submit" value="Post Greeting" /></div>
</form>
</body>
</html>
Créons une classe nommée SignfurumappServlet dans le package furumapp. Insérons les
éléments suivants dans le fichier source :

Figure 26 : Aperçu de la classe SignfurumappServlet
Ensuite on modifie le fichier war/WEB-INF/web.xml et on ajoute les lignes suivantes pour

déclarer le servlet SignfrumappServlet, puis mappons-le sur l'URL /sign :
<web-app xmlns="http://java.sun.com/xml/ns/javaee" version="2.5">
<servlet><servlet-name>sign</servlet-name>
<servlet-class>furumapp.SignfurumappServlet</servlet-class>
</servlet><servlet-mapping><servlet-name>sign</servlet-name>
<url-pattern>/sign</url-pattern>
</servlet-mapping>
... </web-app>
Ce nouveau servlet se sert de la classe java.util.logging.Logger pour écrire les messages dans
le journal.
Nous avons créé une interface qui permet aux utilisateurs d'entrer des messages de bienvenue.
V. Déclaration de l'application auprès de Google
Nous créons et nous gérons des applications dans App Engine via la console d'administration.
Une fois l'identifiant de notre application enregistrée, utilisons-le pour transférer notre
application vers App Engine à l'aide du plug-in Eclipse ou d'un outil de ligne de commande
livré avec le kit de développement de logiciels (SDK).
V.1.Enregistrement de l'application
Pour créer et gérer des applications Web App Engine, servons-nous de la console
d'administration App Engine qui est accessible à l'adresse suivante :
https://appengine.google.com/

Figure 27 : Console d'administration App Engine
Connectons-nous à App Engine à l'aide de notre compte Google. Si nous n'en possédons pas,
nous pouvons créer un compte Google avec une adresse e-mail et un mot de passe.
Pour créer une application, cliquons sur le bouton "Create an Application" (Créer une
application). Suivons les instructions pour enregistrer un identifiant d'application, le nom
unique de l'application concernée. Si nous optons pour le nom de domaine gratuit
appspot.com, l'URL complète de notre application sera http://application-id.appspot.com/.
Nous pouvons également acheter un nom de domaine de premier niveau pour notre
application ou en utiliser un que nous avons déjà enregistré.
Dans le fichier appengine-web.xml, remplacons la valeur de l'élément <application> par

l'identifiant d'application que nous avons enregistré.
V.2. Transfert de l'application
Nous pouvons transférer votre application à l'aide d'Eclipse ou d'une invite de commande.
Nous pouvons transférer nos fichiers et notre code d'application à partir d'Eclipse via le plug-
in Google.
Pour transférer notre application depuis Eclipse, cliquons sur le bouton de déploiement App
Engine situé sur la barre d'outils :

Identifions-nous à l'aide du nom d'utilisateur (adresse e-mail) et du mot de passe de notre

compte Google, puis cliquons sur le bouton Transférer. Eclipse extrait l'identifiant
d'application et les informations de version à partir du fichier appengine-web.xml, puis
transfère le contenu du répertoire war/. Nous pouvons maintenant voir notre application en
cours d'exécution sur App Engine. Si nous avez configuré un nom de domaine appspot.com
gratuit, l'URL de notre site Web commence par l'identifiant de notre application :
http://application-id.appspot.com/.
VI. Manipulation du DataStore avec Objectify
VI. 1. Configuration d’Objectify
Objectify est une bibliothèque créée par un développeur tiers. Elle n'est pas installée
automatiquement avec le plugin AppEngine pour Eclipse. Heureusement, son installation et sa
configuration sont simples.
Le projet Objectify est hébergé sur Google Code à l'adresse suivante :

https://code.google.com/p/objectify-appengine/
Pour utiliser Objectify, on doit télécharger 2 bibliothèques sous la forme de fichiers .jar :
Objectify: on peut télécharger Objectify sur Maven Central.
Prenons le fichier .jar correspondant à la dernière version (par exemple 5.1.12/objectify-
5.1.12.jar)
Guava: c'est une bibliothèque offrant des fonctionnalités de base de Java, créée par
Google et utilisée notamment parObjectify. Nous en aurons besoin pour faire fonctionner
Objectify. Nous pouvons télécharger le .jar sur le site de Guava.
Placons ces fichiers dans le dossier WEB-INF/lib de notre projet.

Figure 28 : Arborescence des fichiers du dossier lib
VI. 2.Objectify dans notre applicationfurumapp
Reprenons notre application furumapp qui permet aux utilisateurs de poster des messages sur
le furum et d’uploader et poster des images public et de l'adapter à Objectify.
Le tableau ci dessous nous résume un peu comment doit ressemble notre projet en donnant
un résumé de nos fichiers et leurs descriptions :
Tableau n°2 : Les fichiers d’arborescence et leurs descriptions

Fichier La description
Utilisé pour spécifier l'ID de projet cette

application est déployée, la version de l'
application, et l'emplacement du
appengine-web.xml logging.properties fichier utilisé pour l'
enregistrement de l' application.

logging.properties Utilisé pour définir le niveau de journal par

défaut ( Error , Warning , Info , et ainsi de
suite).
web.xml Est-ce que toutes les correspondances

nécessaires à la servlet.
Message.java Définit l'entité qui est affiché par l'utilisateur,

enregistré dans Google Cloud Datastore, et
affiché sur le babillard.
OfyHelper.java Un auditeur qui enregistre le service

Objectify avec le servlet
SignfurumappServlet.java .
SignfurumappServlet.java Le servlet qui gère la demande de l'utilisateur

à POST un message à la carte de message et
enregistre le message.
furumapp.java Enregistre le Message entité avec Objectify.
Les classes de modèle de données
Voila noter digramme de classe :
Figure 29 : Diagramme de classe du projet
Commençons par définir la classe Message qui doit nous servir de model. Elle représentera
les objets que nous allons persister dans le Datastore.
La classe doit définir la structure de nos objets persistables. On doit y écrire des annotations
qui indiquent à Objectify où est l'ID et les champs qui doivent être indexer.

Le code suivant montre la classe Message représentant un message posté par l'utilisateur:
importcom.googlecode.objectify.Key;
importcom.googlecode.objectify.annotation.Entity;
importcom.googlecode.objectify.annotation.Id;
importcom.googlecode.objectify.annotation.Index;
importcom.googlecode.objectify.annotation.Parent;
importjava.lang.String;
importjava.util.Date;
importjava.util.List;
@Entity
publicclass Message {
@Parent Key<Furumapp>lefurum;
@Idpublic Long id;
public String auteur_email;
public String auteur_id;
public String contenu;
@Indexpublic Date date;
public Message() {
date = new Date();

public Message(String furum, String contenu) {
this();
if( furum != null ) {
lefurum = Key.create(Furumapp.class, furum);
} else {
lefurum = Key.create(Furumapp.class, "default");
this.contenu = contenu;
public Message(String furum, String contenu, String id, String email) {
this(furum, contenu);
auteur_email = email;
auteur_id = id;
L'exemple utilise également la classe de modèle Furumapp.java pour représenter tout le

furum:
import com.googlecode.objectify.annotation.Entity;
import com.googlecode.objectify.annotation.Id;

@Entity
public class Furumapp {
@Id public Stringfurum;
Le fichier d'aide OfyHelper.java
Pour utiliser Objectify dans une JSP, nous avons besoin d'une classe d'aide qui enregistre
chaque classe de modèle dans le contexte de servlet JSP. Le code suivant dans OfyHelper.java
montre comment faire:
packagefurumapp;
importcom.googlecode.objectify.Objectify;
importcom.googlecode.objectify.ObjectifyFactory;
importcom.googlecode.objectify.ObjectifyService;
importjavax.servlet.ServletContextListener;
importjavax.servlet.ServletContextEvent;
publicclassOfyHelperimplementsServletContextListener {
publicvoidcontextInitialized(ServletContextEventevent) {
ObjectifyService.register(Furumapp.class);
ObjectifyService.register(Message.class);

publicvoidcontextDestroyed(ServletContextEventevent) {
Ce fichier fait référence aux Message des classes modèles utilisés dans l'échantillon.
Le fichier web.xml :
Le fichier web.xml qui doit comporter les lignes spécifiques à Objectify pour que notre
application puisse fonctionner correctement :
<filter>
<filter-name>ObjectifyFilter</filter-name>
<filter-class>com.googlecode.objectify.ObjectifyFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>ObjectifyFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<listener>
<listener-class>furumapp.OfyHelper</listener-class>
</listener>
N'oublions pasla JSP qui récupère simplement une liste de messages et fait une boucle pour
les afficher, rien de bien particulier.

Les importations suivantes dans le fichier JSP montrent les classes du modèle Cloud
Datastore et les classes objectiver requises:
<%@page import="furumapp.Message" %>

<%@ page import=" furumapp.Furumapp" %>
<%@ page import="com.googlecode.objectify.Key" %>
<%@ page import="com.googlecode.objectify.ObjectifyService" %>
Juste au- dessus de la ligne <form action="/furumapp.jsp" method="get"> , notons le code

suivant:

<%
// Create the correct Ancestor key
Key<Furumapp>theBook = Key.create(Furumapp.class, furumappName);
// Run an ancestor query to ensure we see the most up-to-date
// view of the Greetings belonging to the selected Guestbook.
List<Message> messages = ObjectifyService.ofy()
.load()
.type(Message.class) // We want only Greetings
.ancestor(theBook) // Anyone in this book
.order("-date") // Most recent first - date is indexed.
.limit(5) // Only show 5 of them.
.list();
if (messages.isEmpty()) {
%>
<p>Lefurum n'a pas de message.</p>
<%
} else {
%>
<p>Messages danslefurumdediscution .</p>
<%
// Look at all of our greetings
for (Message message : messages) {
pageContext.setAttribute("message_contenu", message.contenu);
String auteur;
if (message.auteur_email == null) {
auteur = "Une personne anonyme";
} else {
auteur = message.auteur_email;
String auteur_id = message.auteur_id;
if (user != null&&user.getUserId().equals(auteur_id)) {
auteur += " (Vous)";
}
}
pageContext.setAttribute("message_user", auteur);
%>
<p><b>${fn:escapeXml(message_user)}</b> a ecrit:</p>
<blockquote>${fn:escapeXml(message_contenu)}</blockquote>
<%
}
}
%>
<formaction="/sign"method="post">
<div><textareaname="content"rows="3"cols="60"></textarea></div>
<div><inputtype="submit"value="Poster le message"/></div>
<inputtype="hidden"name="furumappName"value="${fn:escapeXml(furumappName)}"/>
</form>

Lorsque l'utilisateur charge la page, le modèle effectue une requête dans le datastore pour tous
les Message des entités qui utilisent le même Furumaap dans leur clé. La requête est triée par
date dans l'ordre chronologique inverse, et les résultats sont limités aux cinq salutations les
plus récentes.
Le reste du modèle affiche les résultats sous forme de HTML, et rend aussi la forme que
l'utilisateur peut utiliser pour poster un nouveau message d'accueil.
Le SignfurumappServlet.java :
Le SignfurumappServlet servlet est le POST gestionnaire pour les salutations postées par les
utilisateurs. Il prend le message d’accueil de la demande et le stocke dans Cloud Datastore
entrant comme un entité:


packagefurumapp;
importcom.google.appengine.api.datastore.*;
importcom.google.appengine.api.users.User;
importcom.google.appengine.api.users.UserService;
importcom.google.appengine.api.users.UserServiceFactory;
importjava.io.IOException;
importjava.util.Date;
importjavax.servlet.http.*;
importcom.googlecode.objectify.ObjectifyService;
@SuppressWarnings("serial")
public class SignfurumappServlet extends HttpServlet {
// Process the http POST of the form
@Override
public void doPost(HttpServletRequestreq, HttpServletResponseresp) throws IOException {
Message message
UserServiceuserService = UserServiceFactory.getUserService();
User user = userService.getCurrentUser(); // Find out who the user is.
String furumappName = req.getParameter("furumappName");
String contenu = req.getParameter("contenu");
if (user != null) {
message = new Message(furumappName, contenu, user.getUserId(), user.getEmail());
} else {
message = new Message(furumappName, contenu);
ObjectifyService.ofy().save().entity(message).now();
resp.sendRedirect("/furumapp.jsp?furumappName=" + furumappName);
} en place d’une solution Cloud (SaaS)

Mise Page 71
Notons que les propriétés des magasins de servlet tels que le contenu du message, la date a la
quelle il a été poste, ID et l'adresse électronique de l'utilisateur serons enregistre si l'utilisateur
est connecté.
Prenons l’exemple d’un utilisateur sayoudi qui va se connecter et poster un message
Figure 30 : Aperçu de la page d’accueil du furum

Figure 31: Console d’administration

On voit que l’utilisateur sayoudi a poste avec son auteur_id et l’adresse sayoudi@test.coma
poster un message dont le contenu est : salut je suis votre freresayoudi à la date du
10/may/2016 a 20 :09 :19.
VI. 3. Déploiement de l'application
Dans cette dernière partie, nous déployer notre application, y compris la génération des index
Google Cloud Datastore requis pour le déploiement.
Génération d'index :
<datastore-indexes>
<datastore-indexkind="Message"ancestor="true"source="manual">
<propertyname="date"direction="desc"/>
</datastore-index>
Lorsque nous exécutons notre application sur le serveur de développement, le serveur de

développement crée automatiquement des index Cloud Datastore nécessaires à l'exécution de
l’application.On ouvre le fichier furumapp/War/WEB-INF/appengine-generated/datastore-
indexes-auto.xml et on insere le texte suivant:

En règle générale, nous devons changer la source="auto" pour source="manual" .
Déploiement de votre application :
Pour déployer notre application depuis Eclipse, cliquons sur le bouton de déploiement App
Engine situé sur la barre d'outils :
Figure 31: Propriétés du projet Google App Engine

Figure 32: Validation avant déploiement
Cliquons tout simplement sur "Deploy" : Notre site part alors sur les serveurs de Google.

Conclusion
Dans ce chapitre nous avons appris de façoncomplète comment installer le plugin Google App
Engine pour Java et nous avons appris la façon de créer une application a base des servlet en
utilisant ce plugin Eclipse pour l'App Engine et comment déployer notre application sur les
serveurs de google.
Nous avons vu de long en large qu’est que le datastore ainsi qu’ojectify, les différentservices
offert par Google appengine, comment authentifier nos utilisateurs en local et comment nous
pouvions stocker des données sur Google App Enginedans leDatastore, dans le Datastore via
Objectify.
Cela nous a permis d’implémenter une application a base des servlet qui permet a des
utilisateurs de poster des messages sur un furum de discussion.
Nous verrons dans le chapitre suivant comment fonctionne cette application de façon
persistante.

Chapitre 4 : Mise en œuvre de la solution implémentée

Introduction
Ce chapitre nous présente les possibilités d'utilisation d’application furumapp à
La page d'accueil de l’application est consultable en local a travers l'URL

http://localhost:8888. Elle permet aussi aux administrateurs d'accéder à la console
d’administration a travers l'URLhttp://localhost:8888/_ah/admin.
Elle permet aux usagers de se connecter, de se déconnecter a travers une interface

d’authentification, d’envoyer des messages sur le furum de discussion.
Elle est consultable en ligne à partir de l'URL http://furumapp.appspot.com.
I. Exécution de l’application en local

Pour tester notre site, il suffit qu’on clique sur le bouton "Debug" (ou "Run") de la barre
d'outils, et de sélectionner : "Debug as" >"Web Application" :
Figure 33: Exécution de l'application depuis Eclipse

La console en bas d'Eclipse nous affiche des messages pendant quelques secondes avant
d'indiquer : "INFO: Dev App Serverisnow running ". Cela signifie que le mini-serveur Google
tourne maintenant sur notre machine et que nous pouvons tester notre application et nous
indique aussi à quelle adresse locale nous pouvons tester notre application:


Allons donc à l'adresse http://localhost:8888 dans notre navigateur, nous devrions voir la page
d'accueil s'afficheé :
Il faut aussi savoir que Google nous génère automatiquement une administration pour
contrôler et surveiller notre application. Nous pouvons yaccéder en allant à l'adresse
http://localhost:8888/_ah/admin :

Figure 36:Administration automatiquement générée par Google pour gérer notre

application
II. Authentification des utilisateurs

Nous allons authentifier nos utilisateurs par Google Accounts qui est le service par defaut,
elle permet à toute personne possédant uncompte Google de se connecter facilement à notre
application.
Donc nous pouvons autoriser toute personne possédant un compte Google à se connecter à
notre application. Les comptes Google sont généralement des adresses e-mail @gmail.com
mais il peut parfois s'agir d'autres emails dans certains cas.
Si nous testons cette l’application en local, nous verrons que le serveur "simule" une mini-
page de connexion qui ressemble à ceci :
Figure 38:La fausse page de connexion en local

Nous pouvons rentrer n'importe quelle adresse, nous serons immédiatement connectés.
Figure 38:Connexion en local avec n’importe quelle adresse
Figure 39:Connexion d’aljazira a l’application

Pour se déconnecter il suffit tout simplement de cliquer sur déconnecter nous serrons
automatiquement déconnecter de l’application.
Figure 40:Déconnexion d’aljazira a l’application

On voit bien qu’on pouvait se connecter et déconnecter a l’application en local sans difficulté
avec m’importe quel compte.
Bien sûr, une fois notre application en ligne, nos utilisateurs passeront par le vrai processus de
connexion d'un compte Google :

Figure 41: La vraie page de connexion une fois l'application en ligne
III. Envoi des messages sur le furum

Nous allons toujours simuler avec l’utilisateur aljazira qui est déjà connecté donc il peut
envoyer des messages sur le furum de discution :
Figure 42: Ecriture de message par aljezira

On voit qu’il est connecter et qu’il est entrant d’ecrire un message, une fois qu’il poster le
message il sera affiche en haut du furum, car chaque fois utilisateur envoi un message, le
message sera afficher en haut.
Figure 43: Ecriture de message par aljezira
On voit apparu en haut le message poster par aljazira qui : salut je suis aljazira.
Sachez bien que n’importe quel utilisateur peut poster de message sans pour avoir
s’authentifier, dans ce cas il ne sera pas identifier dans le furum on verra seulement qu’une
personne anonyme aposter un message.

Simulons toujours cela avec l’utilisateur aljazira lorsqu’il vase déconnecter et poster de
message.
Figure 44: Déconnexion d’aljezira

On voit que personne n’est connecte, essayons de poster un message.

Figure 45: Ecriture de message par une personne anonyme

On voit qu’une personne anonyme est entrant d’écrire un message sur le furum
Essayons de voir lorsqu’il va poster le message :

Figure 46: Le message poste par une personne anonyme
On voit qu’une personne anonyme aposter un message qui est : salut je ne suis pas authentifie.

IV. Console d‘administration

C’est la console a travers la quelle d’administrateur peut accéder est administrer l’application
Il peut accéder travers l'URL http://localhost:8888/_ah/admin.
Elle permet a l’administrateur de faire plusieurs taches, de savoir qui est qui on poste de
message sur le furum, le cotenu et la date ala quelle le message est poste,atravers la base des
données datastore.
Simulons toujours cela et de voir le message poste par aljazira.
Accedons a la console a travers l'URL http://localhost:8888/_ah/admin.
Figure 47: Console d’administration

On voit le message poster par aljazira : son id, le contenu du message ainsi que la date a
laquelle le message et poster.
Noter bien que l’administrateur peut gérer plusieurs taches à travers cette console.

Conclusion
Cette partie de mise en n’œuvre de la solution implémentée met en évidence toutes les
compétences que nous acquises tous au longues de ce travail a fin de comprendre le
fonctionnement de façon explicite de notre application en simule quelque services et certaines
fonctionnement que nous offre app engine pour pouvoir manœuvrer notre application, pour
pouvoir tester la connexion en et authentifier nos utilisateurs en local.

Conclusion générale et perspectives
Conclusion générale et perspective

Face au phénomène médiatique que représente le Cloud Computing actuellement, nous avons
ici effectué une définition pragmatique de cette technologie à partir de la littérature d'experts
en système d'information et en Cloud. Cette technologie en plein essor permet aux entreprises
de disposer d'infrastructures et de progiciels directement en ligne sur Internet. On a distingué
les différents types de Cloud possibles avec l'IAAS pour les infrastructures techniques, le
PAAS pour les infrastructures habillées avec des outils de middleware comme les bases de
données par exemple et le SAAS pour les services logiciels.
Ces trois types peuvent se déployer sous quatre formes de topologies différentes : le Cloud
public pour du déporté en ligne, le Cloud privé pour l'utilisation des concepts du Cloud en
interne à l'organisation, le Cloud hybride pour l'utilisation commune du public et du privé et
enfin le mode communautaire pour des entreprises géographiquement proches ou à intérêts
communs.
Le premier chapitre du document nous a permis de comprendre de façon détaille le Cloud,

son historique, ces différents services, ces model, la sécurité au tous du Cloud et ces acteurs.
Le second chapitre a consisté en la mise en place d’une solution Cloud en mode SaaS ce qui
nous permis des faire une étude détaillée des différentes plateformes du PaaS existantes ce a
mené notre choix au niveau de la plateforme de Google qui est appengine dont nous avons
aussi étudié en détaille au cours du troisième chapitre pour pouvoir mettre en place une
application de discussion que nous avons mis en pratique au cours du dernier chapitre.
Notons bien que le thème de «Mise en place d’une solution Cloud (SaaS)» sera si Dieu le
veut d'un apport considérable pour nous car nous ayant permis d'apprendre beaucoup, àtravers
les nombreuses recherches et les pratiques quotidiennes sur le Cloud.
La réalisation de ce projet va sans aucun doute faciliter la communication et le partage de

l'information entre les étudiants et les enseignants d’une part, et d’autre part entre
l’administration et les enseignants. Nous espérons que le présent document sera d'un apport
particulièrement notable dans ce processus.
Notez bien que dans le but d’accroitre nos connaissance sur le domaine et faciliter la tache
aux consommateurs, ns perspectives sera de mettre en place une application E-Commerce qui

va permettre aux utilisateurs d’effectuer des commandes en lignes des produits que nous
allons mettre a leurs dispositions si Dieu le veut.

WEBOGRAPHIE/BIBLIOGRAPHIE
Sites web visités :
- http://www.openclassrooms.com pages vues le 30/03/2016
- http://www.eclipse.org/downloads/ pages vues le 05/03/2016
- http://www.oracle.com/technetwork/java/javase/downloads/index.html pages vues le

07/04/2016
- https://developers.google.com/eclipse/docs/download_older pages vues le 08/03/2016
- http://www.siteduzero.com/informatique/tutoriels/creez-votre-application-web-avec-
java-ee pages vues le 30/02/2016
- https://appengine.google.com/ pages vues le 09/03/2016
- https://code.google.com/apis/console pages vues le 25/03/2016
- https://code.google.com/p/objectify-appengine/ pages vues le 16/03/2016
- https://code.google.com/p/guava-libraries/ pages vues le 16/03/2016

- http://www.memoireonline.com pages vues le 02/02/2016
- http://www.commentcamarche.com pages vues le 08/04/2016
- http://www.wikipedia.org pages vues le 18/02/2016
Documents consultés :
- montez-votre-site-dans-le-Cloud-avec-google-app-engine
- Creez votre application web avec java jee
- ProgrammingGoogleAppEngine
- Cloud computing - Concept vaporeux ou reelle innovation
- Google-Cloud-Plateform
- Livre-blanc-EuroCloud
- guide-saas-du-syntec
- Le_SaaS_dans_le_SI_de_l_entreprise_2011
- Etude et mise en place dune solution Cloud computing privée pour une entreprise

- Google app engine for java eclipse 2

Table des matières
Dédicace---------------------------------------------------------------------------------------------------i
Remerciements-----------------------------------------------------------------------------------------ii
Liste des tableaux--------------------------------------------------------------------------------------v
Listes des figures--------------------------------------------------------------------------------------vi
Listes des sigles et abréviations-------------------------------------------------------------------vi
Résume---------------------------------------------------------------------------------------------------ix
Introduction générale---------------------------------------------------------------------------------1
Chapitre 1 : Etat de l'art sur le Cloud computing----------------------------------------------3
Introduction-------------------------------------------------------------------------------------------- 4
I. Définition du Cloud computing----------------------------------------------------------------4
II. Historique du Cloud Computing--------------------------------------------------------------5
III. Les différents services du Cloud computing---------------------------------------------6
III.1. Infrastructure as a Service (IaaS)--------------------------------------------------------6
III.2. Plateform as a Service (PaaS )-------------------------------------------------------------6
III.3. Software as a Service (SaaS)---------------------------------------------------------------7
III.4. Data as a Service (SaaS)---------------------------------------------------------------------8
IV. Les Modèles de déploiement du Cloud computing-------------------------------------9
IV.1. Le Cloud privé--------------------------------------------------------------------------------- 9
IV.1.1. Cloud privé internalisé----------------------------------------------------------------9
IV.1.2. Cloud privé externalisé--------------------------------------------------------------10
IV.2. Le Cloud communautaire-----------------------------------------------------------------10
IV.3. Le Cloud public.-----------------------------------------------------------------------------10
IV.4. Le Cloud hybride---------------------------------------------------------------------------- 11
V. Avantages et inconvénients du Cloud computing----------------------------------------11
V.1. Avantages------------------------------------------------------------------------------------- 11
V.2. Inconvénients-------------------------------------------------------------------------------- 12
VI. Cloud Computing et le Cluster------------------------------------------------------------13
VII. Sécurité dans le Cloud Computing-------------------------------------------------------13
VII.1. La sécurité des données------------------------------------------------------------------14
VII.2. La sécurité des infrastructures----------------------------------------------------------15
Mise en place d’une solution Cloud (SaaS) Page I

VII.3. La justice et le Cloud----------------------------------------------------------------------16
VII.4. L'isolation-----------------------------------------------------------------------------------16
VII.5. Les attaques et l'impact sur le Cloud---------------------------------------------------17
VIII. Le Cloud Computing : les Différents Acteurs-------------------------------------------18
VIII.1. Les acteurs de IAAS (Infrastructure as a Service)----------------------------------18
VIII.2. Les acteurs du PAAS (Plateforme as a Service).------------------------------------18
VIII.3. Les acteurs du SAAS (Software as a Service).---------------------------------------19
Conclusion--------------------------------------------------------------------------------------------- 20
Chapitre 2 : Mise en place d’une solution Cloud (SaaS)------------------------------------21
Introduction------------------------------------------------------------------------------------------ 22
I. Solutions existantes---------------------------------------------------------------------------- 22
I.1. Windows Azure-------------------------------------------------------------------------------22
I.2. Google App Engine---------------------------------------------------------------------------22
I.3. La plateforme EC2 d’Amazon--------------------------------------------------------------22
II. Etude comparative des différentes solutions existantes-------------------------------23
III. Choix de la solution retenue---------------------------------------------------------------24
IV. Présentation détaillée de la solution choisie retenue ( Google App Engine)----24
IV.1. Qu'est-ce que Google App Engine ?------------------------------------------------------25
IV.1.1. Le fonctionnement d’ App Engine--------------------------------------------------25
IV.1.2. Les langages supportés par App Engine------------------------------------------26
IV.1.3. Les services de stocker des données App Engine-------------------------------27
IV.1.3.1. Google Cloud SQL--------------------------------------------------------------------29
IV.1.3. 2. La base de données ("Datastore")-----------------------------------------------30
IV.1.3. 3. Google Cloud Storage--------------------------------------------------------------30
IV.1.3. 3.a. Le Blobstorage--------------------------------------------------------------------33
IV.1.3. 3.b. Google Cloud Storage------------------------------------------------------------34
IV.1.4. Objectify--------------------------------------------------------------------------------35
IV.1.5.Les services de google app engine--------------------------------------------------36
IV.1.5.1. Google Accounts API : authentification des visiteurs------------------------36
IV.1.5.2. Google Accounts API : authentification des visiteurs-----------------------36
Conclusion--------------------------------------------------------------------------------------------- 37
Chapitre 3 : Implémentation de la solution---------------------------------------------------38
Introduction------------------------------------------------------------------------------------------ 39
Mise en place d’une solution Cloud (SaaS) Page II

I. Installation de Google App Engine avec Eclipse----------------------------------------39
I.1. Installation d’eclipse-------------------------------------------------------------------------39
I.2. Installation du plugin Google App Engine-----------------------------------------------39
II. Mise en place du projet------------------------------------------------------------------------ 43
II.1. LA Classe FurumappServlet---------------------------------------------------------------45
II.2.LE Fichier WEB.XML-------------------------------------------------------------------------45
II.3. Le fichier APPENGINE-WEB.XML--------------------------------------------------------47
II.4. Exécution du projet-------------------------------------------------------------------------47
III. Utilisation du service Users---------------------------------------------------------------48
III.1. Mise en œuvre du service Users---------------------------------------------------------48
III.2. Test de connexion de l’utilisateur-------------------------------------------------------49
IV. Utilisation des JSP---------------------------------------------------------------------------50
V. Déclaration de l'application auprès de Google-------------------------------------------54
V.1. Enregistrement de l'application----------------------------------------------------------54
V.2. Transfert de l'application------------------------------------------------------------------55
VI. Manipulation du DataStore avec Objectify---------------------------------------------55
VI. 1. Configuration d’ Objectify----------------------------------------------------------------55
VI. 2. Objectify dans notre application furumapp-------------------------------------------56
VI. 3. Déploiement de l'application------------------------------------------------------------67
Conclusion--------------------------------------------------------------------------------------------- 70
Chapitre 4 : Mise en œuvre de la solution implémentée----------------------------------71
Introduction------------------------------------------------------------------------------------------ 72
I. Exécution de l’application en local----------------------------------------------------------72
II. Authentification des utilisateurs------------------------------------------------------------74
III. Envoi des messages sur le furum---------------------------------------------------------77
IV. Console d‘administration------------------------------------------------------------------82
Conclusion générale et perspective-------------------------------------------------------------84
WEBOGRAPHIE/BIBLIOGRAPHIE----------------------------------------------------------------87
Table des matières--------------------------------------------------------------------------------------I
Mise en place d’une solution Cloud (SaaS) Page III

Table Des Matières Cloud1

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Table Des Matières Cloud1

Загружено:

Авторское право:

Доступные форматы

Thème

:Mise en place d’une solution Cloud

SOULEYMANE ADAMOU MAHAMADOU SAYOUDI

Au nom d'Allah, le Tout Miséricordieux, le Très Miséricordieux. Louange à Allah, Seigneur de

Mise en place d’une solution Cloud(SaaS) Page i

Nos remerciements vont également :

 A ma famille, aux connaissances et à tous ceux qui m’ont aidé d’une

Mise en place d’une solution Cloud(SaaS) Page iv

Mise en place d’une solution Cloud(SaaS) Page vi

Mise en place d’une solution Cloud(SaaS) Page vii

Mise en place d’une solution Cloud(SaaS) Page viii

Mise en place d’une solution Cloud(SaaS) Page ix

API Application Programmable Interface

Mise en place d’une solution Cloud(SaaS) Page x

Le mémoire de fin d'étude est un prolongement naturel de l'immersion de l'étudiant dans le

Mise en place d’une solution Cloud(SaaS) Page xi

Mise en place d’une solution Cloud (SaaS) Page 1

Avec l’apparition dans les années 1980 de la virtualisation, de l’infogérance et de

Mise en place d’une solution Cloud (SaaS) Page 2

mise en place d’une solution Cloud (SaaS), le troisièmeportera sur l’implémentation de la

Mise en place d’une solution Cloud (SaaS) Page 3

Chapitre 1 : Etat de l'art sur le Cloudcomputing

Mise en place d’une solution Cloud (SaaS) Page 3

Beaucoup d'entreprises restent cependant sceptiques sur le Cloud computing. La principale

I. Définition du Cloud computing

Mise en place d’une solution Cloud (SaaS) Page 4

 Un accès en libre-service à la demande aux capacités de calcul. Ce service

II. Historique du Cloud Computing

Mise en place d’une solution Cloud (SaaS) Page 5

III. Les différents services du Cloud computing

III.1. Infrastructure as a Service (IaaS)

Mise en place d’une solution Cloud (SaaS) Page 6

Ce service s'apparente aux services d'hébergement classiques du centre de traitement de

L’IaaS a des avantages et inconvénients :

Avantage : grande flexibilité, contrôle total des systèmes (administration à

Inconvénient : besoin d'administrateurs système comme pour les solutions de

III.2. Plateform as a Service (PaaS )

Le PaaS a des avantages et inconvénients :

Avantage : le déploiement est automatisé, pas de logiciel supplémentaire à

III.3.Software as a Service (SaaS)

Le SaaS a des avantages et inconvénients :

III.4.Data as a Service (SaaS)

Il existe plusieurs dont on peut citer entre autre :

Business process as a service (BPaaS) : il s'agit du concept de (BPaaS) qui

Mise en place d’une solution Cloud (SaaS) Page 9

Figure 1 : Les différents types de Cloud

IV. Les Modèles de déploiement du Cloud computing

IV.1. Le Cloud privé

Le Cloudcomputing prive est subdivise en deux : interne et externe.

IV.1.1. Cloud privé internalisé

Plateforme de Cloud Computing interne à l’entreprise ou Cloud entièrement dédié à cette

Mise en place d’une solution Cloud (SaaS) Page 10

Le Cloud privé internalisé permet de :

conserver la maîtrise des infrastructures tout en proposant en interne à

IV.1.2. Cloud privé externalisé

Le Cloud privé externalisé permet de :

conserver la maîtrise des infrastructures tout en proposant à l’entreprise un

garantir un très haut niveau de confidentialité et de sécurité des infrastructures,

Des plans de continuité d’activité possibles et optionnels.

Mise en place d’une solution Cloud (SaaS) Page 11

IV.2. Le Cloud communautaire

IV.3.Le Cloud public.

IV.4.Le Cloud hybride

V. Avantages et inconvénients du Cloud computing