Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant l’architecture microservices

Ministère de l’Enseignement Supérieur
et de la Recherche Scientifique
  
Université de Carthage
  
Institut National des Sciences
Appliquées et de Technologie
Projet de Fin d’Etudes
Pour l’obtention du
Diplôme National d’Ingénieur
en Sciences Appliquées et en Technologie
Filière : Génie Logiciel
Sujet :
Refonte et déploiement d’une solution de messagerie
en utilisant l’architecture microservices.
Réalisé par : Nawres FARHAT
Entreprise d’accueil :
Soutenu le 16/06/2017
Responsable à l’entreprise: M. Amine SALHI
Et M. Slimane HMIDI
Responsable à l’INSAT: Mme. Arwa HEDHILI SBAI
Président: Mme. Leila BACCOUCHE
Examinateur : M. Mejdi JRIBI
Année Universitaire : 2016/2017

Remerciements
Au terme de ce travail, j’exprime mes vifs remerciements à toute personne ayant contribué,
de près ou de loin, à la réalisation de ce travail.
Ma profonde gratitude s’adresse à la société Sofrecom Tunisie qui m’a accueilli et à Mon-
sieur Amine SALHI mon tuteur de stage qui a dirigé mon projet de fin d’études, pour son
engagement permanent, son soutien constant et la confiance totale qu’il m’a accordée.
J’adresse aussi mes profonds remerciements à Madame Arwa HEDHILI SBAI, pour son
encadrement, pour son assistance, pour tout le temps précieux qu’elle m’a octroyé et pour ses
conseils qui m’ont été bien utiles pour la rédaction de ce rapport.
Je tiens à remercier également toute l’équipe de Messaging Pro chez Sofrecom, Monsieur
Slimen HMIDI, Monsieur Mohamed TAGHOUTI, Monsieur Baha eddine BOUKHZAR et Mon-
sieur Ahmed LOUHICHI, pour le temps qu’ils m’ont consacré durant cette période et pour le
partage de leur expertise et connaissances. C’est grâce à leur confiance et leur encouragement
que j’ai été apte à accomplir mes missions et à surmonter toute difficulté rencontrée tout en
gagnant de l’expérience.
Je remercie également mon collègue Tayeb BEN ACHOUR pour sa collaboration pour réus-
sir le projet, et Monsieur Khaled NASSER pour l’agréable intégration au sein de Sofrecom.
Je tiens, par ailleurs, à exprimer mon immense reconnaissance à : Madame Leila BAC-
COUCHE, pour l’honneur qu’elle a bien voulu me faire en acceptant de présider le jury chargé
d’évaluer ce travail. Et Monsieur Mejdi JRIBI , d’avoir accepté d’examiner ce travail. J’espère
que le présent projet soit à la hauteur de vos attentes.
i

Table des Matières
Liste des Figures vi
Liste des Tableaux ix
Introduction Générale 1
I Chapitre 1 : Présentation du projet 3
1 Présentation de l’entreprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Le groupe Sofrecom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Sofrecom Tunisie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Context du sujet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 Problématique du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4 Diagnostic technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5 La méthodologie : SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1 Les rôles dans SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2 Planification d’un projet par Scrum . . . . . . . . . . . . . . . . . . . . 8
II Chapitre 2 : Concepts théoriques 10
1 Relation entre les microservices et DevOps . . . . . . . . . . . . . . . . . . . . 10
2 Architecture microservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3 Caractéristiques d’une architecture microservices . . . . . . . . . . . . . . . . . . 11
4 Domain driven design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5 Architecture orientée évènements . . . . . . . . . . . . . . . . . . . . . . . . . . 14
III Chapitre 3 : Les microservices proposés 16
1 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.2 Backlog de produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.3 Les besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . 19
2 Division Messaging Pro en microservices . . . . . . . . . . . . . . . . . . . . . . 19
3 Planification des Sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4 L’architecture de l’application en microservices . . . . . . . . . . . . . . . . . . . 23
5 Les choix technologiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1 Choix des frameworks de back-end . . . . . . . . . . . . . . . . . . . . . 24
ii

Remerciements
5.1.1 Spring Boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1.2 Dropwizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1.3 Choix de Message Broker . . . . . . . . . . . . . . . . . . . . . 25
5.2 Choix des frameworks front-end . . . . . . . . . . . . . . . . . . . . . . 26
5.2.1 Angular 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.2.2 React . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.3 L’architecture technique . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
IV Chapitre 4 : Microservices utilitaires 30
1 Microservice Bundle-Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
1.1 Analyse fonctionnelle de microservice " Bundle-Service " . . . . . . . . . 31
1.2 Conception de microservice Bundle-Service . . . . . . . . . . . . . . . . . 32
1.2.1 Architecture logicielle de microservice Bundle Service . . . . . . 32
1.2.2 Diagramme de package "Bundle-Service" . . . . . . . . . . . . . 32
1.2.3 Diagramme de classes de microservice "BundleService" . . . . . 33
1.3 Réalisation de microservice "Bundle-Service" . . . . . . . . . . . . . . . . 34
1.3.1 Architecture technique du microservice "Bundle-Service" . . . . 34
1.3.2 Implémentation de microservice "Bundle-Service" . . . . . . . . 35
1.3.3 Tests de microservice "Bundle-Service" . . . . . . . . . . . . . . 36
2 Microservice PhoneNumber-Service . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.1 Conception de microservice "PhoneNumber-Service" . . . . . . . . . . . . 37
2.1.1 Architecture logicielle de microservice "PhoneNumberService" . 37
2.1.2 Diagramme de package de microservice "phoneNumber-Service" 37
2.2 Implémentation de microservice "PhoneNumber-Service" . . . . . . . . . 38
3 Microservice Customer-Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.1 Analyse fonctionnelle de microservice "Customer-Service" . . . . . . . . . 39
3.2 Conception de microservice "Customer-Service" . . . . . . . . . . . . . . 40
3.3 Réalisation de microservice "Customer-Service" . . . . . . . . . . . . . . 41
3.3.1 Implémentation de microservice "Customer-Service" . . . . . . . 41
3.3.2 Tests de microservice "Customer-Service" . . . . . . . . . . . . 42
4 Microservice User-Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.1 Analyse fonctionnelle de microservice "User-Service" . . . . . . . . . . . . 42
4.2 Conception de microservice "User-Service" . . . . . . . . . . . . . . . . . 43
4.2.1 Architecture logicielle de microservice "User-Service" . . . . . . 43
4.2.2 Modèle de domaine de microservice "User-Service" . . . . . . . . 44
iii

Remerciements
4.2.3 Diagramme de package de microservice "User-Service" . . . . . 45
4.3 Réalisation de microservice "User-Service" . . . . . . . . . . . . . . . . . 46
4.3.1 Architecture technique de microservice "User-Service" . . . . . . 46
4.3.2 Implémentation de microservice "User-Service" . . . . . . . . . . 47
4.3.3 Tests de microservice "User-Service" . . . . . . . . . . . . . . . 48
5 Microservice "ContactList-service" . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.1 Analyse fonctionnelle de microservice "ContactList-Service" . . . . . . . . 49
5.1.1 Diagramme de cas d’utilisation de microservice "ContactList-
Service" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.1.2 Diagramme séquence système "Importer une liste des contacts" 50
5.2 Conception de microservice "ContactList-Service" . . . . . . . . . . . . . 51
5.2.1 Modèle de domaine de microservice "ContactList-Service" . . . 51
5.2.2 Diagramme de composants de microservice "ContactList-Service" 52
5.3 Réalisation de microservice "ContactList-Service" . . . . . . . . . . . . . 53
5.3.1 Implémentation de microservice "ContactList-Service" . . . . . 53
5.3.2 Tests de microservice "ContactList-Service" . . . . . . . . . . . 55
V Chapitre 5 : Les microservices Voice et SMS campaign 56
1 Microservice "SMSCampaign-Service" . . . . . . . . . . . . . . . . . . . . . . . . 56
1.1 Analyse des besoins fonctionnels du "SMSCampaign-Service" . . . . . . . 57
1.1.1 Diagramme de cas d’utilisation de microservice "SMSCampaign-
Service" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
1.1.2 Diagramme de séquence système "Créer une campagne SMS" . . 57
1.1.3 Diagramme de séquence système "lancer la campagne" . . . . . 59
1.2 Conception de microservice "SMSCampaign-Service" . . . . . . . . . . . . 60
1.2.1 Orientation architecturale de microservice "SMSCampaign-Service" 60
1.2.2 Modèle de domaine de microservice "SMSCampaign-Service" . . 61
1.2.3 Diagramme d’état d’une campagne SMS . . . . . . . . . . . . . 62
1.2.4 Diagramme d’état d’un message SMS . . . . . . . . . . . . . . . 63
1.2.5 Architecture logicielle de microservice "SMSCampaign-Service" . 64
1.2.6 Le lancement de la campagne SMS . . . . . . . . . . . . . . . . 65
1.3 Réalisation de microservice "SMSCampaign-Service" . . . . . . . . . . . 66
1.3.1 Choix techniques . . . . . . . . . . . . . . . . . . . . . . . . . 66
1.3.1.1 Apache Camel . . . . . . . . . . . . . . . . . . . . . . 66
1.3.1.2 Choix de la base de données . . . . . . . . . . . . . . . 66
iv

Table des Matières
1.3.1.3 Framework d’accès aux données . . . . . . . . . . . . 68
1.3.1.4 SMPPSIM . . . . . . . . . . . . . . . . . . . . . . . . . 68
1.3.2 Architecture technique de microservice "SMSCampaign-Service" 68
1.3.3 Implémentation de microservice "SMSCampaign-Service" . . . . 69
1.3.4 Tests de microservice "SMSCampaign-Service" . . . . . . . . . 70
2 Microservice "VoiceCampaign-Service" . . . . . . . . . . . . . . . . . . . . . . . 71
2.1 Analyse fonctionnelle de microservice "VoiceCampaign-Service" . . . . . . 71
2.2 Conception de microservice "VoiceCampaign-Service" . . . . . . . . . . . 72
2.2.1 Modèle de domaine . . . . . . . . . . . . . . . . . . . . . . . . . 72
2.2.2 Diagramme d’état d’un message vocal . . . . . . . . . . . . . . 73
2.2.3 Diagramme de séquence d’envoi d’une campagne vocale . . . . 74
2.2.4 Diagramme de séquence de microservice "CancelVoiceCampaign" 76
2.3 Réalisation de microservice "VoiceCampaign-Service" . . . . . . . . . . . 78
2.3.1 Architecture technique de microservice "VoiceCampaign-Service" 78
2.3.2 Implémentation de microservice "VoiceCampaign-Service" . . . 78
2.3.3 Tests de microservice "VoiceCampaign-Service" . . . . . . . . . 79
Conclusion générale 81
Bibliographique 82
Glossaire 84
Annexes 85
v

