Rapportpfenawresfarhat 170812135554

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écifions
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 finissons 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 fin 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 " fire 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écification
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- 5
quet
2 En tant qu’administrateur supérieur je veux pouvoir modifier un 5
paquet
3 En tant qu’administrateur supérieur je veux pouvoir supprimer un 2
paquet
4 En tant qu’administrateur supérieur je veux pouvoir lister tous les 2
paquets
5 En tant qu’administrateur supérieur je veux pouvoir ajouter un 5
client
6 En tant qu’administrateur supérieur je veux pouvoir supprimer un 2
client
17
III.1 Spécification des besoins

7 En tant qu’administrateur supérieur je veux pouvoir modifier un 5
client
8 En tant qu’administrateur supérieur je veux pouvoir lister les 2
clients
9 En tant qu’administrateur supérieur je veux pouvoir ajouter un 5
administrateur
10 En tant qu’administrateur supérieur je veux pouvoir lister les ad- 2
minstrateurs
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- 1
lisateur
13 En tant qu’administrateur je veux pouvoir désactiver un compte 1
utilisateur
14 En tant qu’administrateur je veux pouvoir lister les utilisateurs 2
15 En tant qu’utilisateur je veux pouvoir importer une liste des 21
contacts
16 En tant qu’utilisateur je veux pouvoir créer une liste des contacts 8
en ajoutant manuellement ces dérniers
17 En tant qu’utilisateur je veux pouvoir modifier une liste des 5
contacts
18 En tant qu’utilisateur je veux pouvoir supprimer une liste des 2
contacts
19 En tant qu’utilisateur je veux pouvoir lister toutes les listes des 2
contacts
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 5
SMS
23 En tant qu’utilisateur je veux pouvoir reprendre une campagne 5
SMS
24 En tant qu’utilisateur je veux pouvoir lister toutes les campagnes 2
SMS
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 5
vocale
27 En tant qu’utilisateur je veux pouvoir reprendre une campagne vo- 5
cale
28 En tant qu’utilisateur je veux pouvoir lister toutes les campagnes 2
vocales
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 figure III.1 chaque contexte avec une couleur
diffé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 Sprint 2 (3 sprint 3 (4 sprint 4 (4

seamines) semaines) semaines) semaines)
User Story ID 1, 2, 3, 4, 5, 6, 7, 8. 9, 10, 11, 12, 13, 20, 21, 22, 23, 24. 25, 26, 26, 27, 28,
14, 15, 16, 17, 18, 29.
19.
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 configuration pour avoir sa propre configu-
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 effectué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 figure 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 figure 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 figure 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 figure 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 figure 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 figure 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 modifier, 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 différence se trouve princi-
palement au modèle de domaine. La figure 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 différence entre les deux architectures c’est au niveau de la couche d’intégra-
tion. La figure 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 figure 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 effectués.
4.3.1 Architecture technique de microservice "User-Service"
La figure 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 figure IV.22 présente le formulaire d’ajout d’un nouvel utilisateur, ainsi que la
figure 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 figure 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 figure 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 figure 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 affiché à 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 figure 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 figure 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 figure 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 effet, 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 figure 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 figure V.5
62
Figure V.5 – Diagramme d’état d’une campagne SMS
1.2.4 Diagramme d’état d’un message SMS
Un message 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 figure V.6
63
Figure V.6 – Diagramme d’état d’un message SMS
1.2.5 Architecture logicielle de microservice "SMSCampaign-Service"
L’architecture logicielle de microservice "SMSCampaign-Service" rassemble à celle de "User-

