 |
| Exemple d'une architecture SOA |
Définition
L'architecture
orientée service (SOA) peut être définie comme une façon de
bâtir une application logicielle en assemblant plusieurs composantes
logicielles autonomes. Un système logiciel bâti suivant ce modèle est
essentiellement une collection de services qui communiquent entre eux. La
communication peut impliquer une simple transmission de données entre deux
services ou la coordination d'une activité par plusieurs services.
Un service SOA est une unité discrète de
fonctionnalités accessibles à distance, exploitée et mise à jour de manière
indépendante. Autrement dit, c’est une composante d’un système informatisé qui
met à disposition de ses consommateurs un accès
centralisé à une ou plusieurs fonctions d’affaires. Les consommateurs peuvent être des acteurs humains, du matériel ou des logiciels qui
interviennent dans le processus d’affaires que supporte ce service.
Un service SOA
a quatre propriétés selon l'une des nombreuses définitions de SOA:
- Un service représente logiquement une activité d’affaire de l’entreprise avec un résultat spécifié.
- Un service est autonome.
- Le consommateur n’est pas au courant du fonctionnement interne du service, pour lui c’est une boite noire.
- Un service peut être composé d'autres services sous-jacents.
Les premiers styles de mise en œuvre de SOA
Les premiers
styles d’architecture orientée services sont nés dans les années 2000 de
l’exigence forte des systèmes informatiques des grandes entreprises de s’ouvrir
à l’externe, en particulier sous la poussée de la mondialisation. Ces
entreprises faisaient face à des besoins d’ouverture divers, donc l’ouverture
aux clients (commerce électronique et internet), l’ouverture aux employés
(intranet d’entreprise), l’ouverture aux partenaires d’affaires, aux
fournisseurs, aux agents commerciaux et aux autorités de régulation.
Dans ces
premiers styles de SOA, les services qui composent l'application sont organisés
autour d’un bus de services d’entreprise (encore appelé ESB, acronyme de
l’expression anglaise « Enterprise Service Bus »). L’ESB agit comme un socle
d’intégration entre les services pour satisfaire les critères de réutilisation
et de modularité, comme on peut voir sur l’exemple de la figure ci-dessus.
Au sein de
cette architecture, chaque service est organisé autour d'un processus métier
spécifique et utilise un protocole de communication pour échanger avec l'ESB. Ce protocole peut être différent d'un service à l'autre.
Sur notre
exemple, on peut voir le bus de services d’entreprise (ou l’ESB) au centre et
les services qui gravitent tout autour:
- Un premier service ERP qui gère le service après-vente (SAV) et qui communique avec le bus suivant un protocole HTTP.
- Un second service ERP qui gère la comptabilité. Il est construit avec une technologie J2EE et communique avec le bus suivant deux protocoles JMS et JCA.
- Le 3e est un service de gestion des commandes. Il est développé avec les technologies .NET et utilise le protocole HTTP pour communiquer avec l’ESB.
- On a aussi un service boutique en ligne qui utilise aussi le protocole HTTP pour communiquer avec l’ESB.
- Et d'autres services...
Les services
ne se parlent pas directement. Dans une communication entre un service client
et un service fournisseur, l’ESB reçoit la requête du client, traduit le
message dans un format compréhensible par le fournisseur avant d’envoyer
la requête à ce dernier. Il fait un traitement inverse pour acheminer la
réponse du fournisseur au client. L’ESB est au cœur de tous les échanges entre
les services.
Quelques fonctionnalités de l’ESB
Service de
transport : supporte et convertit les protocoles de transport entre
fournisseur et consommateur de service.
Service de
routage : achemine les messages aux destinataires appropriés.
Service de
transformations de message : transforme le format de message provenant d’un
consommateur dans le format attendu par un fournisseur et
vice-versa.
Service de
connecteur : capable de se connecter à tout type de ressource ou de service,
permettant ainsi de découpler le consommateur au fournisseur de
service.
Services de
sécurité et audit : fonctionnalité d’authentification, d’autorisation, de cryptage
sur les messages entrants afin de prévenir les usages malicieux du bus de
services d’entreprise. La sécurité des messages sortants doit également être
assurée afin de satisfaire les exigences de sécurité du consommateur de
service.
Les problèmes rencontrés
La plus grosse problématique rencontrée par cette implémentation
de SOA est liée à la technologie. En effet, outre le fait que l'ESB devient
potentiellement un point de défaillance pour cette architecture, un autre
inconvénient vient du fait que beaucoup de projets SOA sont tirés par des équipes uniquement techniques et par des approches
outils. Par exemple, dans certaines entreprises, on dépense des budgets importants
pour acheter et déployer un ESB avant même de commencer l’analyse des services,
un peu comme si les services allaient apparaître comme par magie une fois le
bus d’entreprise (ESB) déployé.
Conclusion
L’implémentation de SOA avec un bus de
services d'entreprise, que certains ont appelé SOA de première génération, n’a pas permis
de résoudre tous les problèmes observés avec les monolithes, d’où l’émergence
des architectures micoservices.
Pour démarrer avec les microservices, je vous recommande ce cours sur Udemy: Les bases des architectures de microservices
Pour démarrer avec les microservices, je vous recommande ce cours sur Udemy: Les bases des architectures de microservices
Référence:
Nous remercions sincèrement l'auteur de l'article pour cette analyse approfondie sur les limites de SOA et ESB. Bien que sap s4hana ne soit pas mentionné directement, il est clair que cette solution moderne peut potentiellement surmonter certaines de ces limitations grâce à son architecture avancée et à ses capacités intégrées. L'adoption de SAP S/4HANA pourrait apporter des avantages significatifs aux entreprises cherchant à optimiser leurs processus métier et à renforcer leur agilité face aux défis futurs.
RépondreSupprimer