Liste des Figures
I.1 Scénario d’inscription d’une entreprise à la plateforme MessagingPro . . . . . . . 5
I.2 Architecture technique existante . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
I.3 Le framework SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
II.1 carte de contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
III.1 Modèle du domaine de MessagingPro . . . . . . . . . . . . . . . . . . . . . . . . 21
III.2 Carte de contexte de Messaging Pro . . . . . . . . . . . . . . . . . . . . . . . . . 22
III.3 Les composants d’une architecture microservices . . . . . . . . . . . . . . . . . . 23
III.4 Courbe de performance React VS Angular VS Angular JS VS Blaze . . . . . . . 27
III.5 Architecture technique minimale . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
IV.1 Diagramme cas d’utilisation du microservice Bundle-service . . . . . . . . . . . . 31
IV.2 Architecture logicielle de microservice Bundle-Service . . . . . . . . . . . . . . . 32
IV.3 Diagramme de package de Bundle-Service . . . . . . . . . . . . . . . . . . . . . 33
IV.4 Diagramme de classes de microservices "Bundle-service" . . . . . . . . . . . . . . 34
IV.5 Architecture technique de microservice "Bundle-Service" . . . . . . . . . . . . . 35
IV.6 Interface d’ajout d’un nouveau Bundle . . . . . . . . . . . . . . . . . . . . . . . 35
IV.7 Liste des paquets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
IV.8 Tests unitaire de "Bundle-Service" . . . . . . . . . . . . . . . . . . . . . . . . . . 36
IV.9 Architecture logicielle de microservice "PhoneNumber-Service" . . . . . . . . . . 37
IV.10 Diagramme de package de microservice "PhoneNumber-Service" . . . . . . . . 38
IV.11 Les test unitaire du microservice phoneNumber-Service . . . . . . . . . . . . . 39
IV.12 Diagramme de cas d’utilisation de microservice "Customer-Service" . . . . . . . 40
IV.13 Modèle de domaine de microservice "Customer-Service" . . . . . . . . . . . . . 41
IV.14 Liste des clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
IV.15 Interface de création d’un client . . . . . . . . . . . . . . . . . . . . . . . . . . 42
IV.16 Interface de création d’un client . . . . . . . . . . . . . . . . . . . . . . . . . . 42
IV.17 Diagramme de cas d’utilisation de microservice "User-Service" . . . . . . . . . . 43
IV.18 La couche d’intégration de microservice "User-Service" . . . . . . . . . . . . . . 44
IV.19 Modèle de domaine de microservice "User-Service" . . . . . . . . . . . . . . . . 44
IV.20 Diagramme de package de "User-Service" . . . . . . . . . . . . . . . . . . . . . 46
IV.21 Architecture technique de microservice "User-Service" . . . . . . . . . . . . . . 47
vi

Liste des Figures
IV.22 Formulaire de création d’un nouveau utilisateur . . . . . . . . . . . . . . . . . 48
IV.23 Liste de tous les utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
IV.24 Tests unitaires de microservice "User-Service" . . . . . . . . . . . . . . . . . . . 49
IV.25 Diagramme de cas d’utilisation de ContactList-Service . . . . . . . . . . . . . . 50
IV.26 Diagramme de séquence système : Importer une liste de contacts . . . . . . . . 51
IV.27 Modèle de domaine de microservice "ContactList-Service" . . . . . . . . . . . . 52
IV.28 Diagramme de composants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
IV.29 Liste des toutes les listes de contacts . . . . . . . . . . . . . . . . . . . . . . . 53
IV.30 Importer une liste de contacts . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
IV.31 Formulaire de création manuelle d’une liste de contacts . . . . . . . . . . . . . 54
IV.32 Formulaire d’ajout d’un contact . . . . . . . . . . . . . . . . . . . . . . . . . . 54
IV.33 Tests unitaires de microservice "ContactList-Service" . . . . . . . . . . . . . . . 55
V.1 Diagramme de cas d’utilisation de microservice "SMSCampaign-Service" . . . . 57
V.2 Diagramme de séquence système "créer une campagne SMS" . . . . . . . . . . . 58
V.3 Diagramme de séquence lancer une campagne SMS . . . . . . . . . . . . . . . . 59
V.4 Modèle de domaine du "SMSCampaignService" . . . . . . . . . . . . . . . . . . . 62
V.5 Diagramme d’état d’une campagne SMS . . . . . . . . . . . . . . . . . . . . . . 63
V.6 Diagramme d’état d’un message SMS . . . . . . . . . . . . . . . . . . . . . . . . 64
V.7 Processus de création et de lancement d’une campagne SMS . . . . . . . . . . . 66
V.8 Architecture technique de microservice "SMSCampaign-Service" . . . . . . . . . 69
V.9 Formulaire de création d’une campagne SMS . . . . . . . . . . . . . . . . . . . . 69
V.10 Liste des campagnes SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
V.11 La liste des campagnes SMS après annulation d’une campagne . . . . . . . . . . 70
V.12 Tests unitaires de microservice "SMSCampaign-Service" . . . . . . . . . . . . . . 71
V.13 Diagramme de cas d’utilisation de "VoiceCampaign-Service" . . . . . . . . . . . 72
V.14 Modèle de domaine de microservice "voiceCampaign-Service" . . . . . . . . . . . 73
V.15 Diagramme d’état d’un message vocal . . . . . . . . . . . . . . . . . . . . . . . . 74
V.16 Diagramme de séquence d’envoi d’une campagne vocale . . . . . . . . . . . . . . 75
V.17 Diagramme de séquence d’annulation d’une campagne vocale . . . . . . . . . . . 77
V.18 Architecture Technique de microservice "VoiceCampaign-Service" . . . . . . . . 78
V.19 Formulaire de création d’une nouvelle campagne vocale . . . . . . . . . . . . . . 79
V.20 listes des campagnes vocales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
V.21 Tests de microservice "VoiceCampaign-Service" . . . . . . . . . . . . . . . . . . 79
A.1 Architecture global de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . 88
vii

Liste des Figures
A.2 Diagramme d’activité de la chaîne de déploiement . . . . . . . . . . . . . . . . . 90
viii

Liste des Tableaux
III.1 Backlog de produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
III.2 Partitionnement des user stories par sprint . . . . . . . . . . . . . . . . . . . . . 22
III.3 Les composants d’une architecture microservice et l’apport du Spring cloud . . . 25
A.1 Comparaison entre Eureka et Consul . . . . . . . . . . . . . . . . . . . . . . . . 86
ix

Introduction Générale
La communication est omniprésente dans notre société. Elle présente un élément inhérent
à l’existence humaine sans laquelle l’interaction entre les différents membres, moraux et phy-
siques, de la société sera pénible. Communiquer c’est informer, influencer, partager, échanger,
convaincre, séduire, etc. Nous parlons, ainsi, d’une autre sorte de Cogito : "je communique donc
j’existe".
Actuellement, la communication gagne une nouvelle dimension grâce à l’expansion du phé-
nomène de la globalisation, qui n’a pas seulement transformé le monde en un village planétaire,
mais aussi à un marché très compétitif dans lequel les stratégies de communications sont dé-
sormais un élément clé à la pérennité et le succès.
A titre d’exemple, dans le monde des affaires, les moyens de communication jouent un
rôle crucial dans l’identification de la culture de l’entreprise (son image et sa réputation) et
dans la personnalisation de ses objectifs. En effet, la communication est le levier marketing qui
permettra à l’entreprise de commercialiser et faire connaître ses produits et services et influencer
l’opinion publique.
Dans ce cadre, les entreprises contemporaines privilégient les interactions virtuelles comme
les e-mails, SMS, internet et réseaux sociaux par rapport à la communication verbale et ges-
tuelle. Particulièrement, les messages textuels et les messages vocaux présentent un moyen
favorable de communication grâce à sa simplicité, sa rapidité, le bas prix et la fiabilité. D’une
part, les entreprises utilisent souvent ces messages pour lancer leurs campagnes marketing, leurs
campagnes de promotion ainsi que la diffusion des renseignements et des informations. D’autre
part, l’Etat peut bénéficier de ces messages afin de sensibiliser ses citoyens. Par exemple, durant
les élections, elle communique à travers les messages textuels les procédures et les renseigne-
ments relatifs au vote. Elle optimise son budget en réduisant les dépenses et en augmentant les
recettes (lutte contre le gaspillage de l’eau, incitation à la rationalisation de la consommation
de l’électricité, etc.)
Dans ces différents contextes, les entreprises et l’Etat ont besoin de diffuser avec un grand
débit des SMS en masse, au tarif le plus raisonnable et qui cible un public varié et au nombre
assez élevé. Ils ont besoin aussi d’envoyer des messages en différents formats (textes, audio,
etc.), d’organiser et de gérer facilement les campagnes et de personnaliser l’envoie pour chaque
récepteur. Dans cette optique, s’inscrit notre projet de fin d’étude qui consiste à migrer une
application de messaging d’une architecture monolithique vers une architecture microservices.
Le présent rapport qui décrit la refonte de Messaging Pro est structuré en cinq chapitres.
Le premier chapitre concerne la présentation de l’organise d’accueil, contexte du sujet, la pro-
1

Introduction Générale
blématique ainsi que le diagnostic de l’existant et la méthodologie utilisée.
Le deuxième chapitre présente les concepts théoriques utiles pour l’élaboration de notre projet.
Le troisième chapitre est consacré à la présentation des microservices proposés. Nous spéciﬁons
d’abord les besoins. Ensuite, nous présentons la division de l’application existante en microser-
vices et le planning de nos sprints. Après, nous présentons l’architecture d’une application en
microservices et nous ﬁnissons par présenter nos choix techniques.
Le quatrième chapitre décrit les deux premiers sprints qui sont dédiés au développement des
microservices utilitaires de notre application.
Quant au dernier chapitre, il est dédié aux deux derniers sprints qui décrivent les cycles de vie
de nos deux principaux microservices.
Pour conclure, nous clôturons ce rapport par une synthèse de cette expérience et une illustration
des perspectives.
2

Chapitre I
Chapitre 1 : Présentation du projet
Plan
1 Présentation de l’entreprise . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Le groupe Sofrecom . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Sofrecom Tunisie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Context du sujet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 Problématique du projet . . . . . . . . . . . . . . . . . . . . . . . . . 5
4 Diagnostic technique . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5 La méthodologie : SCRUM . . . . . . . . . . . . . . . . . . . . . . . 8
5.1 Les rôles dans SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2 Planification d’un projet par Scrum . . . . . . . . . . . . . . . . . . . 8
Introduction
Dans ce premier chapitre introductif, nous présentons l’organisme d’accueil Sofrecom et sa
filiale Sofrecom Tunisie. Nous présentons par la suite, le contexte du sujet, la problématique
et un diagnostic technique de la solution existante. Enfin, nous présentons la méthode de
développement choisie pour la réalisation de notre solution.
1 Présentation de l’entreprise
1.1 Le groupe Sofrecom
Sofrecom, filiale d’Orange, développe depuis 50 ans un savoir-faire unique dans les métiers de
l’opérateur, ce qui en fait un leader mondial du conseil et de l’ingénierie télécom. Ces dernières
années, plus de 200 acteurs majeurs, dans plus de 100 pays, ont confié à Sofrecom la conduite de
leurs projets stratégiques et opérationnels. Le Know-How Network de Sofrecom, c’est aussi la
garantie d’un transfert de savoir-faire, de compétences et d’expertises pour une transformation
durable s’appuyant sur des méthodologies certifiées au niveau international.
3