Service". Nous rappelons que la couche de d’intégration est responsable de la gestion :
— Des communications synchrones avec L’ API Gateway pour l’annulation, la suspension,
la reprise et le listage des campagnes.
— Des communications asynchrones avec L’API Gateway pour la création de SMSCam-
paign et avec le microservice "User-Service" pour mettre à jour de balance utilisateur.
— Des communications asynchrones avec le SMSC.
64
1.2.6 Le lancement de la campagne SMS
La figure V.7 explique le processus de création d’une campagne SMS et son lancement
au niveau de microservice "SMSCampaign-Service". La couleur bleu présente les classes de
"SMSCampaign-Service" et la couleur vert présente les topics 3 utilisées.
1. Une fois que l’API Gateway met le message contenant les détails de la campagne SMS
dans la topic, il est consommé par "SMSCampaignCreator".
2. L’SMSCampaignCreator crée un objet campagne ainsi que les SMS à envoyer, et il les
stocke dans la base de données.
3. Le "SMSCreator" produit un message avec l’identifiant de l’utilisateur et le coût de
la campagne, pour mettre à jour la balance de l’utilisateur, et le met dans la topic
"BalancUpdaterTopic". Nous parlons ici de la consistance à base d’évènement.
4. Une fois que la date du lancement correspond à la date actuelle "SMS Message loader"
charge la campagne et ses SMS à partir de la base.
5. Il crée une topic avec un nom qui se compose de "topic.+idCmpaign" dans laquelle il
met tous les SMS relatifs à cette campagne.
6. Ensuite, il met la campagne concernée dans une topic appelée "campaign".
7. Le "SMS Sender" qui est en écoute sur la topic "campaign", la détecte et la consomme.
8. Ensuite, il consomme tous les SMS de la campagne concernée.
9. Pour chaque SMS consommé, le "SMS sender" vérifie l’état actuel de la campagne.
— Si elle est en attente, il met à jour son état à "lancée" (il s’agit du premier message)
et il envoie le message au SMSC.
— Si elle est suspendue, il remet le message dans la topic.
— Si elle est démarrée il envoie le message au SMSC.
10. Le SMSC renvoie une réponse au "SMS Sender" avec une smppID, SmsCampaignId,
messageId. Le smppID est l’identifiant unique du message dans le SMSC.
11. "SMS Sender" reçoit le message envoyé par SMSC et il le met dans la "topic SMSSent".
12. "SMS Sent Event Handler" consomme le message depuis la topic "SMSSent".
13. "SMS Sent Event Handler" met à jour le message avec l’état envoyé, et il lui affecte une
smppID.
14. Après un certain moment, le SMSC enverra une autre réponse avec le smppID et l’état
de livraison de chaque SMS envoyé.
3. Topic : c’est un canal qui implémente la sémantique Publier/Abonner
65
15. "SMS Receiver" reçoit ce message et il le met dans la topic "SMS Deliv".
16. "SMSDeliv Event Handler" consomme le message depuis la topic "SMS Deliv" et il met
à jour le message concerné.
Figure V.7 – Processus de création et de lancement d’une campagne SMS
1.3 Réalisation de microservice "SMSCampaign-Service"

Nous présentons dans cette section nos choix techniques, l’architecture technique, l’implé-
mentation et les tests unitaires de microservice "SMSCampaign-service".
1.3.1 Choix techniques
1.3.1.1 Apache Camel

Apache Camel est un Framework open source d’intégration léger écrit en java, qui supporte
la plupart des patterns d’intégrations d’entreprise. Apache Camel réalise la transformation,
l’agrégation, l’enrichissement et le routage des messages entre les applications. Il propose aussi
un large nombre des connecteurs afin de pouvoir s’interfacer avec plusieurs protocoles et tech-
nologies.
Dans le cas de "SMSCampaign-service", Apache Camel va assurer la communication entre notre
microservice et le SMSC.
1.3.1.2 Choix de la base de données
66
Comme nous avons déjà précisé que la solution existante utilise MySQL qui présente plu-
sieurs problèmes de performances. En effet la fonctionnalité principale de Messaging Pro est
l’envoi des messages en masse donc la performance est une exigence. Or, l’utilisation des bases
de données relationnelles cause plusieurs problèmes de performance dont nous citons :
— Un inter-blocage, lors de l’ajout ou mise à jour d’une campagne, ce qui implique l’indis-
ponibilité des fonctionnalités de l’application.
— Les données sont en train d’augmenter d’une manière exponentielle, donc la scalabilité
est devenue indispensable pour l’application, or une base de données relationnelle pose
des problèmes de scalabilité.
— L’application est en plein essor, chaque jour des améliorations sont effectuées et des
fonctionnalités sont ajoutées. Ce qui implique des modifications à effectuer au niveau
des schémas des tables qui ne sont pas beaucoup appréciées par les administrateurs
des bases relationnelles. Tous ces problèmes mettent en question le choix de la base
relationnelle, et nous pousse à réfléchir aux bases des données NoSQL.
Il existe quatre types des bases des données NoSQL[18] :
— Clé/Valeur :
Les données sont représentées par un couple clé/valeur.
— Orienté Colonne :
Ce modèle rassemble a une base de données rationnelles sauf que dans cette famille le
nombre des colonnes peut varier dun enregistrement à un autre.
— Orienté document :
ce modèle étend le paradigme clef/valeur avec pour valeur un document Json/xml.
Chaque document est un objet qui contient un ou plusieurs champs, et chaque champ
contient une valeur typée
— Orienté graphe :
Ce modèle est basé sur les théories des graphes. Il sappuie sur la notion de nuds, de
relations et de propriétés qui leur sont rattachées.
Pour notre analyse, nous excluons la base de données clé/valeur qui est adéquate pour la
représentation des données simples avec une seule clé comme le cas de stockage de session
utilisateur. Nous excluons aussi la base de données orientée graphe qui est plus appropriée à la
représentation des données d’un réseau social, ce qui n’est pas notre cas. Et nous gardons pour
la comparaison les bases des données orientée colonnes et orientée document. Nous choisissons
de comparer les deux candidats les plus matures de chaque famille qui sont Mongodb coté base
de données orientée document et Cassandra coté base de données orientée colonnes.
Dans ce qui suit, nous présentons les raisons qui nous ont poussé à choisir MongoDB et ne pas
Cassandra :
67
— Nous sommes dans un contexte web où les données circulent avec des documents JSON 4
qui est le format de stockage d’une valeur dans MongoDB.
— Notre traitement présente plusieurs opérations de recherches, d’où le besoin d’indexer
les champs concernés, ce qui n’est pas possible avec Cassandra.
— Cassandra est plus performante avec les traitements analytiques, ce qui ne présente pas
notre besoin.
— Nous pouvons utilisé des modèles des données normalisées avec MongoDB grace à l’uti-
lisation de Réference pour présenter les relations entre deux documents.
1.3.1.3 Framework d’accès aux données

