ESIAC – Cycle Ingénieur – Département Génie Informatique et Télécommunications

EXPOSE INTEGRATION DES SYSTEMES

THEME : ARCHITECTURE ORIENTEE SERVICES

Rédigé par :

TAMKOU MANFOUO Christbern Vicaire G.

Option & Niveau : M.S.I. 5 (Management des Systèmes d’Information)

2022 – 2023 Ecole Supérieure d’Ingénieurs et de Management d’Afrique Centrale

INTRODUCTION

Aujourd'hui, le système d'information devient de plus en plus complexe et il doit

intégrer des besoins tels que la sécurité et le décisionnel. Toutes ces demandes sont
coûteuses et doivent pouvoir se mettre en place rapidement en respectant les coûts
d'intégration.
De plus, les problématiques de production informatique impactent de plus en plus
l'activité de l'entreprise. Il est alors nécessaire de simplifier le système d'information et le
rendre plus fluide.
Pour répondre à ces problématiques, il est nécessaire d’améliorer l’agilité du système
d’information en facilitant la réutilisation des composants existants.
L’approche SOA s’efforce de proposer des normes, des bonnes pratiques mais
aussi des outils permettant de mettre en œuvre cette agilité.
Qu’est-ce que l’architecture orientée services ?

L'architecture orientée services (SOA) est une méthode de développement de logiciels qui utilise
des composants logiciels appelés services pour créer des applications métier. Chaque service offre une
capacité commerciale, et les services peuvent également communiquer entre eux à travers les
plateformes et les langues. Les développeurs utilisent la SOA pour réutiliser des services dans différents
systèmes ou combiner plusieurs services indépendants pour effectuer des tâches complexes.
Les Principes de bases

Dans la vie de tous les jours, un fournisseur offre un service à un client le consommant dans une
relation de confiance établie entre les deux parties. En général, le client s’intéresse uniquement au
résultat produit du service sans avoir le besoin ni le souci de savoir comment ce dernier est obtenu. La
SOA suit ce même principe. Le service est une action exécutée par un « fournisseur » (ou
« producteur ») à l'intention d'un « client » (ou « consommateur »), cependant l'interaction entre
consommateur et producteur est faite par le biais d'un médiateur (qui peut être un bus) responsable de
la mise en relation des composants. Le service étant à grandes mailles, il englobe et propose les
fonctionnalités des composants du système.
Les Principes de bases

Il s’agit de :
 Interopérabilité
 Couplage faible
 Abstraction
 Granularité
Les Composants
Une architecture orientée services (SOA) est constituée de quatre composants principaux.

 Service

 Fournisseur du service

 Consommateur du service

 Registre du service
Le fonctionnement et implémentation

Avant l'arrivée de l'architecture SOA à la fin des années 1990, il était difficile de connecter
une application à des services hébergés par un autre système. Cela nécessitait une intégration point-à-
point poussée (connectivité, routage, traduction des modèles de données, etc.), que les développeurs
devaient ensuite reproduire pour chaque nouveau projet. Ce modèle était appelé « monolithique », car
tout le code de l'application tenait dans un déploiement unique. Si l'un des éléments de l'application ne
fonctionnait pas correctement, il fallait mettre hors ligne l'application entière pour résoudre le problème
avant de déployer une autre version.
En exposant des services via des protocoles réseau standards (comme SOAP, JSON, ActiveMQ ou
Apache Thrift) pour envoyer des requêtes ou accéder aux données, l'architecture SOA évite aux
développeurs de devoir réaliser une intégration de A à Z.
Qu’est ce qu’un ESB dans une architecture orientée services

À la place, ils peuvent utiliser des modèles appelés ESB pour réaliser l'intégration entre un
composant centralisé et les systèmes back-end, puis les rendre disponibles en tant qu'interfaces de
services. Cela permet aussi aux développeurs de réutiliser les fonctions déjà existantes au lieu de les
recréer.
Au sein d'une architecture orientée services, les services communiquent via un système de
« couplage faible ». Les composants (aussi appelés « éléments ») sont interconnectés dans un système
ou réseau, ce qui leur permet de transmettre des informations ou de coordonner un processus métier, en
réduisant la dépendance entre eux. Dans les faits, cela aboutit à la création d'une application.
Qu’est ce qu’un ESB dans une architecture orientée services

