Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.
Ministère de l’Enseignement Supérieur
et de la Recherche Scientifique
  
Université de Carthage
  
Institut ...
Remerciements
Au terme de ce travail, j’exprime mes vifs remerciements à toute personne ayant contribué,
de près ou de loi...
Table des Matières
Liste des Figures vi
Liste des Tableaux ix
Introduction Générale 1
I Chapitre 1 : Présentation du proje...
Remerciements
5.1.1 Spring Boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1.2 Dropwizard . . . . . . ...
Remerciements
4.2.3 Diagramme de package de microservice "User-Service" . . . . . 45
4.3 Réalisation de microservice "User...
Table des Matières
1.3.1.3 Framework d’accès aux données . . . . . . . . . . . . 68
1.3.1.4 SMPPSIM . . . . . . . . . . . ...
Liste des Figures
I.1 Scénario d’inscription d’une entreprise à la plateforme MessagingPro . . . . . . . 5
I.2 Architectur...
Liste des Figures
IV.22 Formulaire de création d’un nouveau utilisateur . . . . . . . . . . . . . . . . . 48
IV.23 Liste d...
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 P...
Introduction Générale
La communication est omniprésente dans notre société. Elle présente un élément inhérent
à l’existenc...
Introduction Générale
blématique ainsi que le diagnostic de l’existant et la méthodologie utilisée.
Le deuxième chapitre p...
Chapitre I
Chapitre 1 : Présentation du projet
Plan
1 Présentation de l’entreprise . . . . . . . . . . . . . . . . . . . ....
I.2 Context du sujet
1.2 Sofrecom Tunisie
Sofrecom Tunisie lancé en Octobre 2012, est la plus jeune et la plus importante ...
I.3 Problématique du projet
Figure I.1 – Scénario d’inscription d’une entreprise à la plateforme MessagingPro
3 Problémati...
I.4 Diagnostic technique
plus coûteux en termes d’homme/jours. En troisième lieu, la haute disponibilité, la rapidité de
t...
I.4 Diagnostic technique
Figure I.2 – Architecture technique existante
La figure I.2, montre que l’application existante es...
I.5 La méthodologie : SCRUM
la vue coté backend et l’envoie au client. Cette génération coté serveur peut prendre plusieur...
I.5 La méthodologie : SCRUM
4. Durant le sprint, l’équipe se réunit chaque jour, "Daily Scrum", pour synchroniser les
tâch...
Chapitre II
Chapitre 2 : Concepts théoriques
Plan
1 Relation entre les microservices et DevOps . . . . . . . . . . . . . 1...
II.2 Architecture microservices
Le mariage entre l’architecture des microservices et l’approche DevOps a vu le jour dans d...
II.3 Caractéristiques d’une architecture microservices
composants plus explicite. En effet, la plupart des langages sont in...
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 un...
II.5 Architecture orientée évènements
le rôle d’un langage ubiquitaire 2
pour faciliter la communication entre les dévelop...
II.5 Architecture orientée évènements
— une communication asynchrone entre le consommateur et le producteur, le producteur...
Chapitre III
Chapitre 3 : Les microservices proposés
Plan
1 Spécification des besoins . . . . . . . . . . . . . . . . . . ....
III.1 Spécification des besoins
1.1 Identification des acteurs
Messaging Pro dispose de deux types d’acteurs, des acteurs pr...
III.1 Spécification des besoins
ID User Story Effort
7 En tant qu’administrateur supérieur je veux pouvoir modifier un
client...
III.2 Division Messaging Pro en microservices
ID User Story Effort
26 En tant qu’utilisateur je veux pouvoir suspendre une ...
III.2 Division Messaging Pro en microservices
nos contextes bornés. Nous présentons dans La figure III.1 chaque contexte av...
III.2 Division Messaging Pro en microservices
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...
III.4 L’architecture de l’application en microservices
4 L’architecture de l’application en microservices
La figure III.3 p...
III.5 Les choix technologiques
pour chaque client.
5 Les choix technologiques
Nous présentons, dans cette partie, les tech...
III.5 Les choix technologiques
évolué en gardant toujours son identité comme un framework web minimal, facile à utiliser e...
III.5 Les choix technologiques
— RabbitMQ a montré ses limites avec 3 600 messages/s, l’ajout des threads et des noeuds
au...
III.5 Les choix technologiques
Figure III.4 – Courbe de performance React VS Angular VS Angular JS VS Blaze
Selon la courb...
III.5 Les choix technologiques
Figure III.5 – Architecture technique minimale
Cette architecture minimale se compose alors...
III.5 Les choix technologiques
au service pour déterminer s’il est à nouveau disponible.
Nous notons que cette architectur...
Chapitre IV
Chapitre 4 : Microservices utilitaires
Plan
1 Microservice Bundle-Service . . . . . . . . . . . . . . . . . . ...
IV.1 Microservice Bundle-Service
l’analyse des besoins, la conception proposée ainsi que les interfaces homme-machine déve...
IV.1 Microservice Bundle-Service
1.2 Conception de microservice Bundle-Service
Nous détaillons, dans cette section, la pha...
IV.1 Microservice Bundle-Service
— com.olt.repository : présente le package d’implémentation des méthodes utiles pour l’ac...
IV.1 Microservice Bundle-Service
Figure IV.4 – Diagramme de classes de microservices "Bundle-service"
1.3 Réalisation de m...
IV.1 Microservice Bundle-Service
Figure IV.5 – Architecture technique de microservice "Bundle-Service"
1.3.2 Implémentatio...
IV.2 Microservice PhoneNumber-Service
Figure IV.7 – Liste des paquets
1.3.3 Tests de microservice "Bundle-Service"
Les rés...
IV.2 Microservice PhoneNumber-Service
— 3 si le numéro est International.
Dans la suite, nous présentons seulement la conc...
IV.2 Microservice PhoneNumber-Service
Figure IV.10 – Diagramme de package de microservice "PhoneNumber-Service"
2.2 Implém...
IV.3 Microservice Customer-Service
Figure IV.11 – Les test unitaire du microservice phoneNumber-Service
3 Microservice Cus...
IV.3 Microservice Customer-Service
Figure IV.12 – Diagramme de cas d’utilisation de microservice "Customer-Service"
3.2 Co...
IV.3 Microservice Customer-Service
Figure IV.13 – Modèle de domaine de microservice "Customer-Service"
3.3 Réalisation de ...
IV.4 Microservice User-Service
Figure IV.15 – Interface de création d’un client
3.3.2 Tests de microservice "Customer-Serv...
IV.4 Microservice User-Service
Figure IV.17 – Diagramme de cas d’utilisation de microservice "User-Service"
4.2 Conception...
IV.4 Microservice User-Service
deux types de communication :
— Synchrone en exposant une API Rest ;
— Asynchrone à travers...
IV.4 Microservice User-Service
4.2.3 Diagramme de package de microservice "User-Service"
La figure IV.20 présente le diagra...
IV.4 Microservice User-Service
Figure IV.20 – Diagramme de package de "User-Service"
4.3 Réalisation de microservice "User...
IV.4 Microservice User-Service
Figure IV.21 – Architecture technique de microservice "User-Service"
4.3.2 Implémentation d...
IV.4 Microservice User-Service
Figure IV.22 – Formulaire de création d’un nouveau utilisateur
Figure IV.23 – Liste de tous...
IV.5 Microservice "ContactList-service"
Figure IV.24 – Tests unitaires de microservice "User-Service"
5 Microservice "Cont...
IV.5 Microservice "ContactList-service"
Figure IV.25 – Diagramme de cas d’utilisation de ContactList-Service
5.1.2 Diagram...
IV.5 Microservice "ContactList-service"
Figure IV.26 – Diagramme de séquence système : Importer une liste de contacts
5.2 ...
IV.5 Microservice "ContactList-service"
Figure IV.27 – Modèle de domaine de microservice "ContactList-Service"
5.2.2 Diagr...
IV.5 Microservice "ContactList-service"
Figure IV.28 – Diagramme de composants
5.3 Réalisation de microservice "ContactLis...
IV.5 Microservice "ContactList-service"
Figure IV.30 – Importer une liste de contacts
L’interface IV.31 présente le pop-up...
IV.5 Microservice "ContactList-service"
5.3.2 Tests de microservice "ContactList-Service"
la figure IV.33 présente les résu...
Chapitre V
Chapitre 5 : Les microservices Voice et SMS
campaign
Plan
1 Microservice "SMSCampaign-Service" . . . . . . . . ...
V.1 Microservice "SMSCampaign-Service"
1.1 Analyse des besoins fonctionnels du "SMSCampaign-Service"
Un utilisateur a le d...
V.1 Microservice "SMSCampaign-Service"
Figure V.2 – Diagramme de séquence système "créer une campagne SMS"
58
V.1 Microservice "SMSCampaign-Service"
1.1.3 Diagramme de séquence système "lancer la campagne"
La figure V.3 présente le d...
V.1 Microservice "SMSCampaign-Service"
1.2 Conception de microservice "SMSCampaign-Service"
Nous détaillons dans cette par...
V.1 Microservice "SMSCampaign-Service"
Nous avons déjà expliqué dans le chapitre 2 section 5 l’architecture EDA 1
. L’util...
V.1 Microservice "SMSCampaign-Service"
Figure V.4 – Modèle de domaine du "SMSCampaignService"
1.2.3 Diagramme d’état d’une...
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant l’architecture microservices
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant l’architecture microservices
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant l’architecture microservices
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant l’architecture microservices
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant l’architecture microservices
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant l’architecture microservices
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant l’architecture microservices
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant l’architecture microservices
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant l’architecture microservices
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant l’architecture microservices
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant l’architecture microservices
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant l’architecture microservices
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant l’architecture microservices
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant l’architecture microservices
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant l’architecture microservices
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant l’architecture microservices
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant l’architecture microservices
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant l’architecture microservices
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant l’architecture microservices
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant l’architecture microservices
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant l’architecture microservices
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant l’architecture microservices
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant l’architecture microservices
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant l’architecture microservices
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant l’architecture microservices
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant l’architecture microservices
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant l’architecture microservices
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant l’architecture microservices
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant l’architecture microservices
Rapport pfe- Refonte et déploiement d’une solution de messagerie en utilisant l’architecture microservices
Nächste SlideShare
Wird geladen in …5
×

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