Pour simplifier la manipulation des données stockées dans une base MongoDB, nous avons
choisi de travailler avec Spring Data MongoDB qui est un projet Spring. Ce projet offre une
interaction abstraite et une gestion transparente de la persistance des objets java avec Mon-
goDB.
1.3.1.4 SMPPSIM
Pour simuler l’SMSC nous avons utilisé un outil open Source SMPPSim développé par
Selenium Software qui permet de tester les applications à base de Smpp.
1.3.2 Architecture technique de microservice "SMSCampaign-Service"
Nous présentons dans la figure V.8 l’architecture technique de microservice "SMSCampaign-

Service" ainsi que L’API Gateway qui a subi des modifications en intégrant Spring Cloud
Stream. Nous avons aussi présenté l’architecture technique du frontend pour avoir une vue
globale sur l’ensemble des communications.
4. JSON : JavaScript Object Notation.
68
Figure V.8 – Architecture technique de microservice "SMSCampaign-Service"
1.3.3 Implémentation de microservice "SMSCampaign-Service"
Nous présentons dans cette partie les interfaces réalisées pour pouvoir gérer une campagne
SMS. La figure V.9 présente le formulaire de création d’une nouvelle campagne SMS.
Figure V.9 – Formulaire de création d’une campagne SMS
La figure V.10 montre la liste des campagnes SMS créés. Quatre parmi 5 campagnes sont
lancées et terminées et une est suspendue avant d’être lancée.
69
Figure V.10 – Liste des campagnes SMS
Au niveau de l’interface présentée par la figure V.10 un utilisateur peut reprendre la dernière
campagne qui est suspendue comme il peut l’annuler. La figure V.11 montre le résultat d’une
action d’annulation de la dernière campagne.
Figure V.11 – La liste des campagnes SMS après annulation d’une campagne
1.3.4 Tests de microservice "SMSCampaign-Service"
Les résultats des tests unitaires effectués au cours de développement de ce microservice

sont présentés par la figure V.12. Ces tests ont permis de tester la création, l’annulation, la
suspension, la reprise d’une campagne SMS ainsi que la mise à jour du statut d’un message,
l’affichage de toutes les campagnes et la lecture à partir du Kafka.
70
V.2 Microservice "VoiceCampaign-Service"
Figure V.12 – Tests unitaires de microservice "SMSCampaign-Service"
2 Microservice "VoiceCampaign-Service"
Le microservice ""VoiceCampaign-Service" permet de gérer les campagnes vocales. Nous
décrivons dans cette partie la démarche suivie pour concevoir et développer ce microservice.
2.1 Analyse fonctionnelle de microservice "VoiceCampaign-Service"

Un utilisateur a le droit de lister toutes ses campagnes vocales, de créer, de suspendre,
de reprendre, d’annuler une campagne vocale. Nous contentons dans ce qui suit de présenter
seulement le diagramme de cas d’utilisation de microservice VoiceCampaign-Service.En effet
la création d’une campagne vocale est très similaire à celle de SMSCampaign-Service, la seule
différence se présente dans la communication avec l’acteur secondaire. Nous présentons dans la
conception un diagramme de séquence détaillé qui illustre cette communication. La figure V.13
présente le diagramme de cas d’utilisation de microservice VoiceCampaign-Service. La création
d’une campagne vocale nécessite l’intervention d’un acteur secondaire qui est le serveur OMS.
71
Figure V.13 – Diagramme de cas d’utilisation de "VoiceCampaign-Service"
2.2 Conception de microservice "VoiceCampaign-Service"