I.2 Context du sujet
1.2 Sofrecom Tunisie
Sofrecom Tunisie lancé en Octobre 2012, est la plus jeune et la plus importante filiale du
groupe Sofrecom en zone Afrique et Moyen Orient. En 5 ans, elle a pu se positionner en tant
qu’un acteur majeur du conseil et d’ingénierie en télécommunications. Sofrecom Tunisie compte
aujourd’hui 400 experts, et deux clients majeurs qui font partie du groupe Orange : DSI 1
France
et OLS 2
. Sofrecome Tunisie propose à ses clients une gamme riche de prestations organisées
autour de huit métiers :
— Ingénierie
— Architecture
— Support et maintenance
— Sécurité informatique
— Expertise technique
— Développement
— Innovation
— Consulting
Notre projet concerne le métier du développement.
2 Context du sujet
Messaging Pro est une application web de messaging développée par Sofrecom pour ses fi-
liales Oranges. Le projet a été initié par Sofrecom Tunisie en 2014, afin de le vendre à plusieurs
filiales d’Orange groupe en Afrique et Moyen Orient. Actuellement, Messaging Pro est déployée
sur l’infrastructure d’Orange Congo, Orange Botswana, Orange Kenya, Orange Jordan, Orange
Madagascar. Elle est disponible avec sa troisième génération qui offre les services de messagerie
au gouvernement ou à ses clients Business.
Messaging Pro permet à ses clients de gérer leurs campagnes SMS et vocales ainsi que lancer
des campagnes des quiz et des sondages. Nous décrivons dans la figure I.1, un scénario typique
d’inscription des entreprises à la plateforme pour avoir la main de créer des campagnes. Ce
scénario montre les actions nécessaires et les rôles de chaque intervenant dans la chaîne de
messagerie entre l’agence Orange et l’entreprise.
1. Direction des Systèmes dInforamtion.
2. OLS : Orange Labs Services
4

I.3 Problématique du projet
Figure I.1 – Scénario d’inscription d’une entreprise à la plateforme MessagingPro
3 Problématique du projet
Après chaque itération le produit, Messaging pro, subit des améliorations. Des fonctionna-
lités s’ajoutent pour répondre mieux au marché, s’aligner plus au besoin du client et élargir sa
clientèle cible. Le projet a commencé depuis trois ans, et selon son plan d’évolution, il continuera
à évoluer pendant au moins quelques années. Ceci a généré plusieurs défis.
En effet, la taille de projet n’a cessé d’augmenter pour devenir une application monolithique
gigantesque, difficile à gérer et à comprendre. Même le respect des bonnes pratiques et les efforts
fournis pour maintenir un code modulaire et évolutif n’as pas pu éliminer la complexité de ce
produit. Avec une application qui comporte des milliers des lignes et un nombre important de
classes plusieurs problèmes se présentent.
En premier lieu, faire évoluer l’équipe est devenu de plus en plus coûteux. En effet, un nouveau
développeur au projet implique le sacrifice de plusieurs jours et semaines pour comprendre le
code existant et pour qu’il soit capable de le modifier ou d’ajouter d’autres fonctionnalités. En
second lieu, la modification de quelques lignes au niveau de l’application entraîne le redéploie-
ment, le ré-teste (les tests unitaires, les tests de régression, les tests IHM) et la révision de la
qualité de code de toute l’application. La répétition manuelle de toute la chaîne de déploiement
après chaque modification rend le travail de l’équipe de test plus ennuyeux, plus gênant et
5

I.4 Diagnostic technique
plus coûteux en termes d’homme/jours. En troisième lieu, la haute disponibilité, la rapidité de
traitement et la fiabilité sont des priorités pour les deux fonctionnalités de base de Messaging
pro, qui sont l’envoie des messages textuels et messages vocaux. Or, la réplication de toute
l’application afin de garantir ces exigences pour quelques fonctionnalités est très coûteuse en
termes de ressources matérielles.
Par ailleurs, un autre problème qui s’impose, depuis toujours, concerne l’agilité au niveau
d’équipe qui est constituée traditionnellement de deux sous équipes : une équipe de dévelop-
pement et une équipe opérationnelle. L’équipe de développement collecte les exigences métier,
rédige le code, exécute et teste le code dans un environnement isolé. Cette équipe n’est pas sou-
vent préoccupée par l’impact de leur code sur la production. L’équipe opérationnelle exploite
le code fourni par l’équipe de développement et elle est plutôt concentrée sur la stabilisation
des services et de l’architecture ainsi que sur la performance des instances actuelles. Cette
organisation traditionnelle entre les équipes alourdit énormément la mise en production. En
effet, plus nous avons des nouvelles fonctionnalités, plus le temps pour la mise en production
augmente, et plus nous avons des régressions. Potentiellement, cela implique l’augmentation du
temps d’indisponibilité pour l’application, du stress pour les équipes et bien entendu de l’argent
perdu. Dans le but de surmonter ces limites, l’équipe a décidé de passer vers une architecture
microservices et vers une culture Dev-Ops.
Ainsi, deux projets sont affleurés, un projet de migration vers une architecture microservices
qui est le nôtre et un autre projet d’automatisation de chaîne de déploiement. Nous notons que
la validation du nouveau produit requiert la réussite de deux projets. Par conséquent, il est
indispensable de tester et valider notre travail afin de l’évaluer par la chaîne de déploiement.
4 Diagnostic technique
Outre les problèmes générés par l’architecture monolithique, l’application présente des pro-
blèmes technologiques. Avant de passer aux critiques, nous présentons l’architecture technique
existante dans la figure I.2.
6

I.4 Diagnostic technique
Figure I.2 – Architecture technique existante
La figure I.2, montre que l’application existante est décomposée en deux applications appe-
lées par l’équipe front-end et backend. Elle possède deux modes de communication synchrone
(HTTP REST) et asynchrone (communication à base de messages). Les deux parties partagent
une base de données MySQL.
L’application backend communique avec un serveur SMSC 3
pour envoyer les messages
textuels et avec l’OMS 4
pour envoyer les messages vocaux. Cette architecture présente plusieurs
limites. En effet, après certain temps, la base MySQL a signalé des problèmes de performance
particulièrement pour les filiales où le nombre des habitants est très important, exemple le
Congo. En plus, l’application utilise la plateforme de messaging ActiveMQ pour communiquer
entre les deux applications. Or cette plateforme a présenté des limites. En effet, ActiveMQ
n’est plus capable de fonctionner normalement avec un seuil supérieur à 10 mille messages. En
outre, le framwork Play utilisé dans la couche présentation de l’application frontend présente
des problèmes des performances à cause de son utilisation d’un moteur de template qui génère
3. Le SMSC : est l’abréviation de short Message Service Center. Il permet de gérer le transfert de messages
SMS entre les téléphones mobiles. Le protocole utilisé pour communiquer avec l’SMSC est le SMPP (Short
message Peer to Peer)
4. L’OMS : est le serveur qui permet le transfert des messages vocaux, le protocole utilisé pour communiquer
avec l’OMS est le HTTP
7

I.5 La méthodologie : SCRUM
la vue coté backend et l’envoie au client. Cette génération coté serveur peut prendre plusieurs
secondes voir quelques minutes dans quelques cas.
5 La méthodologie : SCRUM
Dans le contexte de notre projet où les dimensions de notre produit n’est pas fixe dès le
début et où nous avons besoin de collaborer et dialoguer avec le reste des membres de l’équipe
en quotidien pour pouvoir réussir toutes les étapes (développement, et automatisation de la
chaîne de déploiement), l’utilisation d’une méthode agile est une priorité pour pouvoir réussir
la mission dans les meilleures conditions. Nous avons choisi de travailler avec la méthode Scrum,
utilisée par l’équipe de Messaging Pro, qui présente une implémentation de l’approche agile.
Nous présentons, dans la suite, les différents intervenants dans notre projet ainsi que le cycle
de vie de la méthode Scrum.
5.1 Les rôles dans SCRUM
Le "Product owner" est la personne qui porte la vision du produit à réaliser, responsable
de la gestion du "product backlog" et travaille en interaction avec l’équipe de développement.
Il s’agit généralement d’un expert du domaine métier du projet. M. Khaled NASSER est le
"Product owner". Le "Scrum master" est la personne qui doit maitriser SCRUM et s’assurer
que ce dernier est bien compris et appliqué. M.SALHI AMINE est le "Scrum master". L’équipe
transforme les besoins en fonctionnalités pour aboutir à un incrément utilisable et livrable à
la fin de chaque itération. L’équipe est pluridisciplinaire et auto-organisée. L’équipe comporte
deux stagiaires, Tayeb BEN ACHOUR, étudiant en Réseau et Télécommunication à l’INSAT,
qui est le responsable de l’automatisation de chaîne de déploiement et moi-même, Nawres
FARHAT, étudiante en Génie logiciel à lINSAT, qui est le responsable de développement des
microservices.
5.2 Planification d’un projet par Scrum
Pour appliquer correctement SCRUM, il faut comprendre le cycle de vie d’un sprint pendant
un processus SCRUM. Le processus, illustré dans la figure I.3, est décrit ci-dessous[1] :
1. le Product owner crée le "product backlog" en déterminant et priorisant les users Story.
2. Pendant la planification du sprint, l’équipe choisit un ensemble de " user story " les plus
prioritaires à partir du "product backlog" pour construire le sprint Backlog.
3. L’équipe implémente les "users story" pendant une période qui dure de 2 à 4 semaines.
8

I.5 La méthodologie : SCRUM
4. Durant le sprint, l’équipe se réunit chaque jour, "Daily Scrum", pour synchroniser les
tâches.
5. A la ﬁn du sprint, le travail doit être achevé pour faire une démonstration au client.
6. Le sprint est clôturé par un "sprint review" pour discuter les prochaines étapes du projet
et par un "sprint retrospective" pour parler des manières à appliquer pour rendre l’équipe
plus productive
Figure I.3 – Le framework SCRUM
Conclusion
A travers ce premier chapitre, nous avons exposé le cadre de notre travail ainsi que la
méthodologie adoptée pour la conception et le développement des tâches demandées. Nous
pouvons passer au chapitre suivant qui est réservé à présenter les concepts théoriques relatifs
à notre projet.
9

Chapitre II
Chapitre 2 : Concepts théoriques
Plan
1 Relation entre les microservices et DevOps . . . . . . . . . . . . . 10
2 Architecture microservices . . . . . . . . . . . . . . . . . . . . . . . 11
3 Caractéristiques d’une architecture microservices . . . . . . . . . . 11
4 Domain driven design . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5 Architecture orientée évènements . . . . . . . . . . . . . . . . . . . 14
Introduction
Afin d’atteindre les objectifs de notre projet, l’étude des concepts théoriques relatifs à notre
projet et des différents moyens mis à notre disposition est une étape inévitable. Ensuite, nous
pouvons dégager la solution envisageable qui peut faire face aux problèmes liés à la solution
existante. Dans ce chapitre, nous présentons les concepts et les termes clés qui s’inscrivent dans
le contexte de notre projet à savoir la relation entre les microservices et DevOps 1
, l’architecture
microservices, ses caractéristiques, le domaine driven design (DDD) et l’architecture orientée
évènements (EDA).
1 Relation entre les microservices et DevOps
Nous commençons ce chapitre par la présentation de la relation entre l’architecture des
microservices et l’approche DevOps. Actuellement, les microservices et DevOps sont deux ten-
dances en effervescence. Elles présentent des pratiques qui offrent une plus grande agilité et
une efficacité opérationnelle pour l’entreprise, selon Kathrina Probst and Uri Sarid : " DevOps
excellence is a key component of microservice excellence. " (L’excellence de DevOps est un
élément clé de l’excellence des microservices). En effet, nous avons des bons résultats lorsque
DevOps et les microservices sont appliqués ensemble.
1. Un mouvement dont le but est de définir un ensemble de techniques permettant aux différentes équipes
(développement, tests et exploitation) de communiquer efficacement afin daméliorer la qualité du produit
10

