INTRODUCTION

Conceptualisée par le Gartner Group, la notion de SOA (Service Oriented Architecture - ou

architecture orientée services) renvoie à une nouvelle manière d'intégrer, de manipuler les
différentes briques et composants applicatifs d'un système informatique (comptabilité, gestion
de la relation client, production, etc.) et de gérer les liens qu'ils entretiennent. Cette approche
repose sur la réorganisation des applications en ensembles fonctionnels appelés services. Un
service renvoi à une application exposée par le biais d'une interface standard (langages
SOAP/WSDL ou REST pour Representational State Transfer), connue sous le nom de Web
Services. L'architecture SOA est de plus en plus utilisée dans les entreprises. Cette
Architecture Orientée Service apporte beaucoup de nouveautés au monde des systèmes
d'information et à l'informatique en général, Cependant cette architecture semble complexe et
peu accessible au non-informaticiens. C’est pourquoi l’objectif de ce travail est de présenter le
concept SOA : principes, fonctionnement et avantages, afin de le rendre compréhensible par
tous ensuite de faire le rapprochement entre ce dernier et le BPM.

I. PRINCIPES GENERAUX DU SOA

Il n’existe pas de spécifications officielles d’une architecture SOA, néanmoins les principales
notions fédératrices retrouvées dans cette notion sont :

- La notion de service, c'est-à-dire une fonction encapsulée dans un composant que l'on
peut interroger à l'aide d'une requête composée d'un ou plusieurs
paramètres et fournissant une ou plusieurs réponses ;
- La description du service, consistant à décrire les paramètres d'entrée du service et le
format et le type des données retournées.
- La publication, (en anglais advertising) et la découverte (discovery) des services. La
publication consiste à publier dans un registre (en anglais registry ou repository) les
services disponibles aux utilisateurs, tandis que la notion
de découverte recouvre la possibilité de rechercher un service parmi ceux qui
ont été publiés.
- L’invocation, représentant la connexion et l'interaction du client avec le service.

En outre, on dénombre trois grands objectifs de l'architecture orientée services, chacun axé
sur une partie distincte du cycle de vie applicatif (ALL : Application Life cycle Management),
consiste à superviser une application de sa planification initiale jusqu'à son retrait).
 Le premier objectif consiste à structurer sous forme de services les procédures ou
composants logiciels. Ces services sont conçus pour être faiblement couplés aux applications :
ils ne servent qu'en cas de besoin. Ils sont prévus pour que les développeurs, tenus de
standardiser la création de leurs applications, les utilisent facilement.

Le deuxième objectif est de fournir un mécanisme de publication des services

disponibles qui comprend la fonctionnalité et les besoins d'entrée/sortie (E/S ou I/O). Les
services sont publiés de manière à faciliter leur intégration aux applications.

Le troisième objectif de l'architecture est de contrôler l'utilisation de ces services pour

éviter tout problème de sécurité et de gouvernance. La sécurité de cette SOA est surtout axée
sur la sécurité des composants individuels en son sein, sur les procédures d'authentification et
d'identification en lien avec ces composants, et la sécurisation des connexions entre les
composants de l'architecture.

Partant de ce principe, le SOA fonction d’une manière particulière.

II. FONCTIONNEMENT DU SOA

Une autre définition simple du SOA pourrait être la notion d'intégrer et de manipuler
les différents composants logiciels d'un système informatique en tant qu'ensembles
fonctionnels appelés services. Cette architecture à la mode répond aux problèmes de
réutilisation d'outils (ou produits) des entreprises.

L'architecture SOA a deux grandes fonctions. Tout d'abord, il s'agit de créer un ample
modèle d'architecture qui définit les objectifs des applications et les approches pour les
atteindre ; ensuite, de définir des caractéristiques de mise en œuvre précises, souvent liées à
celles du langage de description de services WSDL (Web Services Description Language) et
du protocole SOAP (Simple Object Access Protocol).

Pour mieux comprendre sa définition, il faut voir cette architecture comme une
philosophie. C'est une approche permettant de réutiliser et d'organiser des ressources
existantes, dans une solution autorisant une interopérabilité entre plateformes et
environnements, une évolutivité des modules applicatifs et une flexibilité autorisant
l'utilisation dynamique d'applications. Cette solution permet donc d'intégrer divers systèmes :
chaque ressource peut être accessible en tant que service possédant une interface.
L'implémentation du fournisseur de service est donc libre de changer sans qu'il y ait un impact
sur son utilisation. On peut voir ce service comme une boîte noire : on sait qu'elle va rendre le
service voulu sans savoir comment est faite la boite noire. On peut choisir de la remplacer par
un autre service implémenté différemment mais répondant aussi à la même fonctionnalité.