Au cours de cette phase, nous présentons la conception de microservice "VoiceCampaign-
Service". Nous gardons les mêmes orientations architecturales que celles de microservice "SMSCampaign-
Service". Nous présentons donc dans un premier lieu le modèle de domaine de ce microservice.
Dans un deuxième lieu, nous présentons le diagramme d’état d’un message vocal. Le diagramme
d’état d’une campagne vocale est le même de celui d’une campagne SMS. Nous finissons par
présenter les deux diagrammes de séquences d’envoi et d’annulation d’une campagne vocale.
2.2.1 Modèle de domaine
Nous présentons dans la figure V.14 le modèle de domaine de microservice "VoiceCampaign-

Service".
72
Figure V.14 – Modèle de domaine de microservice "voiceCampaign-Service"
2.2.2 Diagramme d’état d’un message vocal
Un message vocal peut avoir plusieurs statuts tout au long de son cycle de vie, La figure
V.15 illustre le diagramme d’état d’un message vocal.
73
Figure V.15 – Diagramme d’état d’un message vocal
2.2.3 Diagramme de séquence d’envoi d’une campagne vocale
L’envoi d’une campagne vocale se fait automatiquement une fois que la date du lancement
correspond à la date actuelle. Pour mieux illustrer le fonctionnement interne, nous avons re-
présenté l’enchaînement des actions avec un diagramme de séquence représenté dans la figure
V.16
74
Figure V.16 – Diagramme de séquence d’envoi d’une campagne vocale
75
L’OMS a besoin de deux fichiers pour son fonctionnement voiceMsg.vxml et voiceMsg.ccxml.

Le VoiceXML (Voice eXtensible Markup Language ou langage de balisage extensible vocal) est
un langage normalisé de programmation d’une application vocale.
Le CCXML (Call Control eXtensible Markup Language) est conçu pour informer le navigateur
de voix sur la façon de gérer le contrôle de téléphonie du canal vocal. Ces deux scripts ont été
fournis par l’équipe de MessagingPro.
2.2.4 Diagramme de séquence de microservice "CancelVoiceCampaign"
Nous représentons dans la figure V.17 le diagramme de séquence relatif à l’annulation d’une
campagne vocale.
76
Figure V.17 – Diagramme de séquence d’annulation d’une campagne vocale
77
2.3 Réalisation de microservice "VoiceCampaign-Service"

Pour la réalisation de microservice "VoiceCampaign-Service", nous gardons les choix tech-
niques déjà effectués précédemment et nous présentons l’architecture technique, les interfaces
implémentées ainsi que les tests effectués.
2.3.1 Architecture technique de microservice "VoiceCampaign-Service"
La figure ci-dessous présente l’architecture technique de microservice VoiceCampaign. Pour

avoir une image claire et globale nous présentons aussi le frontend et l’API Gateway.
Figure V.18 – Architecture Technique de microservice "VoiceCampaign-Service"
2.3.2 Implémentation de microservice "VoiceCampaign-Service"
Nous présentons dans ce qui suit les interfaces relatives au microservices "VoiceCampaign-
Service". La figure V.19 présente le formulaire de création d’une nouvelle campagne vocale.
78
Figure V.19 – Formulaire de création d’une nouvelle campagne vocale
La figure V.20 présente la liste des campagnes vocales et leurs statuts.
Figure V.20 – listes des campagnes vocales
2.3.3 Tests de microservice "VoiceCampaign-Service"
La figure V.21 montre la réussite des tests unitaires de microservice "VoiceCampaign-