II.2 Architecture microservices
Le mariage entre l’architecture des microservices et l’approche DevOps a vu le jour dans des
entreprises comme Amazon, Netflix, SoundCloud, Facebook, Google, etc. Dans de nombreux
cas, ces entreprises ont commencé par des applications monolithiques, qui ont rapidement évolué
vers des services décomposés. Avec cette évolution architecturale, ces entreprises ont également
excellé avec DevOps, elles ont partagé des approches communes pour le développement de
logiciels.
En outre, les microservices apportent une productivité supplémentaire à DevOps en adop-
tant un ensemble d’outils communs, qui peut être utilisé à la fois pour le développement (Dev)
et les opérations (Ops). Ceci a facilité la tâche, en permettant aux membres des équipes Dev
et Ops de travailler ensemble sur un problème et de le résoudre avec succès. [2]
2 Architecture microservices
L’architecture microservices développe une application comme un ensemble de petits ser-
vices. Chaque service fonctionne moyennant son propre processus qui communique avec des
mécanismes légers. Les services sont développés autour des compétences métiers qui sont dé-
ployés d’une façon indépendante par un processus automatisé.[Martin Fowler] Ces services sont
isolés et autonomes mais ils communiquent entre eux pour fournir les fonctionnalités nécessaires.
Les microservices sont généralement implémentés et pilotés par des petites équipes avec suffi-
samment d’autonomie. Chaque équipe peut changer l’implémentation de chaque service voir le
remplacer par un autre avec un impact minimal sur le reste de système. [3]
Cette architecture présente plusieurs avantages comme l’hétérogénéité technologique, la
résistance contre l’échec, la scalabilité sur mesure, la facilité de déploiement, l’alignement or-
ganisationnel, la réutilisabilité, etc. [4]
3 Caractéristiques d’une architecture microservices
Martin Fowler décrit neuf caractéristiques [5] qu’il estime qu’elles soient présentes dans
la plupart des architectures microservices. Nous présentons, dans la suite, ces caractéristiques
puisqu’il est essentiel de les appliquer durant la conception et le développement de nos micro-
services.
— Division en composants via les services
Par définition un logiciel développé en microservices peut être décomposé en plusieurs ser-
vices utilisés comme des composants. Ceci permet de déployer, redéployer, modifier et rem-
placer un service sans affecter l’intégrité de l’application. En plus, ceci offre une interface de
11

II.3 Caractéristiques d’une architecture microservices
composants plus explicite. En effet, la plupart des langages sont incapables de fournir un bon
mécanisme pour définir une interface publiée explicitement. Souvent, la documentation et la
discipline empêchent les clients de rompre l’encapsulation d’un composant, ce qui entraîne un
couplage fort entre les composants. Les services résolvent ce problème grâce à l’utilisation des
mécanismes d’appel distants explicites.
— Organisation autour des capacités métiers
La décomposition classique des applications logicielles consiste à décomposer l’application
selon les couches techniques, ceci permet d’avoir trois équipes (équipe interface utilisateur,
équipe développement métier et équipe base de données). Cependant, une application en mi-
croservices est décomposée en des services centrés sur des capacités métiers et où les équipes
sont inter-fonctionnelles, avec tous les niveaux de compétences (UI, stockage, gestion de projet).
— Produits, pas projets
Avec les microservices, une équipe est responsable d’un produit tout au long de son cycle de
vie. Une équipe de développement assume la pleine responsabilité du logiciel en production. Ceci
mène les développeurs à rester au courant du comportement de leurs produits en production et
augmente le contact avec le client vu qu’ils doivent prendre une partie de la charge du support.
— Extrémités Intelligentes et canaux stupides
La communauté microservices favorise l’utilisation des canaux de communication stupides
et des extrémités intelligents. Les applications en microservices visent à être aussi découplées et
aussi cohérentes. Elles reçoivent une demande, appliquent la logique appropriée et produisent
une réponse. Celles-ci sont chorégraphiées en utilisant des protocoles REST simples plutôt que
des protocoles complexes tels que WS-Choreography ou BPEL où l’orchestration est effectuée
par un outil central. Les deux protocoles souvent utilisés sont le HTTP et le messaging avec
des bus de messagerie asynchrones et légers. L’infrastructure pour le bus de messaging est
typiquement stupide, l’intelligence est concrétisée toujours dans les extrémités qui produisent
et consomment le message (dans les services).
— Une gouvernance décentralisée
L’une des conséquences de la gouvernance centralisée est la normalisation de l’application
sur une seule plateforme technologique. L’expérience montre que cette approche présente des
limites, en effet "pas tous les problèmes sont des clous et pas toutes les solutions sont des
marteaux ", il est donc difficile de trouver une seule technologie qui résout tous les problèmes.
Avec une architecture microservices, nous sommes capables de développer chaque service en
utilisant une technologie, un langage ou une plateforme différente ce qui permet de résoudre
le problème d’une façon efficace. Un autre aspect de la gouvernance décentralisée concerne les
équipes qui construisent les microservices. Ces équipes préfèrent l’idée de produire des outils
utiles afin que d’autres développeurs puissent les utiliser pour résoudre des problèmes similaires.
12

II.4 Domain driven design
Ceci favorise l’idée du partage et de l’open source.
— Gestion des données décentralisée
Avec une architecture microservices, chaque service a un model conceptuel différent. De
plus, les microservices décentralisent également les décisions de stockage de données. En effet,
pour une application monolithique, les entreprises préfèrent une base de données logique unique
pour les données persistantes alors que pour les microservices chaque service gère sa propre base
de données. Ceci est réalisé soit avec des instances différentes de la même technologie de base
de données, soit avec des systèmes de base de données entièrement différents, nous parlons ici
de "polygot Persistence"
— Automatisation de l’infrastructure
Les techniques d’automatisation de l’infrastructure ont considérablement évolué au cours
des dernières années. L’évolution du cloud a réduit la complexité opérationnelle de la construc-
tion, du déploiement et de l’exploitation de microservices. Les équipes qui développent des
applications en microservices ont une expérience considérable dans la livraison continue et l’in-
tégration continue. Ces équipes utilisent des techniques d’automatisation des infrastructures.
— Design for Failure
Les applications en microservices sont conçues de manière à pouvoir tolérer l’échec des
services. Tout appel de service pourrait échouer en raison de l’indisponibilité du fournisseur.
Ceci ne doit jamais affecter le fonctionnement de client. Par conséquent, il est nécessaire que les
équipes de microservices réfléchissent constamment sur la manière dont les pannes du service
affectent l’expérience de l’utilisateur. Alors, nous constatons l’utilisation des techniques de
monitoring en temps réel pour détecter les échecs et la restauration du service est réalisée
automatiquement.
— Conception évolutive
Avec une application monolithique, toute modification nécessite une compilation et un dé-
ploiement de toute l’application. Avec les microservices, et grâce à leurs décompositions en
services, il suffit de redéployer les services modifiés. Ceci simplifie et accélère le processus de
publication et rend l’évolution de l’application plus fluide.
4 Domain driven design
Nous présentons dans cette partie le "domain driven design" qui va nous servir plus tard
dans la division de notre application en microservices. Le DDD a été introduit en 2003 par
Eric Evans [6]. C’est une approche de conception centrée sur le métier de l’application étant
donné qu’un système informatique qui se base sur des compétences métiers comble l’écart entre
la réalité de l’entreprise et le code. En DDD, le domaine (celui qui décrit votre métier) joue
13

II.5 Architecture orientée évènements
le rôle d’un langage ubiquitaire 2
pour faciliter la communication entre les développeurs et les
experts métiers et il présente le composant le plus important dans la conception de l’application.
Par ailleurs, la modélisation d’un domaine introduit l’utilisation du pattern contextes bornés
(bounded contexts). Ce pattern divise un grand modèle du domaine en contextes bornés centrés
sur des capacités métier. Nous utilisons les contextes bornés pour notre application. Nous
définissons les relations entre ces contextes à l’aide de Bounded Context Map. La figure II.1
montre comment l’outil Bounded Context Map est utilisé pour relier entre deux domaines. Les
liaisons expriment les dépendances entre les domaines.
Figure II.1 – carte de contexte
5 Architecture orientée évènements
Nous présentons dans cette partie l’architecture orientée évènements, appelée en anglais
l’architecture orientée évènements que nous utilisons pour assurer la consistance des données
dans un environnement distribué. EDA est un style d’architecture dans lequel un composant
logiciel s’exécute en réponse à la réception d’une ou plusieurs notifications d’évènement. Dans
cette architecture, l’information peut être propagée en temps quasi réel dans un environnement
hautement distribué.[7] Les composants d’EDA sont : un producteur, un consommateur, un
bus et un évènement. EDA est appelé aussi un système de messaging, où le message présente
l’évènement. Cette architecture présente plusieurs avantages :[8]
— un couplage faible entre le producteur et le consommateur, les deux ne se connaissent
pas.
2. Le langage ubiquitaire : un langage structuré autour du modèle de domaine qui est utilisé par tous les
membres de l’équipe pour connecter tous les activités de l’équipe avec le logiciel.
14

II.5 Architecture orientée évènements
— une communication asynchrone entre le consommateur et le producteur, le producteur
peut produire même si le consommateur n’est pas disponible.
— une communication non bloquante, le principe de " ﬁre and forget "
— une faible latence et équilibrage de charge garanti, plusieurs consommateurs peuvent
consommer du même canal.
Conclusion
Nous avons éclairci à travers ce chapitre les concepts de base reliés à une architecture micro-
services et à notre projet en général. Dans le prochain chapitre, nous abordons la spéciﬁcation
des besoins fonctionnels et non fonctionnels et nous détaillons nos microservices théoriquement
et techniquement.
15

Chapitre III
Chapitre 3 : Les microservices proposés
Plan
1 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.2 Backlog de produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.3 Les besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 19
2 Division Messaging Pro en microservices . . . . . . . . . . . . . . . 19
3 Planification des Sprints . . . . . . . . . . . . . . . . . . . . . . . . . 22
4 L’architecture de l’application en microservices . . . . . . . . . . . 23
5 Les choix technologiques . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1 Choix des frameworks de back-end . . . . . . . . . . . . . . . . . . . . 24
5.2 Choix des frameworks front-end . . . . . . . . . . . . . . . . . . . . . 26
5.3 L’architecture technique . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Introduction
Ce chapitre présente le sprint de démarrage au cours duquel nous spécifions nos besoins
fonctionnels et non fonctionnels, nous divisons l’application existante en microservices, nous
planifions notre "release" et nous fixons les choix technologiques qui vont nous servir pour
l’architecture globale des microservices. D’autres choix technologiques seront fixés durant les
sprints suivants selon le besoin spécifique de chaque microservice.
1 Spécification des besoins
La phase de spécification des besoins est l’une des étapes les plus importantes. Les autres
phases du cycle de développement dépendent des résultats élaborés durant cette phase. Pour
cela, au cours de ce chapitre, nous allons identifier les acteurs de notre système, recueillir les
besoins fonctionnels et non fonctionnels de notre application.
16