Un exemple concret est le service qui a été créé par la SNCF 1 : réserver une place de
train. Une architecture SOA a été implémentée et l'un des services offre la possibilité de
réserver une place de train : que l'on y accède de leur site internet ou d'un guichet, le service
est le même. La personne qui fait la réservation utilise un client pour se connecter : un
consommateur de service. Cependant, l'interaction entre consommateur et fournisseur n'est
pas directe mais faite par le biais d'un médiateur responsable de la mise en relation des
composants.

Un consommateur de Service X (resp. Y) passe par un médiateur pour accéder au bon

fournisseur de Service X (resp. Y).

Pour mieux comprendre comment fonctionne une architecture SOA, il est important de savoir
ce qu'est un service. Il assure une fonction bien définie et est autonome, ne dépendant d'aucun
contexte ou service externe. On retrouve dans un service les caractéristiques suivantes :

- Couplage faible : les services sont exposés via des standards qui assurent la réduction
des dépendances. Le terme « loosely-coupled » est souvent utilisé.
- Grande Maille : les opérations proposées par un service encapsulent plusieurs
fonctions et opèrent sur un périmètre de données large. Un service contient des objets,
des composants qu'il utilise pour répondre à sa fonction. Le terme récurrent est «
coarse-grained ».
- Interface : le contrat d'utilisation du service.
- Synchrone ou asynchrone : attente de réponse après l'utilisation d'un service ou non.
- Activable à distance et interopérable.

Une architecture orientée service consiste donc en une collection de services, indépendants
les uns des autres, qui interagissent et communiquent entre eux.

Il est intéressant de comparer l'architecture SOA à une autre architecture qui met en avant des
différences importantes. Cette architecture est l'architecture orientée objet. Dans cette
architecture, les données manipulées sont directement associées au mode de traitement qui
leur est appliqué. La programmation orientée objet (POO) implique deux choses : liaison forte

1
SNCF :
à un modèle spécifique et un nombre d'appels important entre les deux couches de
présentation et métier (contenant les objets métiers).

Architecture Orientée Objets

Au contraire, l'architecture SOA permet à la couche de présentation de passer par des services
pour manipuler les objets métier sans avoir besoin de les connaître explicitement. Les services
agissent ainsi en tant que boites noires faisant abstraction de la complexité du modèle objet.

Architecture Orientée Services

Pour mettre en pratique cette théorie, une implémentation s'est vite imposée : les Web
Services. Ce sont des services associés au SOA.