Service". Ces tests ont permis de tester la création, l’annulation, la suspension, la reprise d’une
campagne vocale, ainsi que la mise à jour du statut d’un message, l’affichage de toutes les
campagnes et la lecture à partir du Kafka.
Figure V.21 – Tests de microservice "VoiceCampaign-Service"
79
Conclusion
Au cours de ce dernier chapitre, nous avons réussi à développer les deux microservices
principaux SMSCampaignService et VoiceCampaignService. L’architecture globale de notre
solution est présentée par l’annexe B. Nous avons réussi à tester les communications entre
notre SMSCampaignService et le SMSC en utilisant SMPPSIM déjà mentionné dans le chapitre
5 section 1.3.1.4. Nous avons aussi réussi à tester les communications entre le microservice
VoiceCampaign-Service et l’OMS. A la fin de chaque sprint, nous avons validé chaque produit
avec le "product owner" et nous avons envoyé chacun d’eux à un entrepôt Git distant pour être
automatiquement déployé en suivant la chaine de déploiement décrite dans l’annexe C.
80
Conclusion générale
Notre projet de fin d’études effectué au sein de Sofrecom a abouti à une refonte de l’ap-
plication "Messaging Pro". Nous avons commencé par une identification des limites liées à une
architecture microservice et un diagnostic technique de la solution existante. Ensuite, nous
étions responsables de la mise en place de l’architecture de la solution ainsi que la collecte
des besoins, la conception, la réalisation et les tests. Le travail réalisé n’a pas été une simple
migration mais une réécriture complète de la solution.
Nous avons pu résoudre à travers cette refonte les problèmes techniques liées à la base de
données, au message broker et au framework frontend existants ainsi que les limites liées à
l’architecture monolithique.
Le choix de l’Angular 2 comme un framework frontend a pu résoudre les problèmes liés au

temps de réponse posé par le framework Play, mais il a ralenti le temps du développement à
cause de la limitation des ressources d’apprentissage pour les traitements avancés. En parlant
des difficultés rencontrées avec Angular, nous pouvons citer le problème d’envoi plus qu’un
fichier dans une même requête.
A présent, notre solution répond pratiquement aux objectifs énoncés au début du stage.
En effet, nous avons pu développer les besoins fonctionnels et non fonctionnels initialement
dégagés et chaque microservice a pu passer par la chaîne de déploiement avec succès.
Faute de temps, nous avons travaillé que sur la refonte de la deuxième version de Messaging
Pro. Inclure les fonctionnalités ajoutées par la troisième version est le prochain objectif de
l’équipe. Il sera toujours intéressant d’ajouter un module pour superviser l’application et les
temps des réponses des composants de système.
81
Bibliographique
[1] Joshna Samala. Scrum Methodology - Quick Info. http://test-givethebest.

blogspot.com/2011/09/scrum-methodology-quick-info.html, (2011). [En
ligne ; consulté le 28-Avril-2017]. 8
[2] MuleSoft. Microservices and DevOps : Better together. https://www.mulesoft.

com/resources/api/microservices-devops-better-together. [En ligne ;
consulté le 30-Février-2017]. 11
[3] Christian Posta. Microservices for Java Developers. O’Reilly (2016). 11, 24
[4] Sam Newman. Building Microservices. O’Reilly (2015). 11
[5] Martin Fowler et James Lewis. Microservices. https://martinfowler.com/

articles/microservices.html, (2014). [En ligne ; consulté le 25-Février-2017]. 11
[6] Eric Evans. Domain-Driven Design. Addison Wesley (2003). 13
[7] David Chou. Using events in highly distributed architectures. Microsoft-The architecture
Journal (2008). [En ligne ; consulté le 30-Mars-2017]. 14
[8] Asanka Abeysinghe. Event-driven architecture : The path to increased agility and high
expandability. White paper WSO2 (2016). 14
[9] Siva Prasad Reddy Katamreddy. Why Spring Boot. https://dzone.com/

articles/why-springboot, (2016). 24
[10] Pivotal Software. Spring Boot. https://projects.spring.io/

spring-boot/, (2016). 24
[11] 25
[12] Adam Warski. Evaluating persistent, replicated message queues. https://

softwaremill.com/mqperf/, (2015). [En ligne ; consulté le 24-Mars-2017]. 25
[13] Alexandre Hebert et Dmytro Podyachiy. ANGULAR 2 PRÉSEN-

TATION. http://blog.xebia.fr/2015/12/14/angular-2-presentation/,
(2015). [En ligne ; consulté le 03-Mai-2017]. 26
[14] React. https://facebook.github.io/react/. [En ligne ; consulté le 03-Mai-2017].

26
[15] Shawn McKay. Comparing Performance of Blaze, React, Angular-Meteor and Angular
2 with Meteor. http://tiny.cc/7kclly, (2015). [En ligne ; consulté le 03-Mai-2017].
26
82
Bibliographique
[16] http://boosted.orange.com/. [En ligne ; consulté le 05-Février-2017]. 27
[17] https://git-scm.com/. [En ligne ; consulté le 05-Février-2017]. 27
[18] Amine Chaghal. 5 minutes pour comprendre. http://blog.neoxia.com/

nosql-5-minutes-pour-comprendre/, (2011). [En ligne ; consulté le 15-Mai-2017].
67
[19] HashiCorp. Introduction to Consul. https://www.consul.io/intro/. [En ligne ;