III.1 Spécification des besoins
1.1 Identification des acteurs
Messaging Pro dispose de deux types d’acteurs, des acteurs principaux et des acteurs se-
condaires : Les acteurs principaux de MessagingPro sont :
— L’administrateur : c’est l’utilisateur qui a le droit de gérer les paquets et gérer les comptes
utilisateurs.
— L’administrateur supérieur hérite tous les droits de l’administrateur et il gère les comptes
clients et les comptes administrateur.
— L’utilisateur a le droit de gérer les campagnes SMS et vocales ainsi que gérer les listes
des contacts.
Messaging Pro interagit avec deux acteurs secondaires pour envoyer les messages textuels et
les messages vocaux qui sont :
— Le SMSC : est l’abréviation de short Message Service Center. Il permet de gérer le
transfert de messages SMS entre les téléphones mobiles. Le protocole utilisé pour com-
muniquer avec l’SMSC est le SMPP (Short message Peer to Peer).
— L’OMS : est le serveur qui permet le transfert des messages vocaux, le protocole utilisé
pour communiquer avec l’OMS est le HTTP.
1.2 Backlog de produit
Après avoir recenser les besoins liés à notre application, nous décrivons dans cette partie le
tableau III.1 qui illustre le "product Backlog" de notre projet.
Tableau III.1 – Backlog de produit
ID User Story Effort
1 En tant quadministrateur supérieur je veux pouvoir ajouter un pa-
quet
5
2 En tant qu’administrateur supérieur je veux pouvoir modifier un
paquet
5
3 En tant qu’administrateur supérieur je veux pouvoir supprimer un
paquet
2
4 En tant qu’administrateur supérieur je veux pouvoir lister tous les
paquets
2
5 En tant qu’administrateur supérieur je veux pouvoir ajouter un
client
5
6 En tant qu’administrateur supérieur je veux pouvoir supprimer un
client
2
17

III.1 Spécification des besoins
7 En tant qu’administrateur supérieur je veux pouvoir modifier un
client
5
8 En tant qu’administrateur supérieur je veux pouvoir lister les
clients
2
9 En tant qu’administrateur supérieur je veux pouvoir ajouter un
administrateur
5
10 En tant qu’administrateur supérieur je veux pouvoir lister les ad-
minstrateurs
2
11 En tant qu’administrateur je veux pouvoir créer un utilisateur 5
12 En tant qu’administrateur je veux pouvoir activer un compte uti-
lisateur
1
13 En tant qu’administrateur je veux pouvoir désactiver un compte
utilisateur
1
14 En tant qu’administrateur je veux pouvoir lister les utilisateurs 2
15 En tant qu’utilisateur je veux pouvoir importer une liste des
contacts
21
16 En tant qu’utilisateur je veux pouvoir créer une liste des contacts
en ajoutant manuellement ces dérniers
8
17 En tant qu’utilisateur je veux pouvoir modifier une liste des
contacts
5
18 En tant qu’utilisateur je veux pouvoir supprimer une liste des
contacts
2
19 En tant qu’utilisateur je veux pouvoir lister toutes les listes des
contacts
2
20 En tant qu’utilisateur je veux pouvoir créer une campagne SMS 79
21 En tant qu’utilisateur je veux pouvoir annuler une campagne SMS 3
22 En tant qu’utilisateur je veux pouvoir suspendre une campagne
SMS
5
23 En tant qu’utilisateur je veux pouvoir reprendre une campagne
SMS
5
24 En tant qu’utilisateur je veux pouvoir lister toutes les campagnes
SMS
2
25 En tant qu’utilisateur je veux pouvoir créer une campagne vocale 79
18

III.2 Division Messaging Pro en microservices
26 En tant qu’utilisateur je veux pouvoir suspendre une campagne
vocale
5
27 En tant qu’utilisateur je veux pouvoir reprendre une campagne vo-
cale
5
28 En tant qu’utilisateur je veux pouvoir lister toutes les campagnes
vocales
2
29 En tant qu’utilisateur je veux pouvoir annuler une campagne vocale 3
Nous utilisons un "story point" pour estimer l’effort nécessaire à une équipe pour implémen-
ter une fonctionnalité. Trois éléments doivent être pris en compte pour l’estimation : l’effort
pour le développement, la complexité et le risque. Pour estimer la taille d’une fonctionnalité
nous allons choisir la séquence de Fibbonacci 1
qui est la plus utilisée.
1.3 Les besoins non fonctionnels
Les besoins non fonctionnels de l’application sont :
— Tolérance aux pannes
Messaging Pro doit être capable à fonctionner même s’il existe des microservices en défaillance.
— Mise à l’échelle
Messaging Pro doit permettre une mise à l’échelle ciblée, c’est-à-dire nous n’avons pas besoin
de mettre à l’échelle toute l’application, mais seulement les microservices qui ont besoin d’y
être.
— Maintenabilité
L’architecture doit permettre l’évolution et assurer l’extensibilité de l’application.
— Temps de réponse
Messaging Pro doit avoir un temps minimal pour rendre une vue dans le navigateur.
— Charte graphique
Les interfaces de Messaging Pro doivent respecter la charte graphique d’Orange.
2 Division Messaging Pro en microservices
Pour passer d’une architecture monolithique vers une architecture en microservices, nous
suivons le pattern des contextes bornés du DDD, décrit précédemment dans le chapitre 2 section
4. Nous partons donc du diagramme de domaine de l’application existante et nous définissons
1. La Suite de Fibbonacci : 1,2,3,5,8,13,21,34,45,79
19

nos contextes bornés. Nous présentons dans La ﬁgure III.1 chaque contexte avec une couleur
diﬀérente. La couleur jaune présente le contexte des clients, la couleur orange présente le
contexte de listes de contacts, la couleur rose présente le contexte utilisateur, la couleur bleu
présente le contexte des paquets, la couleur gris présente le contexte des campagnes vocales, la
couleur violet présente le contexte des campagnes SMS.
20

Figure III.1 – Modèle du domaine de MessagingPro
21

III.3 Planification des Sprints
Nous présentons dans la figure III.2 notre carte de mapping simplifiée où les relations entre
les contextes sont affichées sans noms et sans multiplicités.
Figure III.2 – Carte de contexte de Messaging Pro
L’utilisation du pattern Bounded context nous a permis d’avoir six microservices : SMSCampaign-
Service, VoiceCampaign-Service, Utilisateur-Service, Bundle-Service, Customer-Service, Contact-
Service.
3 Planification des Sprints
En se basant sur notre backlog product et sur la décomposition de notre produit en micro-
services, nous divisons notre Release en 4 sprints comme le montre le tableau III.2.
Tableau III.2 – Partitionnement des user stories par sprint
Sprint 1 (3
seamines)
Sprint 2 (3
semaines)
sprint 3 (4
semaines)
sprint 4 (4
semaines)
User Story ID 1, 2, 3, 4, 5, 6, 7, 8. 9, 10, 11, 12, 13,
14, 15, 16, 17, 18,
19.
20, 21, 22, 23, 24. 25, 26, 26, 27, 28,
29.
Nous développons au cours du chaque sprint un ou plusieurs microservices.
22

III.4 L’architecture de l’application en microservices
4 L’architecture de l’application en microservices
La figure III.3 présente les composants nécessaires pour une architecture microservice.
Figure III.3 – Les composants d’une architecture microservices
Elle est composée :
— d’un serveur de configuration "Config Server" qui permet d’externaliser et de centraliser
les fichiers des configurations de chaque microservice. Ceci permet d’avoir une configu-
ration partagée et évolutive indépendamment des application. Chaque microservice doit
chercher ses propriétés de configuration auprès du serveur de configuration.
— d’un service de découverte "Service Discovery" qui garde le catalogue des instances dis-
ponibles de chaque microservice. Il dispose de ses propres mécanismes pour avoir le
catalogue à jour à tout moment.
— d’un équilibreur de charge "Load Balancer", c’est le responsable de router et répartir
la charge entre plusieurs instances disponibles. Pour avoir la liste de ces dernières, il
consulte le serveur de découverte.
— d’un disjoncteur de circuit "circuit breaker", l’utilisation de ce composant est essentielle
pour garantir la caractéristique "Design for Failure" évoquée précédemment dans Cha-
pitre 2, section 2.3. En effet, il permet d’éviter l’échec de l’application au cas où un
microservice a cessé de fonctionner.
— d’API Passerelle "API Gateway" qui présente un unique point d’entrée au système.
L’API Gateway encapsule l’architecture du système interne et fournit une API adaptée
23

III.5 Les choix technologiques
pour chaque client.
5 Les choix technologiques
Nous présentons, dans cette partie, les technologies globales avec lesquels nous réalisons
notre projet.
5.1 Choix des frameworks de back-end
Avec une architecture microservices, chaque microservice peut être développé avec une tech-
nologie différente. Or, pour garantir que notre application continuera à fonctionner sur l’infra-
structure existante d’Orange, ainsi pour que l’équipe existante prenne le relais pour terminer
le projet qui est initié dans un contexte de recherche, nous avons décidé de développer tous les
microservices avec la technologie Java/JEE. Par ailleurs, il existe trois frameworks populaires
pour développer une application en microservices : Dropwizard, Spring Boot et WildFly Swarm
[3]. Dans notre étude, nous nous intéressons seulement aux deux frameworks les plus matures
Dropwizard et Spring Boot. WlidFly Swarm est un projet trop jeune la version 1.0.0 Final est
lancée en (Juin, 2016) et la communauté est beaucoup plus réduite pour ce Framework.
5.1.1 Spring Boot
C’est un framework java créé par l’équipe Pivotal qui permet de simplifier le démarrage et
le développement de nouvelles applications Spring en réduisant la complexité de configuration
[9]. Spring Boot offre les avantages suivants [10] :
— Faciliter la création des applications Spring.
— Offrir un serveur d’application intégré (Tomcat, Jetty), donc nous n’avons pas besoin
de la déployer tant que fichier war.
— Fournir un "starter" POM pour simplifier la configuration Maven.
— Pas des fichiers XML à configurer.
— Fournir des fonctionnalités prêtes à la production, comme des métriques et contrôles de
santé (health check).
5.1.2 Dropwizard
Dropwizard est créé par Coda Hale à Yammer en 2011 pour alimenter les architectures des
systèmes distribués de l’entreprise (appelé maintenant Microservices). Le projet a commencé
par le rassemblement des quelques bibliothèques pour écrire des web services REST puis il a
24