5.468 Aufrufe

Veröffentlicht am

Refonte et déploiement d’une solution de messagerie en utilisant l’architecture microservices.
Technologies utilisées: Angular 2, Spring Boot, Spring Cloud, Apache Camel, Kafka, MongoDB, MySQL.

Veröffentlicht in: Software
  • DOWNLOAD THIS BOOKS INTO AVAILABLE FORMAT (2019 Update) ......................................................................................................................... ......................................................................................................................... Download Full PDF EBOOK here { https://soo.gd/irt2 } ......................................................................................................................... Download Full EPUB Ebook here { https://soo.gd/irt2 } ......................................................................................................................... Download Full doc Ebook here { https://soo.gd/irt2 } ......................................................................................................................... Download PDF EBOOK here { https://soo.gd/irt2 } ......................................................................................................................... Download EPUB Ebook here { https://soo.gd/irt2 } ......................................................................................................................... Download doc Ebook here { https://soo.gd/irt2 } ......................................................................................................................... ......................................................................................................................... ................................................................................................................................... eBook is an electronic version of a traditional print book THIS can be read by using a personal computer or by using an eBook reader. (An eBook reader can be a software application for use on a computer such as Microsoft's free Reader application, or a book-sized computer THIS is used solely as a reading device such as Nuvomedia's Rocket eBook.) Users can purchase an eBook on diskette or CD, but the most popular method of getting an eBook is to purchase a downloadable file of the eBook (or other reading material) from a Web site (such as Barnes and Noble) to be read from the user's computer or reading device. Generally, an eBook can be downloaded in five minutes or less ......................................................................................................................... .............. Browse by Genre Available eBooks .............................................................................................................................. Art, Biography, Business, Chick Lit, Children's, Christian, Classics, Comics, Contemporary, Cookbooks, Manga, Memoir, Music, Mystery, Non Fiction, Paranormal, Philosophy, Poetry, Psychology, Religion, Romance, Science, Science Fiction, Self Help, Suspense, Spirituality, Sports, Thriller, Travel, Young Adult, Crime, Ebooks, Fantasy, Fiction, Graphic Novels, Historical Fiction, History, Horror, Humor And Comedy, ......................................................................................................................... ......................................................................................................................... .....BEST SELLER FOR EBOOK RECOMMEND............................................................. ......................................................................................................................... Blowout: Corrupted Democracy, Rogue State Russia, and the Richest, Most Destructive Industry on Earth,-- The Ride of a Lifetime: Lessons Learned from 15 Years as CEO of the Walt Disney Company,-- Call Sign Chaos: Learning to Lead,-- StrengthsFinder 2.0,-- Stillness Is the Key,-- She Said: Breaking the Sexual Harassment Story THIS Helped Ignite a Movement,-- Atomic Habits: An Easy & Proven Way to Build Good Habits & Break Bad Ones,-- Everything Is Figureoutable,-- What It Takes: Lessons in the Pursuit of Excellence,-- Rich Dad Poor Dad: What the Rich Teach Their Kids About Money THIS the Poor and Middle Class Do Not!,-- The Total Money Makeover: Classic Edition: A Proven Plan for Financial Fitness,-- Shut Up and Listen!: Hard Business Truths THIS Will Help You Succeed, ......................................................................................................................... .........................................................................................................................
       Antworten 
    Sind Sie sicher, dass Sie …  Ja  Nein
    Ihre Nachricht erscheint hier
  • DOWNLOAD THIS BOOKS INTO AVAILABLE FORMAT (2019 Update) ......................................................................................................................... ......................................................................................................................... Download Full PDF EBOOK here { https://soo.gd/irt2 } ......................................................................................................................... Download Full EPUB Ebook here { https://soo.gd/irt2 } ......................................................................................................................... Download Full doc Ebook here { https://soo.gd/irt2 } ......................................................................................................................... Download PDF EBOOK here { https://soo.gd/irt2 } ......................................................................................................................... Download EPUB Ebook here { https://soo.gd/irt2 } ......................................................................................................................... Download doc Ebook here { https://soo.gd/irt2 } ......................................................................................................................... ......................................................................................................................... ................................................................................................................................... eBook is an electronic version of a traditional print book THIS can be read by using a personal computer or by using an eBook reader. (An eBook reader can be a software application for use on a computer such as Microsoft's free Reader application, or a book-sized computer THIS is used solely as a reading device such as Nuvomedia's Rocket eBook.) Users can purchase an eBook on diskette or CD, but the most popular method of getting an eBook is to purchase a downloadable file of the eBook (or other reading material) from a Web site (such as Barnes and Noble) to be read from the user's computer or reading device. Generally, an eBook can be downloaded in five minutes or less ......................................................................................................................... .............. Browse by Genre Available eBooks .............................................................................................................................. Art, Biography, Business, Chick Lit, Children's, Christian, Classics, Comics, Contemporary, Cookbooks, Manga, Memoir, Music, Mystery, Non Fiction, Paranormal, Philosophy, Poetry, Psychology, Religion, Romance, Science, Science Fiction, Self Help, Suspense, Spirituality, Sports, Thriller, Travel, Young Adult, Crime, Ebooks, Fantasy, Fiction, Graphic Novels, Historical Fiction, History, Horror, Humor And Comedy, ......................................................................................................................... ......................................................................................................................... .....BEST SELLER FOR EBOOK RECOMMEND............................................................. ......................................................................................................................... Blowout: Corrupted Democracy, Rogue State Russia, and the Richest, Most Destructive Industry on Earth,-- The Ride of a Lifetime: Lessons Learned from 15 Years as CEO of the Walt Disney Company,-- Call Sign Chaos: Learning to Lead,-- StrengthsFinder 2.0,-- Stillness Is the Key,-- She Said: Breaking the Sexual Harassment Story THIS Helped Ignite a Movement,-- Atomic Habits: An Easy & Proven Way to Build Good Habits & Break Bad Ones,-- Everything Is Figureoutable,-- What It Takes: Lessons in the Pursuit of Excellence,-- Rich Dad Poor Dad: What the Rich Teach Their Kids About Money THIS the Poor and Middle Class Do Not!,-- The Total Money Makeover: Classic Edition: A Proven Plan for Financial Fitness,-- Shut Up and Listen!: Hard Business Truths THIS Will Help You Succeed, ......................................................................................................................... .........................................................................................................................
       Antworten 
    Sind Sie sicher, dass Sie …  Ja  Nein
    Ihre Nachricht erscheint hier
  • ACCESS that WEBSITE Over for All Ebooks (Unlimited) ......................................................................................................................... DOWNLOAD FULL PDF EBOOK here { http://bit.ly/2m77EgH } ......................................................................................................................... DOWNLOAD FULL EPUB Ebook here { http://bit.ly/2m77EgH } ......................................................................................................................... Download Full PDF EBOOK here { http://bit.ly/2m77EgH } ......................................................................................................................... Download EPUB Ebook here { http://bit.ly/2m77EgH }
       Antworten 
    Sind Sie sicher, dass Sie …  Ja  Nein
    Ihre Nachricht erscheint hier

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

  1. 1. 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
  2. 2. 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
  3. 3. 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
  4. 4. 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
  5. 5. 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
  6. 6. 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
  7. 7. 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
  8. 8. 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
  9. 9. Liste des Figures A.2 Diagramme d’activité de la chaîne de déploiement . . . . . . . . . . . . . . . . . 90 viii
  10. 10. 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
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. 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
  15. 15. 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
  16. 16. 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
  17. 17. 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
  18. 18. 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
  19. 19. 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
  20. 20. 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
  21. 21. 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
  22. 22. 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
  23. 23. 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
  24. 24. 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
  25. 25. 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
  26. 26. 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
  27. 27. III.1 Spécification des besoins 1.1 Identification des acteurs Messaging Pro dispose de deux types d’acteurs, des acteurs principaux et des acteurs se- condaires : Les acteurs principaux de MessagingPro sont : — L’administrateur : c’est l’utilisateur qui a le droit de gérer les paquets et gérer les comptes utilisateurs. — L’administrateur supérieur hérite tous les droits de l’administrateur et il gère les comptes clients et les comptes administrateur. — L’utilisateur a le droit de gérer les campagnes SMS et vocales ainsi que gérer les listes des contacts. Messaging Pro interagit avec deux acteurs secondaires pour envoyer les messages textuels et les messages vocaux qui sont : — Le SMSC : est l’abréviation de short Message Service Center. Il permet de gérer le transfert de messages SMS entre les téléphones mobiles. Le protocole utilisé pour com- muniquer avec l’SMSC est le SMPP (Short message Peer to Peer). — L’OMS : est le serveur qui permet le transfert des messages vocaux, le protocole utilisé pour communiquer avec l’OMS est le HTTP. 1.2 Backlog de produit Après avoir recenser les besoins liés à notre application, nous décrivons dans cette partie le tableau III.1 qui illustre le "product Backlog" de notre projet. Tableau III.1 – Backlog de produit ID User Story Effort 1 En tant quadministrateur supérieur je veux pouvoir ajouter un pa- quet 5 2 En tant qu’administrateur supérieur je veux pouvoir modifier un paquet 5 3 En tant qu’administrateur supérieur je veux pouvoir supprimer un paquet 2 4 En tant qu’administrateur supérieur je veux pouvoir lister tous les paquets 2 5 En tant qu’administrateur supérieur je veux pouvoir ajouter un client 5 6 En tant qu’administrateur supérieur je veux pouvoir supprimer un client 2 17
  28. 28. III.1 Spécification des besoins ID User Story Effort 7 En tant qu’administrateur supérieur je veux pouvoir modifier un client 5 8 En tant qu’administrateur supérieur je veux pouvoir lister les clients 2 9 En tant qu’administrateur supérieur je veux pouvoir ajouter un administrateur 5 10 En tant qu’administrateur supérieur je veux pouvoir lister les ad- minstrateurs 2 11 En tant qu’administrateur je veux pouvoir créer un utilisateur 5 12 En tant qu’administrateur je veux pouvoir activer un compte uti- lisateur 1 13 En tant qu’administrateur je veux pouvoir désactiver un compte utilisateur 1 14 En tant qu’administrateur je veux pouvoir lister les utilisateurs 2 15 En tant qu’utilisateur je veux pouvoir importer une liste des contacts 21 16 En tant qu’utilisateur je veux pouvoir créer une liste des contacts en ajoutant manuellement ces dérniers 8 17 En tant qu’utilisateur je veux pouvoir modifier une liste des contacts 5 18 En tant qu’utilisateur je veux pouvoir supprimer une liste des contacts 2 19 En tant qu’utilisateur je veux pouvoir lister toutes les listes des contacts 2 20 En tant qu’utilisateur je veux pouvoir créer une campagne SMS 79 21 En tant qu’utilisateur je veux pouvoir annuler une campagne SMS 3 22 En tant qu’utilisateur je veux pouvoir suspendre une campagne SMS 5 23 En tant qu’utilisateur je veux pouvoir reprendre une campagne SMS 5 24 En tant qu’utilisateur je veux pouvoir lister toutes les campagnes SMS 2 25 En tant qu’utilisateur je veux pouvoir créer une campagne vocale 79 18
  29. 29. III.2 Division Messaging Pro en microservices ID User Story Effort 26 En tant qu’utilisateur je veux pouvoir suspendre une campagne vocale 5 27 En tant qu’utilisateur je veux pouvoir reprendre une campagne vo- cale 5 28 En tant qu’utilisateur je veux pouvoir lister toutes les campagnes vocales 2 29 En tant qu’utilisateur je veux pouvoir annuler une campagne vocale 3 Nous utilisons un "story point" pour estimer l’effort nécessaire à une équipe pour implémen- ter une fonctionnalité. Trois éléments doivent être pris en compte pour l’estimation : l’effort pour le développement, la complexité et le risque. Pour estimer la taille d’une fonctionnalité nous allons choisir la séquence de Fibbonacci 1 qui est la plus utilisée. 1.3 Les besoins non fonctionnels Les besoins non fonctionnels de l’application sont : — Tolérance aux pannes Messaging Pro doit être capable à fonctionner même s’il existe des microservices en défaillance. — Mise à l’échelle Messaging Pro doit permettre une mise à l’échelle ciblée, c’est-à-dire nous n’avons pas besoin de mettre à l’échelle toute l’application, mais seulement les microservices qui ont besoin d’y être. — Maintenabilité L’architecture doit permettre l’évolution et assurer l’extensibilité de l’application. — Temps de réponse Messaging Pro doit avoir un temps minimal pour rendre une vue dans le navigateur. — Charte graphique Les interfaces de Messaging Pro doivent respecter la charte graphique d’Orange. 2 Division Messaging Pro en microservices Pour passer d’une architecture monolithique vers une architecture en microservices, nous suivons le pattern des contextes bornés du DDD, décrit précédemment dans le chapitre 2 section 4. Nous partons donc du diagramme de domaine de l’application existante et nous définissons 1. La Suite de Fibbonacci : 1,2,3,5,8,13,21,34,45,79 19
  30. 30. III.2 Division Messaging Pro en microservices 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
  31. 31. III.2 Division Messaging Pro en microservices Figure III.1 – Modèle du domaine de MessagingPro 21
  32. 32. III.3 Planification des Sprints Nous présentons dans la figure III.2 notre carte de mapping simplifiée où les relations entre les contextes sont affichées sans noms et sans multiplicités. Figure III.2 – Carte de contexte de Messaging Pro L’utilisation du pattern Bounded context nous a permis d’avoir six microservices : SMSCampaign- Service, VoiceCampaign-Service, Utilisateur-Service, Bundle-Service, Customer-Service, Contact- Service. 3 Planification des Sprints En se basant sur notre backlog product et sur la décomposition de notre produit en micro- services, nous divisons notre Release en 4 sprints comme le montre le tableau III.2. Tableau III.2 – Partitionnement des user stories par sprint Sprint 1 (3 seamines) Sprint 2 (3 semaines) sprint 3 (4 semaines) sprint 4 (4 semaines) User Story ID 1, 2, 3, 4, 5, 6, 7, 8. 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19. 20, 21, 22, 23, 24. 25, 26, 26, 27, 28, 29. Nous développons au cours du chaque sprint un ou plusieurs microservices. 22
  33. 33. 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
  34. 34. 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
  35. 35. III.5 Les choix technologiques é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
  36. 36. III.5 Les choix technologiques — 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
  37. 37. III.5 Les choix technologiques 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
  38. 38. III.5 Les choix technologiques 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
  39. 39. III.5 Les choix technologiques 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
  40. 40. 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
  41. 41. 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
  42. 42. IV.1 Microservice Bundle-Service 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
  43. 43. IV.1 Microservice Bundle-Service — 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
  44. 44. IV.1 Microservice Bundle-Service 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
  45. 45. IV.1 Microservice Bundle-Service 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
  46. 46. 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
  47. 47. IV.2 Microservice PhoneNumber-Service — 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
  48. 48. IV.2 Microservice PhoneNumber-Service 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
  49. 49. 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
  50. 50. IV.3 Microservice Customer-Service 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
  51. 51. IV.3 Microservice Customer-Service 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
  52. 52. 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
  53. 53. IV.4 Microservice User-Service 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
  54. 54. IV.4 Microservice User-Service 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
  55. 55. IV.4 Microservice User-Service 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
  56. 56. IV.4 Microservice User-Service 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
  57. 57. IV.4 Microservice User-Service 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
  58. 58. IV.4 Microservice User-Service 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
  59. 59. 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
  60. 60. IV.5 Microservice "ContactList-service" 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
  61. 61. IV.5 Microservice "ContactList-service" 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
  62. 62. IV.5 Microservice "ContactList-service" 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
  63. 63. IV.5 Microservice "ContactList-service" 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
  64. 64. IV.5 Microservice "ContactList-service" 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
  65. 65. IV.5 Microservice "ContactList-service" 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
  66. 66. 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
  67. 67. 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
  68. 68. V.1 Microservice "SMSCampaign-Service" Figure V.2 – Diagramme de séquence système "créer une campagne SMS" 58
  69. 69. V.1 Microservice "SMSCampaign-Service" 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
  70. 70. V.1 Microservice "SMSCampaign-Service" 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
  71. 71. V.1 Microservice "SMSCampaign-Service" 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
  72. 72. V.1 Microservice "SMSCampaign-Service" 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

×