SOA et Web Services¶

L'industrialisation des services — quand l'interopérabilité a enfin fonctionne, mais que la gouvernance a pris le dessus.

L'émergence de SOA¶

SOA (Service-Oriented Architecture) est ne d'un constat pragmatique : les entreprises avaient des dizaines d'applications qui ne communiquaient pas entre elles. Le mainframe de la comptabilité ignorait le système CRM. L'ERP ne parlait pas au système de gestion des stocks. Chaque tentative d'intégration point-à-point créait un réseau de connexions inextricable — le fameux "plat de spaghetti".

Josuttis, dans SOA in Practice, définit SOA non pas comme une technologie mais comme un style architectural. L'idée fondatrice : exposer les capacités métier sous forme de services réutilisables, avec des contrats explicites et un couplage lâche.

Les principes SOA selon Josuttis¶

Ces principes sont remarquablement proches de ce que les microservices revendiqueront quinze ans plus tard. La différence tient moins aux principes qu'a leur mise en œuvre.

Web Services : SOAP, WSDL, UDDI¶

Les Web Services sont la technologie qui a donne un corps a SOA. Contrairement aux objets distribués (CORBA, DCOM), les Web Services reposent sur des standards ouverts et passent à travers les firewalls via HTTP.

SOAP (Simple Object Access Protocol)¶

SOAP est un protocole d'échange de messages structure en XML. Chaque message SOAP est une enveloppe contenant un en-tête (optionnel) et un corps.

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope
    xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:ban="http://banque.exemple.com/services">

    <soap:Header>
        <ban:Authentification>
            <ban:Token>eyJhbGciOiJIUzI1NiJ9...</ban:Token>
        </ban:Authentification>
    </soap:Header>

    <soap:Body>
        <ban:ConsulterSolde>
            <ban:NumeroCompte>FR76-3000-1234-5678</ban:NumeroCompte>
        </ban:ConsulterSolde>
    </soap:Body>

</soap:Envelope>

La réponse suit le même format :

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
    <soap:Body>
        <ConsulterSoldeReponse>
            <Solde>12450.00</Solde>
            <Devise>EUR</Devise>
            <DateMiseAJour>2025-01-15T14:30:00Z</DateMiseAJour>
        </ConsulterSoldeReponse>
    </soap:Body>
</soap:Envelope>

WSDL (Web Services Description Language)¶

WSDL décrit le contrat du service en XML : quelles opérations sont disponibles, quels sont les parametres d'entree et de sortie, quel protocole utiliser, à quelle adresse envoyer les requêtes.

C'est l'héritier de l'IDL de CORBA, mais en plus verbeux. Un fichier WSDL pour un service simple pouvait atteindre plusieurs centaines de lignes. Les outils generaient automatiquement le code client et serveur à partir du WSDL — une approche "contract-first" qui garantissait la cohérence entre le contrat et l'implémentation.

UDDI (Universal Description, Discovery and Intégration)¶

UDDI etait un annuaire centralise de services. L'idée : les fournisseurs publient leurs services dans UDDI, les consommateurs les decouvrent dynamiquement. En pratique, UDDI n'a jamais decolle. Les entreprises preferaient des catalogues internes maintenus manuellement. Le concept de découverte dynamique de services reapparaitra avec les service registries (Consul, Eureka) des architectures microservices.

La pile WS-*¶

Au-dessus de SOAP, un ensemble de spécifications complementaires — la pile WS-* — a été développé pour répondre aux besoins entreprise :

Kamima et Montfort (Les Web Services) detaillent cette pile avec un regard pratique. Leur analyse montre que chaque spécification resolvait un problème réel, mais que l'empilement créait une complexité qui depassait la capacité d'absorption de la plupart des équipes.

L'ESB : le hub d'intégration¶

L'ESB (Enterprise Service Bus) est devenu le composant central des architectures SOA. C'est un middleware qui assure le routage, la transformation et l'orchestration des messages entre services.

graph TB
    subgraph "Consommateurs"
        APP1["Application Web"]
        APP2["Application Mobile"]
        APP3["Partenaire B2B"]
    end

    subgraph "ESB"
        RT["Routage"]
        TR["Transformation<br/>XML ↔ JSON ↔ CSV"]
        OR["Orchestration<br/>BPEL"]
        MON["Monitoring"]
        RT --- TR
        TR --- OR
        OR --- MON
    end

    subgraph "Fournisseurs de services"
        ERP["ERP (SAP)"]
        CRM["CRM (Siebel)"]
        LEG["Mainframe COBOL"]
        BDD["Base de donnees"]
    end

    APP1 --SOAP/HTTP--> RT
    APP2 --SOAP/HTTP--> RT
    APP3 --AS2/ebXML--> RT

    OR --adaptateur SAP--> ERP
    OR --adaptateur JDBC--> BDD
    OR --adaptateur CICS--> LEG
    OR --adaptateur Siebel--> CRM