évolué en gardant toujours son identité comme un framework web minimal, facile à utiliser et
prêt à la production.
Or, Spring Boot présente de nombreux avantages compétitifs. En effet, Spring boot offre une
gamme riche des choix au niveau de serveur d’application utilisé, des implémentations REST,
des outils de manipulation des JSON, des outils de logging et plusieurs autres intégrations [11].
Nous choisissons donc le spring boot comme étant notre framework backend.
Notre deuxième choix technologique est Spring Cloud qui fournit des outils facilitant le
développement de certains patterns communs dans une architecture distribuée comme la ges-
tion de configuration, la découverte des services (Service discovery) et le coupe circuit (circuit
breaker). Nous utilisons Spring Cloud pour rependre aux exigences et aux patterns liés à une
architecture microservices. Une liste des composants requis pour notre architecture sera décrite
dans le tableau III.3. Nous notons que la comparaison entre Eureka, Consul et Zookeeper est
Tableau III.3 – Les composants d’une architecture microservice et l’apport du Spring cloud
Composant Solution offerte par Spring cloud choix effectué
Service de découverte Netflix, Consul, Zookeeper Consul
Circuit breaker Netflix Hystrix Netflix Hystrix
Routage dynamique et équilibreur de charge Netflix Ribbon Netflix Ribbon
Serveur de configuration Spring cloud ConfigServer Spring cloud ConfigServer
fournie par l’annexe A. En outre, Spring Cloud offre un autre projet ”Spring Cloud Stream”
qui permet de développer des microservices à base de messages ”message-driven microservices”.
Spring Cloud Stream est basé sur Spring Intégration pour pouvoir se connecter aux ńmessages
brokerż 2
. Il possède trois "messages broker" Kafka 3
, ActiveMQ 4
et RabbitMQ 5
. Nous présen-
tons dans la prochaine section une étude comparative entre ces outils.
5.1.3 Choix de Message Broker
Pour la comparaison, plusieurs analyses comparatives de ces technologies sont disponibles.
Nous nous somme référés à une comparaison faite par [12]. Cette comparaison montre que :
— ActiveMQ, qui est la solution actuelle, présente des problèmes de scalabilité énormes.
En effet, l’ajout des threads et des noeuds a dégradé ses performances.
2. Un Message Broker (en anglais) appelé en français courtier de messages c’est un système d’échange de
messages entre applications, comprenant un dispositif de transport des messages, un moteur de règles et un
moteur de formattage.
3. Kafka est un système de messagerie distribué, écrit en scala, originellement développé chez LinkedIn, et
maintenu au sein de la fondation Apache depuis 2012.
4. ActiveMQ C’est un projet open source Apache qui contient un client JMS et un "message broker". Il est
développé en JAVA
5. RabbitMQ Il s’agit d’un projet Open Source d’implémentation de message broker. Le serveur est pro-
grammé en Erlang, un langage de programmation fonctionnelle.
25

— RabbitMQ a montré ses limites avec 3 600 messages/s, l’ajout des threads et des noeuds
aussi n’a pas amélioré les performances.
— Kafka offre les meilleures performances en terme débit d’envoi et de réception des mes-
sages et présente une meilleur scalabilité. Nous choisissons donc Kafka.
5.2 Choix des frameworks front-end
Après avoir choisir les deux frameworks Spring Boot et Spring Cloud pour le backend, nous
devons maintenant choisir une plateforme pour notre application frontend. Plusieurs technolo-
gies se présentent, mais notre comparaison va être restreinte sur Angular 2 et React puisque
ces deux plateformes sont open source et elles sont les plus populaires et les plus utilisées. Notre
comparaison est focalisée sur deux points essentiels liés à nos besoins techniques :
— L’amélioration du temps de réponse de notre application.
— Avoir un code maintenable, modulaire et compréhensible par les nouveaux ingénieurs.
5.2.1 Angular 2
Angular 2 est l’un des frameworks le plus avancé pour le web crée par Google. Angular 2
est le résultat de reconstruction d’Angular JS, développé avec TypeScript, et sa version stable
était lancée en 14 Septembre 2016. Angular 2 a apporté plusieurs améliorations par rapport à
son prédécesseur Angular JS avec des performances améliorées, une modularité accrue, du code
plus expressif et un respect des nouveaux standards du web. [13]
5.2.2 React
React est l’une des bibliothèques JavaScript les plus populaires développées par Facebook
pour construire des interfaces utilisateurs. React permet de créer des composants réutilisables
pour construire des interfaces graphiques. [14]
Comme nous avons déjà mentionné les deux critères choisis pour la comparaison sont la per-
formance et la modularité du code. En ce qui concerne la performance, la figure III.4 [15]
montre une analyse du temps nécessaire pour afficher un certain nombre d’articles. L’analyse
est faite pour comparer 4 framworks Angular 2, Angular JS, React JS et Blaze, mais nous nous
intéressons seulement aux résultats d’Angular 2 et React JS.
26

Figure III.4 – Courbe de performance React VS Angular VS Angular JS VS Blaze
Selon la courbe, Angular est le plus performant, avec l’affichage de 50 000 articles dans
moins de 1000 millisecondes. En outre, en ce qui concerne la modularité du code et la lisibilité,
Angular utilise Type Script qui permet une meilleure organisation du code avec les interfaces et
un typage statique. Angular et React sont à base de composants ce qui permet d’avoir un code
modulaire et réutilisable. Après l’évaluation de ces deux critères, nous avons choisi Angular 2.
Nous utilisons aussi le framework Boosted Orange [16] pour la charte graphique, Git [17] afin
de gérer les différentes versions. et l’outil Junit pour les tests Unitaires. Ce dernier répond au
développement piloté par les tests appelés en anglais (Le TDD : Test Driven Development) qui
est fortement recommandé pour produire un code d’haute qualité et fiable.
5.3 L’architecture technique
Après avoir fixé les choix techniques nécessaires pour concevoir une architecture en microser-
vices, nous avons besoin d’avoir une image globale sur l’architecture cible et son fonctionnement.
La figure III.5 présente l’architecture qui résume l’étude technique évoquée précédemment.
27

Figure III.5 – Architecture technique minimale
Cette architecture minimale se compose alors d’un frontend développé avec Angular 2 et
d’un backend développé avec Spring Boot et Spring Cloud.
D’abord, le microservice consulte le serveur de conﬁguration pour avoir sa propre conﬁgu-
ration. Une fois que le service est démarré, l’agent "consule" le détecte et l’enregistre dans le
serveur de découverte. Pour rediriger une requête de L’API Gateway vers un microservice "A" le
"load balancer" consulte le service de découverte pour connaître toutes les instances disponibles
du microservice concerné, dans ce cadre plusieurs situations sont envisagées :
— Si plusieurs instances d’un service sont disponibles, le load balancer Ribbon choisit une
instance selon l’algorithme "Round Robin".
— Si le service n’a pas répondu (à cause d’un "time out" ou une erreur de communication),
le circuit breaker hystrix redirige l’appel vers une autre instance, si aucune autre instance
n’est disponible, hystrix redirige la requête vers une méthode de "fallback" interne du
service consommateur (L’API Gateway dans notre cas).
— Si, après plusieurs tentatives, le service n’arrive pas à répondre, Hystrix ouvre le circuit et
appelle directement la méthode "fallback". Puis, il envoie un nombre limité des requêtes
28

au service pour déterminer s’il est à nouveau disponible.
Nous notons que cette architecture présente une ébauche. Elle sera enrichie chaque fois que
nous développons les microservices.
Conclusion
Durant ce chapitre, nous avons d’abord spécifié nos besoins ce qui nous a aidé à avoir une
vision plus claire et une compréhension plus profonde du sujet. Ensuite, nous avons présenté
les microservices qui composent notre application. Puis, nous avons planifié nos sprints. Après,
nous avons présenté l’architecture globale d’une application en microservices. Enfin, nous avons
spécifié les technologies utilisées tout au long du projet et nous avons présenté l’architecture
technique cible. Dans le chapitre suivant, nous abordons les deux premiers sprints.
29

Chapitre IV
Chapitre 4 : Microservices utilitaires
Plan
1 Microservice Bundle-Service . . . . . . . . . . . . . . . . . . . . . . . 31
1.1 Analyse fonctionnelle de microservice " Bundle-Service " . . . . . . . . 31
1.2 Conception de microservice Bundle-Service . . . . . . . . . . . . . . . 32
1.3 Réalisation de microservice "Bundle-Service" . . . . . . . . . . . . . . 34
2 Microservice PhoneNumber-Service . . . . . . . . . . . . . . . . . . 36
2.1 Conception de microservice "PhoneNumber-Service" . . . . . . . . . . 37
2.2 Implémentation de microservice "PhoneNumber-Service" . . . . . . . . 38
3 Microservice Customer-Service . . . . . . . . . . . . . . . . . . . . . 39
3.1 Analyse fonctionnelle de microservice "Customer-Service" . . . . . . . 39
3.2 Conception de microservice "Customer-Service" . . . . . . . . . . . . . 40
3.3 Réalisation de microservice "Customer-Service" . . . . . . . . . . . . . 41
4 Microservice User-Service . . . . . . . . . . . . . . . . . . . . . . . . 42
4.1 Analyse fonctionnelle de microservice "User-Service" . . . . . . . . . . 42
4.2 Conception de microservice "User-Service" . . . . . . . . . . . . . . . . 43
4.3 Réalisation de microservice "User-Service" . . . . . . . . . . . . . . . . 46
5 Microservice "ContactList-service" . . . . . . . . . . . . . . . . . . . 49
5.1 Analyse fonctionnelle de microservice "ContactList-Service" . . . . . . 49
5.2 Conception de microservice "ContactList-Service" . . . . . . . . . . . . 51
5.3 Réalisation de microservice "ContactList-Service" . . . . . . . . . . . . 53
Introduction
Au cours de ce chapitre, nous détaillons les étapes eﬀectuées durant le premier et le deuxième
sprint. L’objectif du premier sprint est la réalisation du microservice "Bundle-Servcie","PhoneNumber-
Service"et "Customer-Service". Quant à l’objectif du deuxième sprint, il s’agit de réaliser les mi-
croservices "User-Service" et "ContactList-Service". Pour chaque microservice, nous présentons
30

IV.1 Microservice Bundle-Service
l’analyse des besoins, la conception proposée ainsi que les interfaces homme-machine dévelop-
pées.
1 Microservice Bundle-Service
Dans cette partie, nous décrivons la démarche suivie pour concevoir et développer notre pre-
mier microservice Bundle-Service. Nous rappelons que ce service permet de gérer les paquets. 1
1.1 Analyse fonctionnelle de microservice " Bundle-Service "
Un administrateur supérieur a le droit de créer un nouveau paquet, de le modifier, de le
supprimer et de consulter la liste des paquets existants. La figure IV.1 présente le diagramme
de cas d’utilisation relatif au microservice Bundle-Service.
Figure IV.1 – Diagramme cas d’utilisation du microservice Bundle-service
1. Paquet : Un client doit acheter un paquet pour pouvoir lancer des campagnes. Chaque paquet a son prix
, et définit les prix de chaque type d’SMS et d’appel vocal.
31

1.2 Conception de microservice Bundle-Service
Nous détaillons, dans cette section, la phase de conception de notre microservice Bundle-
Service. Nous présentons l’architecture logicielle, le diagramme de package et le diagramme de
classes.
1.2.1 Architecture logicielle de microservice Bundle Service
La ﬁgure IV.2 présente l’architecture logicielle de microservice Bund Service qui est consti-
tuée de trois couches :
— IntegrationLayer : Elle joue le rôle de façade du microservice, elle assure la communi-
cation avec les autres composants du système et elle délègue le traitement à la couche
Business Logic Layer.
— Business Logic Layer : Elle est la responsable du logique métier.
— Data Aceess Layer : Elle est la responsable de la communication avec le serveur de
stockage des données.
Figure IV.2 – Architecture logicielle de microservice Bundle-Service
1.2.2 Diagramme de package "Bundle-Service"
Bundle-Service présente 4 packages qui sont présentés dans la ﬁgure IV.3 comme suit :
— com.olt.domain : présente le package de nos entités.
32

