Architecture orientée services (SOA) et bus de services d'entreprise (ESB)

L'architecture orientée services (SOA, pour service-oriented architecture) a été la réponse des grandes entreprises à un problème toujours d'actualité : des dizaines d'applications, chacune construite pour un seul département, chacune avec sa propre copie des données clients, reliées entre elles par des centaines de transferts de fichiers et de liens de base de données non documentés. La SOA proposait d'exposer les capacités de chaque application sous forme de services pilotés par leur contrat, de faire transiter les appels par une infrastructure partagée et de composer les processus métier à partir de ces services. Le style a connu son apogée dans les années 2000, a souvent été sur-conçu, puis est discrètement devenu le socle sur lequel se sont bâtis les microservices et les plateformes d'API. Le comprendre éclaire une bonne partie des systèmes dont vous hériterez et du vocabulaire qu'emploient vos architectes.

Le problème : silos et plat de spaghettis

Une entreprise grandit application après application. Les ventes obtiennent un CRM, la finance un ERP, les opérations développent un outil de planification maison, et chacun détient « la » fiche client. Dès qu'un processus traverse plusieurs départements — de la commande à l'encaissement, de la déclaration de sinistre au paiement — les données doivent circuler entre ces silos, et la solution la moins chère sur le moment est un lien point à point : un extrait nocturne, une vue en base, un appel d'API direct.

Avec n applications, l'intégration point à point tend vers n(n−1)/2 interfaces. Chacune est construite une fois, rarement documentée, et n'appartient plus à personne après le départ de son auteur. Les conséquences sont prévisibles :

• Des données redondantes et incohérentes. Trois référentiels clients qui ne s'accordent pas sur une adresse.
• Un couplage fort. Modifier une table du CRM casse un rapport de la finance dont personne ne savait qu'il la lisait.
• Aucune réutilisation. Le scoring de crédit est réimplémenté dans le système de prêts, celui des cartes et celui du leasing.
• Des processus rigides. Un nouveau canal de distribution (mobile, portail partenaire) impose de reconstruire toutes les intégrations.
• Une qualité de service impossible à mesurer. Personne ne peut dire quelle est la disponibilité ou le temps de réponse de « récupérer un client », parce que cela n'existe pas — il n'y a que quinze façons de lire la table.

Le postulat de la SOA est qu'il s'agit de problèmes d'architecture, pas de problèmes de projet, et que la solution consiste à introduire une couche de services aux contrats explicites entre les processus qui ont besoin de capacités et les applications qui les fournissent.

Ce qui fait un service

Les définitions varient, mais les propriétés qui comptent en pratique se retrouvent dans toutes.

Un service expose un contrat et masque son implémentation. Les consommateurs voient une interface — opérations, formats de message, engagements de qualité de service — et rien d'autre. Le consommateur ne doit ni savoir ni se soucier de savoir si le service repose sur un mainframe, une application Java ou une macro de tableur.

Les frontières sont explicites. Appeler un service, c'est échanger des messages à travers une frontière, avec la latence et les modes de défaillance que cela implique. C'est différent d'appeler une méthode sur un composant du même processus, et les conceptions qui font semblant du contraire (des services fins et bavards) échouent.

Les services sont autonomes. Chacun peut être déployé, versionné et exploité indépendamment, et il possède les données nécessaires pour honorer son contrat. Les bases de données partagées entre services violent ce principe, et c'est la façon la plus courante dont les programmes SOA se sont sabordés.

La compatibilité repose sur des politiques, pas sur du code. Le droit d'un consommateur à appeler un service est déterminé par des exigences déclarées — sécurité, transport, fiabilité — et non par le partage de bibliothèques.

Deux autres attributs de conception décident si un service est réellement réutilisable. La granularité doit convenir au consommateur : un service qui renvoie tout le dossier client alors que l'appelant veut un code postal est un gaspillage ; un service qui exige douze appels pour reconstituer une adresse est bavard. L'absence d'état (statelessness) — aucun état conversationnel conservé entre les appels — rend les services plus faciles à faire monter en charge et à remplacer ; c'est donc la règle par défaut, les processus longs étant confiés à une couche de processus explicite plutôt qu'à un état de session dans le service.

Services et composants