consulté le 05-Mars-2017]. 85
[20] Spring Cloud Consul. https://cloud.spring.io/spring-cloud-consul/. [En

ligne ; consulté le 05-Mars-2017]. 85
[21] Spring Cloud Zookeeper. https://cloud.spring.io/

spring-cloud-zookeeper/. [En ligne ; consulté le 05-Mars-2017]. 85
[22] Spring Cloud Netflix. http://cloud.spring.io/spring-cloud-netflix/

spring-cloud-netflix.html. [En ligne ; consulté le 07-Février-2017]. 85
[23] https://groups.google.com/forum/#!topic/consul-tool/fsLGavCv-j8.
[En ligne ; consulté le 06-Mars-2017]. 85
[24] Chris Richardson et Floyd Smith. Microservices From Design to Deployment.

NGINX, Inc (2016). 85
[25] Ivan Glushkov. ZooKeeper vs Consul. http://www.slideshare.net/

IvanGlushkov/zookeeper-vs-consul-41882991, (2014). [En ligne ; consulté le
05-Mars-2017]. 87
83
Glossaire
— REST : REpresentational state transfer
— BPEL : Business Process Execution Language
— HTTP : Hypertext Transfer Protocol
— WS : Web Service
— DDD : Domain Driven Design
— EDA : Event Driven architecture
— POC : proof de concept
— DAO : Data Access Layer
— ORM : Object-relational mapping
— API : Application Programming Interface
— IHM : Interface Homme Machine
— XML : eXtensible Markup Language.
84
Annexes
Annexe A : Spring Cloud Consul, Spring Cloud Netflix
Eureka et Spring Cloud Zookeeper
Spring Cloud fournit trois technologies pour le service de découverte, nous décrivons par la
suite chaque technologie et nous procéderons à une comparaison entre eux.
Spring Cloud Consul Consul est un système distribué et hautement disponible qui permet
de découvrir et de configurer les services dans notre infrastructure[19]. Spring Cloud Consul
offre une intégration de Consul pour les applications Spring Boot[20]. Spring Cloud Consul
offre :
— Un Service de découverte : les instances sont enregistrées à l’aide de l’agent consul et
les clients peuvent découvrir les instances en utilisant des beans gérer par spring.
— Un support pour Ribbon qui est un "load balancer".
— Une configuration distribuée en utilisant Consul Key/value store.
— Un support Zuul 1
— Control Bus : Un contrôle d’évènement distribué à l’aide de Consul Events
Spring Cloud Zookeeper Spring Cloud Zookeeper fournit une intégration d’Apache Zoo-
keeper pour les applications Spring Boot[21].
— un Service de découverte : les instances sont enregistrées à l’aide de l’agent zookeeper
et les clients peuvent découvrir les instances en utilisant des beans gérer par spring
— Un support pour Ribbon qui est un load balancer.
— Une configuration distribuée en utilisant consul Key/Value store.
— Un support Zuul
Eureka de Netflix Eureka est un service de découverte de Netflix qui permet aux microser-
vices de s’inscrire eux-mêmes au moment de l’exécution[22].
Comparaison entre Consul, Zookeeper et Netflix Pour la comparaison nous comparons