— com.olt.repository : présente le package d’implémentation des méthodes utiles pour l’ac-
cès à la base de données.
— com.olt.service : présente le package de notre logique métier.
— com.olt.controller : présente notre REST API.
Figure IV.3 – Diagramme de package de Bundle-Service
1.2.3 Diagramme de classes de microservice "BundleService"
La ﬁgure IV.4 présente le diagramme de classes de microservice Bundle-Service.
33

Figure IV.4 – Diagramme de classes de microservices "Bundle-service"
1.3 Réalisation de microservice "Bundle-Service"
Nous présentons dans cette partie l’architecture technique de microservice "Bundle-Service",
les interfaces homme/machines implémentées ainsi que les tests unitaires développés.
1.3.1 Architecture technique du microservice "Bundle-Service"
Pour mettre en place notre microservice "Bundle-Service", nous choisissons les outils tech-
nologiques présentés dans la ﬁgure IV.5 :
34

Figure IV.5 – Architecture technique de microservice "Bundle-Service"
1.3.2 Implémentation de microservice "Bundle-Service"
Nous exposons les interfaces liées au microservice Bundles-Service. La ﬁgure IV.6 présente
l’interface d’ajout d’un nouveau paquet.
Figure IV.6 – Interface d’ajout d’un nouveau Bundle
Une fois le paquet est créé, il est ajouté à la liste des paquets existants. Pour chaque paquet,
nous avons la possibilité de l’éditer ou bien de le supprimer, voir ﬁgure IV.7.
35

IV.2 Microservice PhoneNumber-Service
Figure IV.7 – Liste des paquets
1.3.3 Tests de microservice "Bundle-Service"
Les résultats des tests sont présentés dans la figure IV.8. Cette figure montre la réussite
des 5 tests unitaires. Ces testes permettent de tester l’ajout, la modification , la suppression, la
recherche par un identifiant, et la recherche de tous les "Bundles".
Figure IV.8 – Tests unitaire de "Bundle-Service"
2 Microservice PhoneNumber-Service
Nous avons eu recours à l’externalisation de la vérification de numéro de téléphone dans un
microservice à part vu qu’il est un traitement sollicité aux plusieurs niveaux de notre système.
Cette externalisation permet d’avoir un code faiblement couplé où le changement au niveau de
cette fonctionnalité va impliquer seulement le changement de ce microservice. Le microservice
PhoneNumber-Service est le responsable de la vérification de la validité et le type d’un numéro
de téléphone. Ce microservice expose une seule interface avec une seule méthode, elle permet
de retourner le type de numéro de téléphone. La méthode retourne :
— 0 si le numéro est Invalide
— 1 si le numéro est Onnet (appartient à l’opérateur orange)
— 2 si le numéro est Offnet (appartient à un autre opérateur local)
36

— 3 si le numéro est International.
Dans la suite, nous présentons seulement la conception de ce microservice et les tests effectués
pour valider son fonctionnement.
2.1 Conception de microservice "PhoneNumber-Service"
Pour illustrer notre conception nous décrivons, dans cette partie, l’architecture logicielle et
le diagramme de package de microservice " PhoneNumber-Service ".
2.1.1 Architecture logicielle de microservice "PhoneNumberService"
La figure IV.9 montre l’architecture logicielle de microservice PhoneNumber-Service. Ce
dernier dispose seulement de deux couches logicielles :
— Integration Layer : c’est la couche qui permet d’assurer la communication de notre
microservice avec l’environnement externe.
— Business Layer : c’est la couche qui encapsule la logique métier. Dans notre cas, c’est la
vérification de validité du numéro de téléphone.
Figure IV.9 – Architecture logicielle de microservice "PhoneNumber-Service"
2.1.2 Diagramme de package de microservice "phoneNumber-Service"
La figure IV.10 montre le diagramme de package de notre microservice.
37

Figure IV.10 – Diagramme de package de microservice "PhoneNumber-Service"
2.2 Implémentation de microservice "PhoneNumber-Service"
Pour ce microservice, nous utilisons les technologies déjà décrites dans le chapitre 3 section
5, nous ajoutons la librairie java de Google " libphonenumber" qui permet de vérifier les numéros
des téléphones. La figure IV.11 présente les résultats des tests unitaires développés pour tester
le fonctionnement de ce microservice. Ces tests consistent à tester le type d’un numéro , de
tester la non validité d’un numéro, et tester le bon fonctionnement des expressions régulières
utilisées dans le fichier de configuration pour définir le format du numéro.
38

IV.3 Microservice Customer-Service
Figure IV.11 – Les test unitaire du microservice phoneNumber-Service
3 Microservice Customer-Service
3.1 Analyse fonctionnelle de microservice "Customer-Service"
Ce microservice concerne l’administrateur supérieur qui a le droit de créer un nouveau
client, de le modiﬁer, de le supprimer et de consulter la liste des clients existants. Un compte
client représente le compte créé pour l’entreprise lors de son inscription sur notre plateforme.
Le diagramme ci-dessous montre le diagramme de cas d’utilisation de microservice Customer-
Service.
39

Figure IV.12 – Diagramme de cas d’utilisation de microservice "Customer-Service"
3.2 Conception de microservice "Customer-Service"
Nous présentons, dans cette section, le modèle de domaine de ce microservice. Nous notons
que l’architecture logicielle de ce microservice est identique à celle de microservice "Bundle-
Service" c’est pour cette raison nous nous l’avons pas présentée. Le diagramme de classe de ce
microservice rassemble énormément à celui de "Bundle-Service", la diﬀérence se trouve princi-
palement au modèle de domaine. La ﬁgure IV.13 présente le modèle de domaine de microservice
customer-Service. Il contient une seule classe "customer" qui présente notre entité.
40

Figure IV.13 – Modèle de domaine de microservice "Customer-Service"
3.3 Réalisation de microservice "Customer-Service"
Nous présentons, dans ce qui suit, les interfaces développées et les tests unitaires effectués.
3.3.1 Implémentation de microservice "Customer-Service"
Les interfaces présentées par la figure IV.14 et la figure IV.15 présentent respectivement
l’interface de liste des clients inscrits dans la plateforme et le formulaire d’ajout d’un nouveau
client.
Figure IV.14 – Liste des clients
41

IV.4 Microservice User-Service
Figure IV.15 – Interface de création d’un client
3.3.2 Tests de microservice "Customer-Service"
La figure IV.16 présente les tests unitaire développés pour tester le microservice Customer-
Service. Ces tests permettent de tester la création, l’ajout, la modification et la recherche de
tous les clients.
Figure IV.16 – Interface de création d’un client
4 Microservice User-Service
4.1 Analyse fonctionnelle de microservice "User-Service"
Un administrateur a le droit de gérer les comptes utilisateur, il peut créer un nouveau
compte utilisateur, activer ou désactiver un compte utilisateur et lister tous les utilisateurs.
Un administrateur supérieur hérite les rôles d’un administrateur et en plus il peut ajouter un
compte administrateur et lister les administrateurs existants. La figure ci-dessous présente le
diagramme de cas d’utilisation de microservice "User-Service".
42

Figure IV.17 – Diagramme de cas d’utilisation de microservice "User-Service"
4.2 Conception de microservice "User-Service"
Nous présentons, dans cette partie,l’architecture logicielle, le modèle de domaine ainsi que
le diagramme de package de microservice "User-Service".
4.2.1 Architecture logicielle de microservice "User-Service"
L’architecture logicielle de microservice "User-Service" est semblable de celle de "Bundle-
Service". La seule diﬀérence entre les deux architectures c’est au niveau de la couche d’intégra-
tion. La ﬁgure IV.18 présente cette dernière. La couche d’intégration de ce microservice gère
43

deux types de communication :
— Synchrone en exposant une API Rest ;
— Asynchrone à travers un mécanisme de messaging, ce type de communication est essen-
tiel pour assurer la consistance de données avec les autres services.
Figure IV.18 – La couche d’intégration de microservice "User-Service"
4.2.2 Modèle de domaine de microservice "User-Service"
La ﬁgure IV.19 présente le modèle de domaine de microservice "User-Service".
Figure IV.19 – Modèle de domaine de microservice "User-Service"
44

4.2.3 Diagramme de package de microservice "User-Service"
La figure IV.20 présente le diagramme de package de microservice User-Service. Ce dernier
présente 6 packages, nous décrivons seulement les package les plus pertinents :
— com.olt.messageHandler : c’est le package responsable de la gestion des communications
asynchrones qui se basent sur des messages. Ce package comporte deux classes :
1. La classe ”CreationBalanceHandler” : elle gère les messages de création d’une cam-
pagne. En effet, lors de la création d’une nouvelle campagne, un message qui contient
l’identifiant de l’utilisateur et le coût de la campagne est créé et injecté dans le "mes-
sage broker". Cette classe consomme ce message et met à jour le solde de l’utilisateur
en lui soustrayant le coût de la campagne.
2. La classe "CancelCreationHandler" : elle gère les messages d’annulation d’une cam-
pagne. En effet, lors de l’annulation d’une campagne, un message qui contient l’iden-
tifiant de l’utilisateur et le montant à rajouter au solde de ce dernier est créé et
injecté dans le "message broker". Cette classe consomme ce message et met à jour le
solde en lui ajoutant le montant.
— com.olt.infrastructure : Ce package est le responsable de la configuration des "topics".
45

Figure IV.20 – Diagramme de package de "User-Service"
4.3 Réalisation de microservice "User-Service"
Dans cette section, nous présentons l’architecture technique de microservice User-Service
ainsi que son implémentation et les tests unitaires eﬀectués.
4.3.1 Architecture technique de microservice "User-Service"
La ﬁgure IV.21 présente l’architecture technique de microservice " User-Service ".
46

Figure IV.21 – Architecture technique de microservice "User-Service"
4.3.2 Implémentation de microservice "User-Service"
Nous présentons ci-dessous quelques interfaces implémentées relatives au microservice "User-
Service ". La ﬁgure IV.22 présente le formulaire d’ajout d’un nouvel utilisateur, ainsi que la
ﬁgure IV.23 présente l’interface de tous les utilisateurs. Il est possible d’activer un compte s’il
est désactivé et vice versa, comme il est possible de supprimer un utilisateur.
47

Figure IV.22 – Formulaire de création d’un nouveau utilisateur
Figure IV.23 – Liste de tous les utilisateurs
4.3.3 Tests de microservice "User-Service"
Pour tester le bon fonctionnement de ce microservice, nous présentons dans la ﬁgure IV.24
les résultats des tests unitaires développés. Ces tests permettent de tester l’ajout d’un utilisa-
teur et d’un administrateur, d’activer ou désactiver un compte utilisateur, de trouver tous les
utilisateurs et les administrateurs, de mettre à jour la balance d’un utilisateur soit en ajoutant
ou en soustrayant un montant et de lire à partir du Kafka.
48