Un composant est une unité de déploiement à l'intérieur d'une application : il a des interfaces fournies et requises, des propriétés de configuration et un cycle de vie géré par un conteneur. Un service est une unité de capacité métier offerte à plusieurs applications. La spécification Service Component Architecture (SCA) a tenté d'unifier les deux — assembler des composites de composants et les exposer comme services via des bindings configurables (SOAP, JMS, RMI) — et c'est une grille de lecture utile même si vous n'utilisez jamais de runtime SCA : les composants servent à construire un service, les services sont ce que vous exposez.

La pile des web services

La SOA est un style ; les web services SOAP en ont été l'implémentation dominante pendant une décennie. Trois spécifications portent l'essentiel de l'édifice.

SOAP (à l'origine Simple Object Access Protocol ; l'acronyme a été abandonné avec la version 1.2) définit une enveloppe XML avec un en-tête pour les métadonnées — jetons de sécurité, adressage, contexte transactionnel — et un corps qui transporte la charge utile. Il est indépendant du transport, même si HTTP est utilisé presque partout.

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
  <soap:Header>
    <!-- WS-Security, WS-Addressing and similar headers go here -->
  </soap:Header>
  <soap:Body>
    <getBalance xmlns="urn:example:accounts">
      <accountNumber>FR7630006000011234567890189</accountNumber>
    </getBalance>
  </soap:Body>
</soap:Envelope>

WSDL (Web Services Description Language) est le contrat lisible par une machine. Un document WSDL 1.1 déclare les types XML Schema utilisés, les structures message, un portType qui liste les opérations, un binding qui indique comment ces opérations se projettent sur un protocole (en général SOAP sur HTTP), et un service qui donne l'adresse de l'endpoint. L'outillage en génère des stubs clients et des squelettes serveur, ce qui explique pourquoi le développement contract-first allait de soi dans cet univers : écrire le WSDL et le schéma, générer, puis implémenter.

<definitions name="Accounts" targetNamespace="urn:example:accounts"
             xmlns="http://schemas.xmlsoap.org/wsdl/">
  <types><!-- XML Schema for request/response elements --></types>
  <message name="getBalanceRequest"><part name="body" element="tns:getBalance"/></message>
  <message name="getBalanceResponse"><part name="body" element="tns:getBalanceResponse"/></message>
  <portType name="AccountsPort">
    <operation name="getBalance">
      <input message="tns:getBalanceRequest"/>
      <output message="tns:getBalanceResponse"/>
    </operation>
  </portType>
  <binding name="AccountsSoap" type="tns:AccountsPort"><!-- SOAP/HTTP details --></binding>
  <service name="AccountsService">
    <port name="AccountsSoap" binding="tns:AccountsSoap">
      <soap:address location="https://api.example.com/accounts"/>
    </port>
  </service>
</definitions>

UDDI (Universal Description, Discovery and Integration) était l'annuaire où les services devaient être publiés et découverts. Les annuaires UDDI publics ont fermé il y a des années ; les annuaires privés ont survécu comme composant « registry and repository » des outils de gouvernance, et l'idée réapparaît aujourd'hui sous la forme de catalogues d'API et de portails développeurs.

Autour de ces trois piliers gravitaient les spécifications WS-* : WS-Security pour signer et chiffrer les messages, WS-ReliableMessaging pour la livraison garantie, WS-Addressing pour le routage, WS-AtomicTransaction pour le commit à deux phases entre services. Elles résolvaient de vrais problèmes, et elles expliquent aussi la réputation de complexité de SOAP : l'interopérabilité entre les piles des différents éditeurs était fragile, et peu d'équipes avaient besoin d'autre chose que de la sécurité.

REST sur HTTP avec JSON a supplanté SOAP pour la plupart des nouvelles interfaces, parce qu'il ne demande aucun outillage particulier, s'appuie naturellement sur l'infrastructure de cache et de sécurité du web, et permet d'écrire un client en un après-midi. La contrepartie est que REST n'a pas de langage de contrat standard d'une rigueur équivalente, un manque qu'OpenAPI a comblé plus tard. Le guide conception d'API REST traite ce style en profondeur ; SOAP mérite toujours d'être lu couramment, car tant de systèmes centraux de l'entreprise le parlent encore.

Le bus de services d'entreprise