ces technologies deux à deux, nous commençons par Consul et Eureka. Le tableau A.1 illustre
cette comparaison [23] [20][22] [24].
1. Zuul : joue le rôle d’un microproxy qui permet de transformer une requête de l’extérieurs vers les services
de notre système
85
Tableau A.1 – Comparaison entre Eureka et Consul
Eureka Consul
Enregistrement Une instance d’un microservice Une instance est détectée par un
au serveur de s’auto inscrit dans un serveur de agent consul qui s’occupe de son
d’enregistre- d’enregistrement. Une instance enregistrement dans le serveur de
ment maintient son inscription à tra- découverte. L’agent Consul uti-
vers un mécanisme de battement lise un mécanisme de "healthche-
du coeur. Si le service d’enregis- cking" 2 chaque 10 seconde, si la
trement ne reçoit pas aucun bat- vérification échoue le service est
tement pendant une période spé- marqué comme critique. Les ser-
cifique (par défaut 30 seconde), vices sont enregistrés par n’im-
le service sera supprimé de ser- porte quels serveurs puis,elles se-
veur de d’enregistrement. Les ser- ront répliquées sur les autres ser-
vices requêtent un seul service veurs.
pour s’inscrire, qui va répliquer ⇒Équilibrage de charge
les données aux autres serveurs
⇒un seul point d’échec
Le théorème AP. Par défaut c’est CP.
CAP 3 : Les clients peuvent lire des don- Mais il supporte 3 modes de
nées erronées ou manquantes. consistance,(consistency, default,
stale). Donc il peut devenir un AP
avec le mode stale.
Lancement lancé automatiquement Lancé à partir de la ligne de com-
mande.
Equilibrage de Ribbon Ribbon
charge
Echec : quand ? Échec si tous les serveurs sont en Échec si la plupart des serveurs
panne. sont en panne.
Mais, Eureka dispose de méca-
nisme de cache coté client : même
si le serveur tombe en panne le
client peut continuer à chercher
et communiquer avec d’autres
services
Autres - Consul offre un stockage de confi-
guration, par la suite il peut être
à la fois un service de découverte
ainsi qu’un serveur de configura-
tion
Consul offre une consistance modifiable, en effet on peut basculer entre un système haute-
ment disponible ou hautement consistant, ce qui convient avec notre besoin, surtout qu’on ne
86
sait pas exactement ce que nous voulons avoir, il sera génial de tester les deux modes et décider
après de changer avec un coût nul. Aussi les services dans Eureka garde une connexion avec le
serveur pour qu’ils puissent survivre, avec consul ceci est géré par un agent, nos services auront
donc moins de responsabilités. Le dernier point sur lequel nous voulons insister c’est qu’avec
Eureka, un seul serveur qui se charge de l’inscription des services ce qui présente un seul point
d’échec (SPOF). Suite à cette étude nous choisissons Consul.
Nous comparons par la suite Consul et Zookeeper. [25] Consul et zookeeper se rassemblent
beaucoup, un des problèmes de zookeeper était avec limplémentation de service de découverte
qui est un problème résolu avec Spring Cloud Zookeeper. Consul présente des avantages ar-
chitecturaux avec la notions des clients consul et le protocole gossip, ainsi quil présente un
couplage faible entre les services et les serveurs et il offre des mécanismes de "healthchech" plus
avancés. Pour cela nous avons garder Consul.
87
Annexe B : Architecture globale en microservices de Mes-
saging Pro
La figure A.1 présente l’architecture globale en microservices de Messaging Pro.
Figure A.1 – Architecture global de la solution
88
Annexe C : Chaîne de déploiement
Chaque microservice envoyé au serveur Git, il sera automatiquement déployé en suivant la
chaîne de déploiement présenté par le diagramme dactivité de la figure A.2.
Une fois que le microservice est envoyé au serveur Git, il sera récupéré pour construire le JAR,
si la construction échoue une notification sera envoyée à l’équipe de développement et le pro-
cessus suspend. Sinon, les tests unitaires seront lancés.
Si ces derniers échouent une notification sera envoyée à l’équipe de développement et le pro-
cessus suspend. Sinon une analyse de qualité de code sera lancée.
Si l’analyse échoue une notification sera envoyée à l’équipe de développement et le processus
suspend. Sinon le jar obtenu sera déployé dans le serveur d’hébergement (il héberge les arte-
facts).
Une fois que le JAR est hébergé une notification sera envoyée à l’équipe de d’intégration et il
sera déployé dans l’environnement de test.
Une fois qu’il est déployé dans ce dernier une notification sera envoyée à l’équipe de test. Si le
produit a présenté des problèmes dans l’environnement de test une notification sera envoyée à
l’équipe de développement et le processus suspend. Sinon il sera déployé dans l’environnement
de pré-production.
Une fois que ceci est fait une notification sera envoyée à l’équipe d’intégration et le produit
sera supervisé.
89
Figure A.2 – Diagramme d’activité de la chaîne de déploiement
90
91
‫ إعادة هيكلة و نشر تطبيق بعث الرسائل باستخدام الميكروسرفس‬: ‫العنوان‬
‫ يلخص هذا التقرير األعمال المنجزة في إطار تربص نهاية الدراسة للحصول على دبلوم مهندس وطني في هندسة‬:‫ملخّص‬
.‫البرمجيات داخل المؤسسة سوفركوم‬
‫و يتمثل العمل في إعادة تصميم تطبيق واب يقوم بإرسال عدد كبير من الرسائل النصية و الصوتية وفق ا للمكرسرفسس وإيجاد‬
.‫بديل لبعض التكنولوجيات القديمة التي استوفت حدودها‬
.‫ اباشي كافكا‬,‫ اباشي كمال‬,‫ سبرينغ كالود‬,‫ سبرييغ بوت‬,‫ التصميم حسب المجال‬,‫ ليونة‬,‫ مكروسرفيس‬: ‫المف اتيح‬
Refonte (Conception & développment) et déploiement d’une solution de messagerie en