L'ESB géré les adaptateurs spécifiques à chaque système cible, la transformation de format (le CRM envoie du XML, le mainframe attend du COBOL copybook), le routage intelligent (en fonction du contenu du message, de l'émetteur, de règles métier) et le monitoring des flux.

Les produits ESB dominants etaient IBM WebSphere ESB, TIBCO BusinessWorks, Oracle Service Bus, Mule ESB et Microsoft BizTalk.

Orchestration et BPEL¶

BPEL (Business Process Exécution Language) permet de définir des processus métier comme des enchainements de services. Un processus BPEL est un programme XML qui appelle des services, géré les conditions, les boucles, les compensations en cas d'erreur.

graph TB
    START["Debut : commande recue"] --> VERIF["Service : verifier stock"]
    VERIF -->|En stock| PAIEMENT["Service : traiter paiement"]
    VERIF -->|Rupture| NOTIF_RUPTURE["Service : notifier client"]
    PAIEMENT -->|Accepte| EXPED["Service : creer expedition"]
    PAIEMENT -->|Refuse| ANNUL["Service : annuler commande"]
    EXPED --> NOTIF_OK["Service : notifier client"]
    NOTIF_OK --> FIN["Fin"]
    NOTIF_RUPTURE --> FIN
    ANNUL --> FIN

L'orchestration BPEL centralisait la logique de processus dans l'ESB. C'est la différence fondamentale avec la choregraphie, ou chaque service décidé autonomement comment reagir aux événements — un modèle que les architectures event-driven reprendront.

Pourquoi SOA a échoué dans beaucoup d'entreprises¶

SOA n'a pas échoué en tant que concept — ses principes sont toujours valides. Ce qui a échoué, c'est sa mise en œuvre typique dans les grandes entreprises.

L'ESB monolithique¶

L'ESB devait être un facilitateur. Il est devenu un goulot d'étranglement. Toute la logique d'intégration — routage, transformation, orchestration — etait centralisee dans une seule plateforme, gérée par une seule équipe. Chaque nouvelle intégration imposait un changement de l'ESB, soumis aux cycles de release de l'équipe middleware.

La gouvernance paralysante¶

La promesse de réutilisabilité a engendre une bureaucratie de gouvernance. Avant de créer un nouveau service, il fallait vérifier qu'il n'en existait pas un similaire, obtenir l'approbation du comite d'architecture, respecter les standards de nommage, documenter le service dans le registre. Le coût de création d'un service depassait souvent le coût de reimplementation locale.

Le syndrome du "big design up front"¶

SOA encourageait la conception préalable d'un modèle de services couvrant l'ensemble du SI — le "modèle canonique". Ce modèle, necessairement abstrait et consensuel, ne correspondait aux besoins précis d'aucune équipe. Les équipes contournaient les services officiels ou les enrichissaient de façons non prévues.

La complexité XML¶

La verbosity de SOAP et WSDL n'etait pas un simple inconvénient esthetique. Elle rendait le debugging difficile, les messages volumineux, et les outils de développement lourds. Un développeur devait maîtriser XML, XSD, XSLT, WSDL, SOAP, WS-* — un investissement cognitif considérable pour envoyer une requête a un service.

REST comme réaction a SOAP¶

Roy Fielding a formalisé REST dans sa these de doctorat en 2000, mais c'est l'adoption par les geants du web (Amazon, Google, Twitter) à partir de 2005-2008 qui a fait basculer l'industrie.

REST n'est pas un protocole — c'est un style architectural qui utilise les mécanismes natifs de HTTP : les verbes (GET, POST, PUT, DELETE), les URI comme identifiants de ressources, les codes de réponse, le cache, la negociation de contenu.

La ou SOAP definissait ses propres conventions par-dessus HTTP (tout passe par POST, les erreurs sont dans l'enveloppe SOAP), REST utilisé HTTP tel qu'il a été conçu. Un GET est idempotent et cacheable. Un 404 signifie que la ressource n'existe pas. Un 201 signifie qu'une ressource a été créée.

La simplicité de REST — un appel HTTP retourné du JSON — a conquis les développeurs. Pas de WSDL a générer, pas de stub a compiler, pas d'outillage spécifique. Un simple curl suffit pour tester un service REST. Cette accessibilite a change les règles du jeu.

REST n'a pas résolu tous les problèmes que WS-* adressait (transactions distribuées, livraison garantie, sécurité au niveau message), mais il a montre que pour 90% des cas d'usage, ces mécanismes n'etaient pas nécessaires. Le pragmatisme a vaincu l'exhaustivité.

Chapitre suivant : Urbanisation du SI — organiser le système d'information comme on planifie une ville.