III. LES WEB SERVICES ASSOCIES AU SOA

 Les interfaces standard (langages SOAP/WSDL2 ou REST3 pour (Representational
State Transfer), qui permettent d’implémenter un service sont connues sous le nom de Web
Services, des couches d'invocation compréhensibles potentiellement par l'ensemble des
systèmes en présence, car elles intègrent le module d'interprétation nécessaire. La plupart des
serveurs d'intégration (EAI)4 et des plates-formes applicatives savent exécuter les interfaces
en mode Web Services. Ce qui leur permet par conséquent de supporter des architectures de
type SOA, c'est-à-dire un ensemble de Web Services distribués dialoguant entre eux. Au fil
des années, l'interface REST s'est imposée comme le principal standard dans ce domaine.
Certaines offres vont plus loin néanmoins en incluant l'orchestration de processus standardisés
(par exemple via BPEL5).

Les Web Services représentent l'implémentation la plus utilisée pour appliquer

l'architecture SOA. Le concept de Web Service regroupe un ensemble de technologies basées
sur XML, permettant de créer des composants logiciels distribués, de décrire leurs interfaces
et de les utiliser en mettant en œuvre des standards tels que SOAP, XSD, WSDL et UDDI.
Les Web Services respectent donc des protocoles et des normes informatiques utilisés pour
échanger des données entre les applications : ils ont été définis, pour la plus grande part, par le
W3C (World Wide Web Consortium), qui a été fondé pour promouvoir la compatibilité des
technologies du Web et émet des recommandations à valeur de standards industriels.

Un Web Service peut, dans un exemple simple, laisser un client communiquer avec lui
en utilisant des messages XML qui répondent au standard SOAP (Simple Object ou Service
Oriented Architecture Protocol). Il représente donc le format d'échange de données dont les
protocoles primaires sont HTTP et HTTPS. On y trouve un en-tête et un corps. Dans l'en-tête,
on peut faire référence à un fichier XSD (XML Schema Definition), permettant de définir les
types des différentes données échangées. Dans le corps, les données indiquant la méthode
utilisée et les bons paramètres sont présents. Prenons un Web service donnant, pour un
identifiant client particulier et un identifiant produit, le prix du produit désiré. Un message
SOAP contenant les bonnes informations et un champ prix vide pourra être envoyé au service.
En retour, sera renvoyé le message avec le prix du produit renseigné.

IV. AVANTAGES DU SOA

2
SOAP/WSDL :
3
REST :
4
EAI :
5
BPEL :
Une architecture orientée service permet d’obtenir tous les avantages d’une architecture
client-serveur notamment :

- Une modularité permettant de remplacer facilement un composant /service par un

autre ;
- Une réutilisabilité possible des composants contrairement à un système tout en un
fait sur mesure pour une organisation ;
- De meilleures possibilité d’évolutions car il suffit de faire évoluer un service ou
d’ajouter un service ;
- Une plus grande tolérance aux pannes : flexibilité ;
- Une maintenance facilitée : service par service et non tout le système d’un coup ;
- Réduction des couts d’entretien et les scalabilité des services.
- Une amélioration de la rapidité ainsi que la productivité des développements : grâce à
son caractère standard. Ainsi, un composant exposé sous forme de Web Services peut
être réutilisé à loisir par d'autres applications.
Exemple type : les dispositifs de requêtage et d'inscription au sein d'un annuaire
d'entreprise, solution classiquement conçue pour gérer les droits d'accès aux
applications en stockant les profils utilisateur. Une fois publiées par le biais de Web
Services, ces fonctions peuvent être aisément intégrées aux différentes briques du SI
sans que le développement de connecteurs spécifiques au cas par cas ne soit
nécessaire.
- Une intégration d’une démarche de "fourniture de services" par la technologie des
Web Services. Une logique qui, au-delà de services techniques d'intégration, renvoie à
la publication de composants sous la forme de "services métier" délivrés à des
applicatifs clients (internes ou externes), avec à la clé l'ensemble des notions sous-
jacentes : contrat de service, niveau de service, etc. Pour être appliquée, cette
philosophie passe par la mise en place d'annuaires de Web Services incluant
l'ensemble des éléments nécessaires à la consommation de ces derniers (adresses,
droits d'accès, conditions d'utilisation, etc.). Le SAO permet donc d’associer les
composants du système d'information à des contrats de service métier ;
- SOA est un style d'architecture dont l'objectif premier est de fournir un couplage lâche
entre les agents logiciels. Il simplifie donc la réutilisation. En effet, plus les systèmes
informatiques sont déployés en entreprise, plus il semble indispensable de réutiliser les
fonctions des systèmes existants au lieu de tout reconstruire à partir de zéro.
 Par exemple, supposons une SOA que vous installée dans un salon. Pour lire un CD,
nous utilisons un lecteur CD de salon qui offre un service de lecture de CD. Il est
possible de remplacer le lecteur de salon par un lecteur portable qui offre aussi un
service de lecture de CD mais avec une qualité de service différente. Nous pouvons
aussi choisir de lire un autre CD. Dans la mesure où l'interface entre le CD et le lecteur
de CD est bien définie, il est possible de lire n'importe quel CD sur n'importe quel
lecteur. Le style SOA pousse donc à la réutilisation de services existants avec comme
conséquence la nécessité de bien définir des standards de données.

V. INCONVENIENTS DU SOA

Les inconvénients de l’utilisation d’une architecture orientée services incluent :

- Le développement de l'architecture orientée services dépend de l'application des

normes. Sans normes, la communication entre les applications devient difficile et
requiert énormément de temps ;
- Ce type d’architecture n'est pas destiné à des applications avec des transferts de
données haute, des applications qui ne requièrent pas d'exécution de requête/réponse
ou avec une durée de vie courte ;
- Un bug / interruption dans un service peut affecter plusieurs services /couches ;
- Il manque une symphonie(union) de domaines en raison de laquelle l’innovation
pourrait faire défaut ;
- Les équipes peuvent finir par travailler sur une seule couche si elles ne sont pas gérées
correctement ;
- La gestion de plusieurs fonctionnalités est difficile car elle peut impliquer des
modifications sur plusieurs services ;
- Un service pourrait finir par changer beaucoup.