IV.5 Microservice "ContactList-service"
Figure IV.24 – Tests unitaires de microservice "User-Service"
5 Microservice "ContactList-service"
Le développement de ContactList-Service est très similaire au développement des microser-
vices précédents. Pour cette raison, nous ne présentons que les diagrammes que nous trouvons
pertinents.
5.1 Analyse fonctionnelle de microservice "ContactList-Service"
Un utilisateur a le droit de créer une liste de contacts soit en important un fichier xlsx ou
csv 2
, soit en ajoutant manuellement les contacts. Il peut aussi modifier une liste de contacts
existants, supprimer une liste et lister tous ces listes de contacts. Nous présentons dans la
suite le diagramme de cas d’utilisation de ce microservice ainsi que le diagramme de séquence
"Importer une liste des contacts".
5.1.1 Diagramme de cas d’utilisation de microservice "ContactList-Service"
Le diagramme de cas d’utilisation de microservice ContactList-Service est présenté dans la
figure IV.25.
2. CSV : Comma-Separated Values Un format informatique ouvert représentant des données tabulaires sous
forme de valeurs séparées par des virgules.
49

Figure IV.25 – Diagramme de cas d’utilisation de ContactList-Service
5.1.2 Diagramme séquence système "Importer une liste des contacts"
La ﬁgure suivante montre le diagramme de séquence système de cas d’utilisation "Importer
une liste de contacts"
50

Figure IV.26 – Diagramme de séquence système : Importer une liste de contacts
5.2 Conception de microservice "ContactList-Service"
Pour illustrer notre conception, nous présentons le modèle de domaine de microservice,
ainsi que le diagramme de composants. Nous ne présentons pas l’architecture logicielle de ce
microservice car elle est similaire à celle de "Bundle-Service".
5.2.1 Modèle de domaine de microservice "ContactList-Service"
La ﬁgure IV.27 illustre le modèle de domaine de microservices ContactList-Service
51

Figure IV.27 – Modèle de domaine de microservice "ContactList-Service"
5.2.2 Diagramme de composants de microservice "ContactList-Service"
Le diagramme de composants présenté dans la figure IV.28 illustre les communications de
notre microservice avec son environnement externe. La figure IV.28 montre que l’interface of-
ferte par le microservice PhoneNumber-Service est consommée par le microservice "ContactList-
Service", pour vérifier les numéros des téléphones, lors de l’importation de fichier de contacts
et par l’API Gateway lors de validation des numéros saisis dans le formulaire de création d’une
liste de contacts.
52

Figure IV.28 – Diagramme de composants
5.3 Réalisation de microservice "ContactList-Service"
Nous exposons dans cette partie l’implémentation ainsi que les tests développés pour ce
microservice.
5.3.1 Implémentation de microservice "ContactList-Service"
Dans cette section, nous présentons les interfaces développées pour le microservice "ContactList-
Service". La figure IV.29 montre la liste des toutes les listes de contacts d’un utilisateur.
Figure IV.29 – Liste des toutes les listes de contacts
La figure IV.30 présente le pop-up affiché à l’utilisateur pour pouvoir créer une liste en
important un fichier.
53

Figure IV.30 – Importer une liste de contacts
L’interface IV.31 présente le pop-up aﬃché à l’utilisateur pour pouvoir créer une liste de
contacts manuellement. Pour ajouter un contact, l’utilisateur clique sur le bouton "Add" pour
pouvoir saisir les informations liées à un contact comme indique la ﬁgure IV.32.
Figure IV.31 – Formulaire de création manuelle d’une liste de contacts
Figure IV.32 – Formulaire d’ajout d’un contact
54

5.3.2 Tests de microservice "ContactList-Service"
la figure IV.33 présente les résultats des tests unitaires développés pour tester le microservice
"ContactList-Service". Ces tests permettent de tester l’ajout d’une liste de contacts, l’ajout d’un
contact à une liste, l’importation des contacts à partir d’un fichier, la recherche d’une liste par
son identifiant ou bien par l’identifiant d’un utilisateur, la suppression de toutes les listes de
contacts et la recherche de toutes les listes.
Figure IV.33 – Tests unitaires de microservice "ContactList-Service"
Conclusion
Au cours de deux premiers sprints nous avons pu développer les microservices suivants :
"Bundle-Service", "PhoneNumber-Service", "Customer-Service", "User-Service" et "Contact-ListService".
Chaque microservice est développé comme étant un mini produit et intégré avec le frontend
à l’aide de l’API Gateway. Après avoir validé ces microservices avec le "product owner", nous
avons envoyé chaque microservice à son entrepôt Git (nous avons un entrepôt Git par micro-
service) qui se trouve dans un serveur Git distant pour qu’il soit automatiquement déployé.
Dans le chapitre suivant, nous étudions les deux derniers sprints.
55

Chapitre V
Chapitre 5 : Les microservices Voice et SMS
campaign
Plan
1 Microservice "SMSCampaign-Service" . . . . . . . . . . . . . . . . . 56
1.1 Analyse des besoins fonctionnels du "SMSCampaign-Service" . . . . . 57
1.2 Conception de microservice "SMSCampaign-Service" . . . . . . . . . . 60
1.3 Réalisation de microservice "SMSCampaign-Service" . . . . . . . . . . 66
2 Microservice "VoiceCampaign-Service" . . . . . . . . . . . . . . . . 71
2.1 Analyse fonctionnelle de microservice "VoiceCampaign-Service" . . . . 71
2.2 Conception de microservice "VoiceCampaign-Service" . . . . . . . . . 72
2.3 Réalisation de microservice "VoiceCampaign-Service" . . . . . . . . . . 78
Introduction
Après avoir développé les microservices : Bundle-Service, Customer-Service, User-Service,
Contact-ListService et PhoneNumber-Service, nous passons au développement des microser-
vices SMSCampaign-Service et VoiceCampaign-Service qui sont les plus importants dans notre
architecture. Ce chapitre présente les cycles de vie du troisième et quatrième Sprint,à savoir
l’analyse fonctionnelle détaillée, la conception, les choix technologiques, la réalisation et les
tests de chaque microservice.
1 Microservice "SMSCampaign-Service"
Dans cette partie, nous décrivons la démarche suivie pour concevoir et développer le mi-
croservice "SMSCampaign-Service". Ce dernier permet de gérer le cycle de vie d’une campagne
SMS.
56

V.1 Microservice "SMSCampaign-Service"
1.1 Analyse des besoins fonctionnels du "SMSCampaign-Service"
Un utilisateur a le droit de créer, de suspendre, de reprendre, d’annuler une campagne SMS.
Il peut aussi lister toutes ses campagnes SMS. La création d’une campagne SMS implique son
lancement ce qui nécessite l’intervention du serveur SMSC qui est un acteur secondaire.
1.1.1 Diagramme de cas d’utilisation de microservice "SMSCampaign-Service"
La figure V.1 présente le diagramme de cas d’utilisation relatif au microservice "SMSCampaign-
Service".
Figure V.1 – Diagramme de cas d’utilisation de microservice "SMSCampaign-Service"
1.1.2 Diagramme de séquence système "Créer une campagne SMS"
Créer une campagne SMS implique implicitement son lancement, soit immédiatement soit
dans la date planifiée. Nous présentons dans la figure V.2 le diagramme de séquence système
lié à la création d’une campagne SMS. Pour des raisons de clarté, le lancement dune campagne
est présenté par un autre diagramme de séquence. Au remplissage du formulaire l’utilisateur a
le droit d’attacher un fichier contenant des numéros, de choisir des listes des contacts ou/et de
taper les numéros manuellement. Nous supposons que l’utilisateur a choisi toutes les actions.
57

Figure V.2 – Diagramme de séquence système "créer une campagne SMS"
58

1.1.3 Diagramme de séquence système "lancer la campagne"
La ﬁgure V.3 présente le diagramme de séquence système "lancer une campagne" qui est
déjà référé dans le diagramme de séquence de la ﬁgure V.2
Figure V.3 – Diagramme de séquence lancer une campagne SMS
59

1.2 Conception de microservice "SMSCampaign-Service"
Nous détaillons dans cette partie, la conception de microservice SMSCampaign. Nous pré-
sentons au début les orientations architecturales que nous avons suivies pour développer ce
microservice. Dans un deuxième lieu, nous présentons le diagramme de domaine. Dans un troi-
sième lieu, nous présentons les deux diagrammes d’état qui illustrent les cycles de vie d’une
campagne SMS et un message SMS. Dans un quatrième lieu, nous présentons le diagramme
de composants qui illustre les interactions entre le microservice SMSCampaign et le reste du
système. Ensuite, nous présentons l’architecture fonctionnelle de microservice et nous finissons
par expliquer comment nous avons adopté une architecture orientée évènements dans notre
microservice.
1.2.1 Orientation architecturale de microservice "SMSCampaign-Service"
La complexité de ce microservice et la spécificité qu’il présente vu qu’il est un des microser-
vices coeurs de notre application nous ont poussé à bien étudier l’architecture que nous allons
appliquer pour réussir sa mise en place. D’abord, nous expliquons les types des communica-
tions acceptées par SMSCampaign-Service. Ensuite, nous présentons l’application d’architec-
ture orientée évènements dans l’implémentation de notre microservice.
1. Communication synchrone et asynchrone avec l’API Gateway :
Notre microservice "SMSCampaign-Service" expose deux modes de communication avec
l’API Gateway, une communication synchrone, en utilisant le protocole HTTP via une
API REST, et une communication asynchrone, basée sur les messages.
Nous utilisons la communication asynchrone pour la création des campagnes SMS. En
effet, la création d’une campagne SMS est l’une des fonctionnalités principales de notre
application. En effet, l’utilisateur peut consacrer un temps énorme pour le remplissage
du formulaire, or lui demander de le remplir une autre fois à cause de l’indisponibilité
du service le mène à un état de frustration. En outre, en utilisant une communication
synchrone, le message du retour vers l’utilisateur de création va dépendre de la réponse
du service "SMSCampaignService", or une campagne peut avoir des milliers de numéros
téléphoniques, leur insertion dans la base peut prendre un certain temps ce qui peut
retarder la réponse vers notre utilisateur final. Ceci peut générer un état de confusion
chez ce dernier qui pourrait recréer la campagne.
2. L’architecture orientée évènements dans SMSCampaign :
60

Nous avons déjà expliqué dans le chapitre 2 section 5 l’architecture EDA 1
. L’utilisation
de cette dernière dans notre microservice "SMSCampaign-Service" va nous garantir une
architecture faiblement couplée, évolutive, qui respecte le principe "single responsibility
principle" 2
où chaque fonctionnalité est encapsulée dans une classe. Une autre raison
pour adopter cette architecture c’est réduire les coûts des accès (lecture/écriture) à la
base de données. En eﬀet, la lecture à partir d’un "message broker" est beaucoup moins
coûteuse et beaucoup plus rapide que la lecture d’une base de données. Finalement
l’application communique avec le SMSC via le protocole smpp qui est un protocole
asynchrone donc les communications avec cet acteur doivent se faire avec un "message
broker".
1.2.2 Modèle de domaine de microservice "SMSCampaign-Service"
A l’aide du modèle de domaine, nous dégageons les objets à persister dans notre base de
données. La ﬁgure V.4 présente le modèle de domaine du "SMSCampaignService".
1. EDA : Event Driven Architecture
2. single responsibility principle :chaque classe doit avoir une responsabilité unique
61

Figure V.4 – Modèle de domaine du "SMSCampaignService"
1.2.3 Diagramme d’état d’une campagne SMS
Une campagne SMS peut avoir plusieurs états tout au long de son cycle de vie, les transitions
entre ces états sont représentées dans le diagramme d’état de la ﬁgure V.5
62

Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant l’architecture microservices

Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant l’architecture microservices

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant l’architecture microservices

Similar a Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant l’architecture microservices (20)

Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant l’architecture microservices