Un bus de services d'entreprise (ESB) est un middleware qui s'intercale entre les consommateurs et les fournisseurs de services et assure la médiation. Ses responsabilités typiques sont les suivantes :

Les patterns de conception qu'implémente un ESB — content-based router, message translator, splitter, aggregator, dead-letter channel — sont catalogués dans la littérature des Enterprise Integration Patterns, et restent tout aussi pertinents quand vous construisez la même chose avec un broker et quelques services.

Un concept souvent associé est le modèle de données canonique : un schéma unique à l'échelle de l'entreprise pour « client », « commande », etc., vers lequel le format de chaque application est traduit. Il réduit le nombre de transformations de n² à 2n, mais tend à devenir un schéma gigantesque de plus petit dénominateur commun que toutes les équipes doivent faire évoluer ensemble. Les conceptions modernes gardent les formats propres à chaque bounded context et traduisent à la frontière, une idée développée dans le guide domain-driven design.

Là où le bus a déraillé

Le travers de l'ESB, c'est qu'il est commode d'y mettre de la logique. Une règle de routage devient une validation, une validation devient un appel d'enrichissement, et en quelques années le bus contient les règles métier les plus importantes de l'entreprise, détenues par une équipe d'intégration centrale derrière laquelle chaque projet fait la queue. Chaque déploiement du bus devient un événement à haut risque, puisque tout passe par lui. Les éditeurs ont vendu des suites toujours plus vastes — bus, moteur de processus, moteur de règles, annuaire, monitoring — et le coût des licences et des compétences a poussé les organisations vers une instance unique partagée, ce qui a maximisé le couplage.

La leçon qu'en ont tirée les microservices tient en une formule : « smart endpoints, dumb pipes » (des extrémités intelligentes, des tuyaux simples). La transformation et les règles restent dans les services qui possèdent les données, et l'infrastructure ne sert qu'à transporter les messages. La logique d'intégration n'a pas disparu ; elle a migré là où se trouve la connaissance du domaine.

Processus, orchestration et chorégraphie

Les services prennent de la valeur lorsqu'ils sont composés en processus métier. Deux modèles coexistent.

L'orchestration confie la direction à un chef d'orchestre central — un moteur de processus qui exécute un modèle écrit en BPMN (Business Process Model and Notation) ou, historiquement, en BPEL. Le moteur appelle les services dans l'ordre, attend les réponses ou les tâches humaines, gère les délais et les escalades, et enregistre l'état de chaque instance en cours. Les analystes métier peuvent lire le modèle ; l'exploitation voit où chaque instance est bloquée. Le moteur est aussi l'endroit unique où tout le processus se retrouve couplé.

La chorégraphie n'a pas de chef d'orchestre. Chaque service réagit aux événements publiés par les autres : quand une commande est passée, l'inventaire réserve le stock et publie « stock réservé », la facturation débite la carte en recevant cet événement, l'expédition déclenche la livraison en recevant « paiement capturé ». Le couplage est minimal et chaque équipe possède son étape, mais personne n'a la vue de bout en bout, et répondre à « où en est la commande 4711 ? » exige de corréler des événements entre services.

Le guide transactions distribuées revient sur ce choix dans le contexte des sagas ; le même compromis se retrouve à toutes les échelles.

À côté des moteurs de processus se trouvent les moteurs de règles métier, qui sortent la logique de décision — éligibilité, tarification, scoring — du code pour la placer dans des tables de règles que le métier peut maintenir. Vendus avec la suite SOA, ils sont utiles précisément quand les règles changent plus souvent que le logiciel qui les entoure ; ils deviennent contre-productifs lorsqu'ils se transforment en second langage de programmation que personne ne teste.

Gouvernance et méthode

La SOA vit ou meurt par sa gouvernance, car la réutilisation n'a lieu que si les services sont trouvables, dignes de confiance et stables.

• Portefeuille de services et responsabilité. Chaque service a un responsable nommé, un état de cycle de vie (planifié, actif, déprécié, retiré) et une politique de versioning. Les versions dépréciées tournent en parallèle, avec une date de fin de vie publiée.
• Contrats et qualité de service. Le contrat inclut des engagements non fonctionnels : temps de réponse par opération, disponibilité, fraîcheur des données (temps réel ou batch de nuit), limites de débit. Sans eux, un consommateur ne peut pas décider si un service convient à son usage.
• Standards de conception. Nommage, conventions de schéma, gestion des erreurs et profils de sécurité sont convenus une fois pour toutes, afin que les consommateurs n'aient pas à apprendre un nouveau dialecte par service.
• Annuaire. Un catalogue où sont consignés les services, les contrats, les responsables et les consommateurs. Son descendant moderne est le portail développeurs d'une plateforme d'API management.