VI. EXEMPLE D’APPLICATION et RAPPROCHEMENT BPM vs SOA

Prenons l’exemple du traitement d’un litige pour une compagnie d’assurances. Dans
un premier temps, la demande de remboursement est traitée et intégrée dans le CRM, qui
reconnaît le client, son contrat, son type de police.
Une fois l’identification effectuée, la demande entre dans l’outil de gestion des processus, qui
se charge de faire appel à un expert pour le traitement du sinistre ; par exemple, s’il s’agit
d’un accident de voiture, il faudra demander ? un devis à un garagiste.
L’outil de gestion des processus intègre les différentes personnes qui peuvent intervenir dans
le traitement du sinistre pour l’apport d’informations complémentaires. Il permet notamment
de déterminer le malus ou le bonus, le montant du remboursement.
Ensuite, la demande est prise en charge par le système financier pour le paiement. Une fois le
sinistre traité et le paiement effectué, les données sont stockées en vue d’être analysées.

Le BPM permet donc de définir l’ensemble de ces processus, en analysant de bout en

bout les données agrégées. L’architecture SOA assure le séquencement des différents services
et va permettre d’accéder aux différents documents nécessaires au traitement du sinistre,
présents dans les diverses applications du système, au travers des services. Le système de
gestion des processus se charge d’appeler les bons services au bon moment.

Dans une architecture SOA, les applications sont connectées entre elles grâce à des
connexions en couplage lâché via un bus de services (ESB), ce qui offre une grande
flexibilité. En effet, on peut appeler dans le workflow tout type de données, intégrer de
nouvelles applications de manière extrêmement rapide, et procéder à des analyses poussées au
travers d’outils de mesure. Grâce au couplage lâche, il n’est plus nécessaire de développer un
beacon6 (balise) spécifique pour chaque application, le développement d’un beacon générique
permet d’aller chercher les données n’importe où. Ceci rend la modélisation des processus
facile, car au lieu de tout définir, on appelle des services déjà définis. Il en est de même pour
le reporting et l’analyse.

SOA et BPM ont donc beaucoup à apporter à l’entreprise, mais aussi l’un à l’autre
pour offrir une adéquation totale entre l’IT et le business.

6
Beacon
 CONCLUSION

Le concept de SOA (Services Oriented Architecture ou Architecture Orientés Services

en français) apparait comme une solution pour optimiser les performances de l’entreprise, la
rendre plus flexible aux changements tout en réduisant les coûts. Elle se définit comme une
architecture logicielle s’appuyant sur un ensemble de services simples. Tout comme le BPM il
offre à l’entreprise les moyens pour rendre ces processus plus efficaces et donc d’améliorer la
productivité et le ROI7 des applications. A la différence du BPM qui s’appuie sur le Business,
l’approche SOA s’appuie sur l’IT8. Le SOA associé au BPM permet l’intégration parfaite des
services informatiques et métiers de l’entreprises ceci en vue de leur optimisation. L’approche
SOA s’appuie particulièrement sur la modélisation des processus IT pour son implémentation.

Bien que son efficacité ne soit plus à démontrer, la mise en œuvre de l’architecture orientée
service est très complexe et représente un coût important pour l’entreprise ce qui pourrait être
un frein à son utilisation.

7
Retour sur Investissement
8
Information and Technology
 WEBOGRAPHIE

-https://www.bpms.info/bpm-et-soa-outils-complementaires-pour-l-entreprise-agile/-
www.commentcamarche.net : Web Services-Architecture orientée services(SOA)

-www.memoireonline.com/12/08/1644/SOA--Definition-Utilisation-dans-le-monde-de-la-banque-et-
methodologie-de-test.html

- https://www.journaldunet.com/solutions/reseau-social-d-entreprise/1093222-soa-pour-service-
oriented-architecture-decryptage/

- https://www.condexatedenbay.com/les-inconvenients-de-l-architecture-orientee-services/
- https://medium.com/@abelmahefa/introduction-au-service-et-micro-service-oriented-
architecture-f5447af937ac

BIBLIOGRAPHIE

Une autre définition simple du SOA pourrait être la notion d'intégrer et de manipuler
les différents composants logiciels d'un système informatique en tant qu'ensembles
fonctionnels appelés services. Ici les services se retrouvent au cœur de l’architecture avec des
données et applications.