Un enterprise service bus (ESB) est un logiciel que vous pouvez utiliser lorsque vous communiquez
avec un système doté de plusieurs services. Il établit la communication entre les services et leurs
utilisateurs, peu importe la technologie.  
Avantages d'un ESB
Un ESB fournit des capacités de communication et de transformation à travers une interface de
service réutilisable. Vous pouvez considérer un ESB comme un service centralisé qui achemine les
demandes de service vers le service approprié. Il convertit également la demande dans un format
accepté par la plateforme sous-jacente et le langage de programmation du service.
Implémentation avec l’ESB

L'implémentation la plus commune de SOA est celle basée sur un bus de services. Ce bus a un rôle
de médiateur (middleware) entre le consommateur et le producteur du service, il permet ainsi de réaliser
le couplage lâche. Le bus peut aussi fournir une gamme de services :
sur la base des patterns EIP (enterprise integration pattern), fournir des fonctionnalités de
fractionnement, combinaison permettant de construire l'appel sur plusieurs services ;
des fonctionnalités de gestion de version de service ;
des fonctionnalités de supervision et contrôle (avec SLA) des services.
On parle généralement d'ESB (Enterprise Service Bus), outil de nouvelle génération pour
l'IAE (Intégration d'Applications d'Entreprise, EAI) construit sur des standards comme XML, JMS (Java
Message Service) ou encore les services web. La différence majeure avec l'IAE réside dans le fait que
l'ESB propose une intégration complètement distribuée grâce à l'utilisation des conteneurs de services.
Ces "mini-serveurs" contiennent la logique d'intégration et peuvent être déposés n'importe où sur le
Implémentation avec l’ESB

L'ESB est principalement un outil d'échange asynchrone disposant d'interfaces standardisées

(SOAP, JMS…) ou intégrées (JBI…). Il peut aussi offrir des services à valeur ajoutée (traduction,
transformation…) activés par des événements.

Implémentation avec la WOA