La méthode de conception classique procède de haut en bas, du processus métier vers le service : modéliser les processus, identifier les entités métier et les activités qui agissent sur elles, regrouper les activités en services candidats selon la cohésion et la réutilisation, rattacher chaque candidat à une application existante ou à un nouveau développement, puis définir les contrats. Les approches ascendantes — encapsuler l'existant et l'exposer — livrent plus vite mais reproduisent la forme des silos. La plupart des programmes ont besoin des deux : l'ascendant la première année pour prouver la valeur, le descendant pour dessiner la suite.

SOA et microservices comparés

Les deux styles partagent leurs principes et diffèrent par leur périmètre, leur granularité et leur infrastructure.

Voyez cette comparaison comme un continuum plutôt qu'un verdict. Une organisation qui compte deux cents progiciels a toujours besoin d'une architecture d'intégration à l'échelle de l'entreprise, et les leçons de la gouvernance SOA s'y appliquent directement ; une équipe produit qui découpe un monolithe a besoin de la méthode des microservices. L'erreur consiste à appliquer l'une ou l'autre à la mauvaise échelle.

Erreurs courantes

Des services qui exposent la base de données. Un « service client » doté des opérations getCustomerRow et updateCustomerRow est une table distante, pas un service ; chaque consommateur dépend toujours du schéma. Correctif : des opérations exprimées en termes métier (openAccount, changeAddress), avec le schéma masqué.

Des interfaces fines et bavardes. Concevoir des opérations SOAP comme des méthodes locales produit dix allers-retours par écran. Correctif : des opérations à gros grain qui renvoient en un seul appel ce dont un cas d'usage a besoin.

Tout faire passer par le bus. Deux services d'une même équipe qui s'appellent via l'ESB central ajoutent de la latence, une dépendance de déploiement et une file de tickets. Correctif : réserver le bus à l'intégration inter-domaines et aux systèmes hérités ; laisser les services étroitement liés se parler directement.

Le modèle canonique comme monolithe. Un schéma d'entreprise unique que chaque projet doit étendre. Correctif : des formats canoniques par domaine métier, avec traduction aux frontières.

Une gouvernance sans automatisation. Des comités de revue qui approuvent chaque contrat à la main deviennent le goulet d'étranglement et finissent contournés. Correctif : encoder les standards sous forme de linters, de tests de contrat et de contrôles dans le pipeline ; réserver la revue humaine aux décisions de conception.

Ignorer la qualité de service. Publier un service sans annoncer son temps de réponse ni sa disponibilité. Correctif : chaque contrat énonce des engagements mesurables, et le monitoring prouve qu'ils sont tenus.

Points clés à retenir

• La SOA s'attaquait à de vrais problèmes — silos, spaghettis point à point, données et logique dupliquées — en introduisant des services pilotés par leur contrat, aux frontières explicites.
• Un service masque son implémentation, possède ses données, est autonome et sans état par défaut, et se conçoit à une granularité adaptée à ses consommateurs.
• SOAP, WSDL et les spécifications WS-* ont mis en œuvre la SOA dans les années 2000 ; REST et OpenAPI les ont remplacés pour les nouvelles interfaces, mais les systèmes SOAP restent omniprésents.
• L'ESB assure routage, transformation, passerelle entre protocoles et orchestration ; son travers est d'absorber la logique métier et de devenir un goulet d'étranglement central.
• L'orchestration offre visibilité et contrôle au prix d'un couplage central ; la chorégraphie offre l'autonomie au prix de la vue de bout en bout.
• La gouvernance — responsables, contrats assortis d'engagements de qualité de service, standards, annuaire — est ce qui rend la réutilisation réelle, et elle ne fonctionne que si elle est automatisée.
• Les microservices gardent les principes de la SOA et en rejettent l'infrastructure et la centralisation ; choisissez selon l'échelle, pas selon la mode.