utilisant l'architecture microservices.
Résumé: Le présent rapport synthétise le travail effectué dans le cadre du projet de fin
d'études
pour l'obtention du diplôme national d'ingénieur en génie logiciel au sein de l’entreprise
Sofrecom.
Le travail consiste à une refonte d’une application web de messaging en se basant sur une
architecture en microservices ainsi que trouver des alternatifs pour quelques technologies qui
ont présenté leurs limites.
Mots-clés : Microservices, Agile, Domain Driven Design, Spring Boot, Spring Cloud, Apache
Camel, Apache Kafka.
Refactoring (Design & development) and deployment of messaging solution using

microservices architecture.
Abstract: This report summarizes the work carried out as part of the final project to obtain the
national software engineer degree in Sofrecom company.
The work consists of a redesign of a web application of messaging based on microservices
architecture as well as finding alternatives for some technologies that have presented their
limits.
Key Word: Microservices, Agile, Domain Driven Design, Spring Boot, Spring Cloud, Apache
Camel, Apache Kafka.
Intitule et adresse complète de l’entreprise :
Entreprise : Sofrecom Tunisie

Adresse : Immeuble Matrix – Berges du lac 01 – 1053
Tél. : +216 31 300 778
Email : http://www.sofrecom.com

Rapportpfenawresfarhat 170812135554

Transféré par

Droits d'auteur :

Formats disponibles

Vous aimerez peut-être aussi

Rapportpfenawresfarhat 170812135554

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapportpfenawresfarhat 170812135554

Transféré par

Droits d'auteur :

Formats disponibles

Ministère de l’Enseignement Supérieur

Projet de Fin d’Etudes

Diplôme National d’Ingénieur

Filière : Génie Logiciel

Responsable à l’entreprise: M. Amine SALHI

Président: Mme. Leila BACCOUCHE

Liste des Figures vi

Liste des Tableaux ix

I Chapitre 1 : Présentation du projet 3

II Chapitre 2 : Concepts théoriques 10

III Chapitre 3 : Les microservices proposés 16

5.1.1 Spring Boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

IV Chapitre 4 : Microservices utilitaires 30

4.2.3 Diagramme de package de microservice "User-Service" . . . . . 45

V Chapitre 5 : Les microservices Voice et SMS campaign 56

1.3.1.3 Framework d’accès aux données . . . . . . . . . . . . 68

I.1 Scénario d’inscription d’une entreprise à la plateforme MessagingPro . . . . . . . 5

II.1 carte de contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

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

IV.1 Diagramme cas d’utilisation du microservice Bundle-service . . . . . . . . . . . . 31

IV.22 Formulaire de création d’un nouveau utilisateur . . . . . . . . . . . . . . . . . 48

V.1 Diagramme de cas d’utilisation de microservice "SMSCampaign-Service" . . . . 57

A.1 Architecture global de la solution . . . . . . . . . . . . . . . . . . . . . . . . . . 88

A.2 Diagramme d’activité de la chaîne de déploiement . . . . . . . . . . . . . . . . . 90

III.1 Backlog de produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

A.1 Comparaison entre Eureka et Consul . . . . . . . . . . . . . . . . . . . . . . . . 86

blématique ainsi que le diagnostic de l’existant et la méthodologie utilisée.

Chapitre 1 : Présentation du projet

1.2 Sofrecom Tunisie

Figure I.1 – Scénario d’inscription d’une entreprise à la plateforme MessagingPro

plus coûteux en termes d’homme/jours. En troisième lieu, la haute disponibilité, la rapidité de

Figure I.2 – Architecture technique existante

5.1 Les rôles dans SCRUM

5.2 Planification d’un projet par Scrum

Figure I.3 – Le framework SCRUM

Chapitre 2 : Concepts théoriques

1 Relation entre les microservices et DevOps

3 Caractéristiques d’une architecture microservices

Ceci favorise l’idée du partage et de l’open source.

4 Domain driven design

Figure II.1 – carte de contexte

5 Architecture orientée évènements

— une communication asynchrone entre le consommateur et le producteur, le producteur

Chapitre 3 : Les microservices proposés

1 Spécification des besoins

1.1 Identification des acteurs

1.2 Backlog de produit

Tableau III.1 – Backlog de produit

ID User Story Effort

ID User Story Effort

ID User Story Effort

1.3 Les besoins non fonctionnels

2 Division Messaging Pro en microservices

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

Figure III.2 – Carte de contexte de Messaging Pro

3 Planification des Sprints

Tableau III.2 – Partitionnement des user stories par sprint

Sprint 1 (3 Sprint 2 (3 sprint 3 (4 sprint 4 (4