Une autre possibilité pour mettre en place SOA au sein d'un SI consiste à utiliser le web comme
unique support de service (et non un bus). Cette approche est rendue possible par le fait que le web
contient d'ores et déjà les qualités nécessaires à une SOA (routage, sécurité…).
Cependant, une telle architecture impose que tous les services soient exposés sur le web (ce qui signifie
accessible depuis un URL), privilégiant ainsi les services web (rappelons que les services web ne sont
pas le seul moyen d'exposer des services sur le web).
Implémentation avec l’ESB

L'avantage de cette conception est que le support des messages d'invocation de service (le web
donc) est vraiment universel et ne nécessite aucune configuration, maintenance, évolution… Mais cette
solution est actuellement assez dépréciée dans les situations où les performances sont un critère
discriminant Cette solution semble, en termes de pure architecture (considérations techniques mises à
part), vraiment plus conforme aux principes de SOA. Qworum est un exemple de technologie WOA.
Quels sont donc les avantages d’une architecture orientée services

Une architecture orientée services (SOA) présente plusieurs avantages par rapport aux
architectures monolithiques classiques dans lesquelles les processus sont exécutés en tant qu'unité
distincte. Voici les principaux avantages de la SOA :
 Délais de commercialisation réduits
Les développeurs réutilisent les services pour différents processus métier afin de gagner du temps
et de l'argent. Ils peuvent assembler les applications bien plus rapidement avec la SOA qu'en rédigeant
du code et en effectuant les intégrations depuis le départ.
 Efficacité de maintenance
Il est plus simple de créer, de mettre à jour et de déboguer de petits services que de grands blocs
de code dans des applications monolithiques. La modification d'un service dans la SOA n'a aucun impact
sur la fonctionnalité globale du processus métier.
Quels sont donc les avantages d’une architecture orientée services

 Meilleure adaptabilité
La SOA s'adapte mieux aux progrès technologiques. Vous pouvez moderniser vos applications de
manière efficace et rentable. Par exemple, les organismes de soins de santé peuvent utiliser les
fonctionnalités de systèmes de dossiers de santé électroniques anciens dans des applications cloud
récentes.
Quelles sont les limites de la mise en œuvre d'une architecture orientée services

 Capacité de mise à l'échelle limitée

La capacité de mise à l'échelle du système est affectée de manière considérable lorsque les
services partagent de nombreuses ressources et doivent se coordonner pour réaliser leurs tâches. 
 Augmentation des interdépendances
Les systèmes d'architecture orientée services (SOA) peuvent se complexifier avec le temps et
développer des interdépendances entre les services. Il peut être difficile de les modifier ou de les
déboguer si plusieurs services s'appellent en boucle. Les ressources partagées, telles que les bases de
données centralisées, peuvent également ralentir le système.
 Point unique de défaillance
Pour les mises en œuvre d'une SOA avec un ESB, l'ESB crée un point unique de défaillance. Il
s'agit d'un service centralisé, qui est contraire à l'idée de décentralisation préconisée par la SOA. Les
clients et les services ne peuvent pas du tout communiquer entre eux si l'ESB tombe en panne.
Que sont les microservices ?

Une architecture de microservices est constituée de composants logiciels très petits et totalement

indépendants, nommés microservices, qui se spécialisent et se concentrent sur une seule tâche. Les
microservices communiquent via des API, qui sont des règles créées par les développeurs pour
permettre aux autres systèmes logiciels de communiquer avec leur microservice.
Le style d'architecture de microservices est plus adapté aux environnements de cloud computing
modernes. En règle générale, ils opèrent sous la forme de conteneurs, des unités logicielles
indépendantes qui regroupent le code avec toutes ses dépendances.
Avantages des microservices
Les microservices présentent des caractéristiques natives cloud : ils sont individuellement évolutifs,
rapides, portables et indépendants des plateformes. Ils sont également dissociés, ce qui signifie qu'ils
n'ont que peu ou pas de dépendances avec d'autres microservices.
Que sont les microservices ?

Pour ce faire, les microservices bénéficient d'un accès local à toutes les données nécessaires plutôt
que d'un accès à distance à des données centralisées que d'autres systèmes consultent et utilisent
également. Cela engendre une duplication de données, compensée par les performances et l'agilité des
microservices.
Les SOA comparées aux microservices
L'architecture de microservices est une évolution du style d'architecture de SOA. Les microservices
comblent les lacunes des SOA afin de rendre le logiciel plus compatible avec les environnements
d'entreprise cloud modernes. Ils sont précis et favorisent la duplication des données plutôt que le
partage des données. Cela les rend totalement indépendants grâce à leurs propres protocoles de
communication qui sont présentés via des API légères. La tâche des utilisateurs est principalement
d'utiliser le microservice via son API, ce qui élimine ainsi le besoin d'ESB centralisé.
CONCLUSION

Parvenu au terme de cet exposé, il en ressort que l’architecture orienté services en abrégé SOA est
une solution basée sur les services, c'est une solution d'architecture qui permet l'interaction entre
différentes applications avec beaucoup d'agilité. Fondé sur des principes comme l’interopérabilité, le
couplage faible, il est composé de quatre(04) composants principaux que sont : le service l’élément
central, le fournisseur de service, le registre de service et le consommateur de service.
Son implémentation se fait par plusieurs stratégies comme : les web services, l’usage de l’ESB, etc.
Toutefois, l’architecture orienté services représente une point de défaillance unique selon le moyen
choisi comme bus. De plus, à long terme, on assiterait à une augmentation de l’interdépendance selon la
complexité du système en place. D’où la conténeurisation des services créée.
 ETUDE DE CAS

Considérons un système d’information consacré à la location des véhicules par

exemple. Dudit système plusieurs services en ressortent et sont exposés suivant le
processus métier. De chaque service peuvent en ressortir d’autres services (sous-services).
A noter que Le potentiel d'un service est d'autant plus
important qu'il
 Permet d'automatiser un processus métier critique
 Est réutilisable par plusieurs domaines métiers
 Remplace une application désuète
 Supporte des besoins non fonctionnels(sécurité, logging, monitoring...)