Pour mieux comprendre comment fonctionne une architecture SOA, il est important de savoir
ce qu'est un service. Il assure une fonction bien définie et est autonome, ne dépendant d'aucun
contexte ou service externe. On retrouve dans un service les caractéristiques suivantes :

- Couplage faible : les services sont exposés via des standards qui assurent la réduction
des dépendances. Le terme « loosely-coupled » est souvent utilisé.
- Grande Maille : les opérations proposées par un service encapsulent plusieurs
fonctions et opèrent sur un périmètre de données large. Un service contient des objets,
des composants qu'il utilise pour répondre à sa fonction. Le terme récurrent est «
coarse-grained ».
- Interface : le contrat d'utilisation du service.
- Synchrone ou asynchrone : attente de réponse après l'utilisation d'un service ou non.
- Activable à distance et interopérable.

Une architecture orientée service consiste donc en une collection de services, indépendants
les uns des autres, qui interagissent et communiquent entre eux.

Cette architecture permet l’optimisation des fonctionnalité critique car les

developpeurs utilisent ces packagent en guise de souche . Il y’ a donc des services générisue
et spécifiques. Par exemple le service générique système d’imagerie médicale on a des
services de reconnaissances formes, de recconnaissance des couleurs , de reconnaissances de
la tridimensionnalité.

Avantages : Cette architecture à la mode répond aux problèmes de réutilisation d'outils

(ou produits) des entreprises donc une écinomie en termes de developpement et
d’investissement. Ces services sont commerciialisable, et autonomes (mises à ours faciles et
automatiques). Ces services peuvent s’appeler lui-même (microservices herbergeable dans le
cloud)

L'architecture SOA a deux grandes fonctions. Tout d'abord, il s'agit de créer un ample
modèle d'architecture qui définit les objectifs des applications et les approches pour les
atteindre ; ensuite, de définir des caractéristiques de mise en œuvre précises, souvent liées à
celles du langage de description de services WSDL (Web Services Description Language) et
du protocole SOAP (Simple Object Access Protocol).

Pour mieux comprendre sa définition, il faut voir cette architecture comme une
philosophie. C'est une approche permettant de réutiliser et d'organiser des ressources
existantes, dans une solution autorisant une interopérabilité entre plateformes et
environnements, une évolutivité des modules applicatifs et une flexibilité autorisant
l'utilisation dynamique d'applications. Cette solution permet donc d'intégrer divers systèmes :
chaque ressource peut être accessible en tant que service possédant une interface.
L'implémentation du fournisseur de service est donc libre de changer sans qu'il y ait un impact
sur son utilisation.

On peut voir ce service comme une boîte noire : on sait qu'elle va rendre le service
voulu sans savoir comment est faite la boite noire. On peut choisir de la remplacer par un
autre service implémenté différemment mais répondant aussi à la même fonctionnalité.

Un exemple concret est le service qui a été créé par la SNCF 9 : réserver une place de
train. Une architecture SOA a été implémentée et l'un des services offre la possibilité de
réserver une place de train : que l'on y accède de leur site internet ou d'un guichet, le service
est le même. La personne qui fait la réservation utilise un client pour se connecter : un
consommateur de service. Cependant, l'interaction entre consommateur et fournisseur n'est
pas directe mais faite par le biais d'un médiateur responsable de la mise en relation des
composants.

Un consommateur de Service X (resp. Y) passe par un médiateur pour accéder au bon

fournisseur de Service X (resp. Y).

Il est intéressant de comparer l'architecture SOA à une autre architecture qui met en avant des
différences importantes. Cette architecture est l'architecture orientée objet. Dans cette
architecture, les données manipulées sont directement associées au mode de traitement qui
leur est appliqué. La programmation orientée objet (POO) implique deux choses : liaison forte
à un modèle spécifique et un nombre d'appels important entre les deux couches de
présentation et métier (contenant les objets métiers).

9
SNCF : Société National de Chemin de fer Francais
Architecture Orientée Objets

Au contraire, l'architecture SOA permet à la couche de présentation de passer par des services
pour manipuler les objets métier sans avoir besoin de les connaître explicitement. Les services
agissent ainsi en tant que boites noires faisant abstraction de la complexité du modèle objet.

Architecture Orientée Services

Pour mettre en pratique cette théorie, une implémentation s'est vite imposée : les Web
Services. Ce sont des services associés au SOA.