07 — Architecture orientée services (SOA)

Contenu

07 — Architecture orientée services (SOA)#

Origines et contexte#

À la fin des années 1990, les grandes entreprises (banques, compagnies d’assurance, opérateurs télécom) font face à un problème qui n’existait pas vingt ans plus tôt : elles ont accumulé des systèmes hétérogènes, construits sur des décennies, dans des technologies incompatibles. Un mainframe IBM AS/400 pour la comptabilité, un système COBOL pour les paiements, une application Java pour la gestion des contrats, un portail web en ASP.NET pour les clients. Comment faire dialoguer tout cela ?

Les approches ad hoc — intégration point-à-point, échanges de fichiers CSV par FTP, triggers de base de données — ont créé des spaghettis d’intégration impossibles à maintenir. Ajouter un nouveau système signifiait coder autant de connecteurs que de systèmes existants. N systèmes → N² connexions potentielles.

La Service-Oriented Architecture (SOA) émerge dans ce contexte comme une réponse architecturale à l’intégration d’entreprise. Elle est popularisée par les grands éditeurs de logiciels (IBM, Oracle, BEA, Microsoft) au début des années 2000 et bénéficie de l’appui du W3C et du consortium OASIS pour ses standards.

L’idée centrale : exposer les fonctionnalités des systèmes existants comme des services réutilisables, accessibles via des interfaces standardisées indépendantes de la technologie sous-jacente.

Principes SOA#

Le SOA est défini autour de huit principes, formalisés par Thomas Erl dans son ouvrage de référence :

Contrat de service (Service Contract)#

Chaque service expose un contrat formel qui décrit ses capacités, ses entrées, ses sorties et les contraintes d’utilisation. Ce contrat est la seule chose que le consommateur du service doit connaître. Comment le service est implémenté, quelle base de données il utilise, quel langage de programmation — rien de tout cela ne filtre à travers le contrat.

Couplage faible (Loose Coupling)#

Les services minimisent leur dépendance aux autres services. Un service ne connaît que le contrat des services qu’il consomme, pas leur implémentation. Cette propriété permet de remplacer ou modifier un service sans impacter ses consommateurs, à condition de respecter le contrat.

Abstraction (Service Abstraction)#

Les détails d’implémentation sont masqués. Le consommateur ne sait pas si derrière le service de « vérification de crédit » se trouve un mainframe COBOL, une API REST moderne ou un tableur Excel.

Réutilisabilité (Service Reusability)#

Un service doit être conçu pour être utilisé par plusieurs consommateurs dans plusieurs contextes. C’est une aspiration majeure du SOA — et l’une des sources de ses difficultés, comme on le verra.

Autonomie (Service Autonomy)#

Les services ont le contrôle sur leur logique et leurs ressources. Ils ne partagent pas leur base de données avec d’autres services.

Sans état (Statelessness)#

Les services préservent des ressources en ne gérant pas d’état entre les requêtes. L’état nécessaire à un échange est porté par les messages eux-mêmes.

Composabilité (Service Composability)#

Des services peuvent être combinés pour créer des services de plus haut niveau. Un service « traitement d’une demande de prêt » peut orchestrer les services « vérification d’identité », « vérification de crédit » et « calcul de risque ».

La réutilisabilité : promesse et réalité

La réutilisabilité est l’un des arguments de vente les plus séduisants du SOA. En pratique, elle s’avère difficile à atteindre : un service suffisamment générique pour être réutilisé dans plusieurs contextes tend à devenir trop complexe et trop couplé aux besoins divergents de ses consommateurs. La plupart des organisations ont constaté que les services les plus utiles sont ceux conçus pour un usage spécifique, quitte à en avoir plusieurs qui font des choses similaires.

SOAP et WSDL#

Le protocole dominant du SOA des années 2000 est SOAP (Simple Object Access Protocol), associé à WSDL (Web Services Description Language) pour la description des services et UDDI (Universal Description, Discovery and Integration) pour leur découverte.

Structure d’un message SOAP#

Un message SOAP est une enveloppe XML structurée en deux parties :

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

  <soap:Header>
    <!-- Métadonnées : authentification, transactions, traçabilité -->
    <tns:Authentication>
      <tns:Token>eyJhbGciOiJSUzI1NiJ9...</tns:Token>
    </tns:Authentication>
    <tns:TransactionId>TXN-2024-001-847362</tns:TransactionId>
  </soap:Header>

  <soap:Body>
    <!-- Charge utile : l'appel de méthode et ses paramètres -->
    <tns:VerifierCredit>
      <tns:ClientId>CLI-98765</tns:ClientId>
      <tns:MontantDemande>25000.00</tns:MontantDemande>
      <tns:DureeEnMois>36</tns:DureeEnMois>
    </tns:VerifierCredit>
  </soap:Body>

</soap:Envelope>

La réponse correspondante :

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Header>
    <tns:TransactionId>TXN-2024-001-847362</tns:TransactionId>
  </soap:Header>
  <soap:Body>
    <tns:VerifierCreditResponse>
      <tns:ScoreCredit>742</tns:ScoreCredit>
      <tns:Decision>APPROUVE</tns:Decision>
      <tns:TauxPropose>3.75</tns:TauxPropose>
      <tns:Motif>Score excellent, historique stable</tns:Motif>
    </tns:VerifierCreditResponse>
  </soap:Body>
</soap:Envelope>

WSDL — contrat formel du service#

<!-- Extrait de WSDL décrivant le service VerificationCredit -->
<definitions xmlns="http://schemas.xmlsoap.org/wsdl/"
             targetNamespace="http://exemple.banque.fr/credit">

  <types>
    <schema>
      <element name="VerifierCreditRequest">
        <complexType>
          <sequence>
            <element name="ClientId" type="string"/>
            <element name="MontantDemande" type="decimal"/>
            <element name="DureeEnMois" type="integer"/>
          </sequence>
        </complexType>
      </element>
      <element name="VerifierCreditResponse">
        <complexType>
          <sequence>
            <element name="ScoreCredit" type="integer"/>
            <element name="Decision" type="string"/>
            <element name="TauxPropose" type="decimal"/>
          </sequence>
        </complexType>
      </element>
    </schema>
  </types>

  <portType name="VerificationCreditPort">
    <operation name="VerifierCredit">
      <input message="tns:VerifierCreditRequest"/>
      <output message="tns:VerifierCreditResponse"/>
    </operation>
  </portType>
</definitions>

Limites de SOAP#

Verbosité : l’enveloppe XML ajoute une charge significative à chaque message. Pour des opérations simples, le ratio charge utile / overhead est défavorable.
Rigidité : le typage fort du WSDL est à double tranchant. Il garantit l’interopérabilité mais rend les évolutions de contrat douloureuses.
Complexité : la pile WS-* (WS-Security, WS-ReliableMessaging, WS-AtomicTransaction…) est notoire pour sa complexité d’implémentation.
Couplage au contrat : tout changement de WSDL nécessite de régénérer les clients, ce qui crée des couplages forts entre versions.

REST comme réponse#

Face à la complexité de SOAP, Roy Fielding avait déjà posé en 2000 (dans sa thèse de doctorat) les bases d’un style architectural radicalement différent : REST (Representational State Transfer).

REST n’est pas un protocole mais un ensemble de contraintes architecturales :

Ressources identifiées par des URI : /clients/42, /commandes/847
Manipulation via les verbes HTTP : GET (lire), POST (créer), PUT/PATCH (modifier), DELETE (supprimer)
Stateless : chaque requête contient toutes les informations nécessaires à son traitement
Représentations : une ressource peut être représentée en JSON, XML, HTML selon la négociation de contenu
HATEOAS : les réponses incluent des liens vers les transitions d’état possibles

// Réponse REST — vérification de crédit
GET /clients/CLI-98765/evaluation-credit?montant=25000&duree=36

HTTP/1.1 200 OK
Content-Type: application/json

{
  "client_id": "CLI-98765",
  "score_credit": 742,
  "decision": "APPROUVE",
  "taux_propose": 3.75,
  "_links": {
    "self": {"href": "/clients/CLI-98765/evaluation-credit"},
    "dossier": {"href": "/dossiers/nouveau?client=CLI-98765"},
    "client": {"href": "/clients/CLI-98765"}
  }
}

REST s’impose progressivement dans les années 2000-2010 pour les API publiques (Twitter, Facebook, Amazon S3), puis pour les API internes, en raison de sa simplicité relative et de l’outillage HTTP disponible.

ESB — Enterprise Service Bus#

Au cœur de la SOA des années 2000, l”ESB (Enterprise Service Bus) est le composant d’infrastructure qui médiatise les échanges entre services.

Rôle de l’ESB#

L’ESB n’est pas un simple routeur. Il assure plusieurs fonctions :

Routing : acheminer un message vers le bon service selon son contenu, son type, ou des règles de routage.
Transformation : convertir un message d’un format à un autre (XML SOAP → JSON REST, format A → format B).
Orchestration : coordonner des appels à plusieurs services pour implémenter un processus métier.
Mediation : adapter le protocole (HTTP → JMS, REST → SOAP) et la sécurité.
Monitoring : journaliser et surveiller les échanges.

Enterprise Integration Patterns (EIP)#

Gregor Hohpe et Bobby Woolf ont catalogué en 2003 les Enterprise Integration Patterns, un vocabulaire de 65 patterns pour les architectures d’intégration. Les plus importants :

Pattern	Description	Exemple
Message Channel	Canal point-à-point entre deux systèmes	Queue JMS entre commandes et inventaire
Message Router	Dirige un message selon son contenu	Commandes France → service FR, Allemagne → service DE
Message Translator	Convertit un format en un autre	Format SAP → format interne
Aggregator	Combine plusieurs réponses en une	Rassembler les résultats de 3 systèmes de stock
Splitter	Divise un message en plusieurs	Un fichier de commandes → une commande par message
Dead Letter Queue	Messages non traités stockés pour inspection	Erreurs de traitement → file d’attente d’erreurs
Idempotent Receiver	Déduplication des messages reçus en double	Éviter de traiter deux fois le même paiement

L’ESB : une bonne idée devenue un anti-pattern

L’ESB a souvent évolué vers un ESB intelligent, services stupides — l’inverse de ce qui était prévu. Les équipes centralisent de plus en plus de logique métier dans l’ESB (transformations complexes, règles de routage métier), qui devient un point de défaillance unique et un goulot de gouvernance. Les microservices ont en partie émergé comme réaction à cet anti-pattern.

SOA vs microservices#

La confusion entre SOA et microservices est fréquente. Les deux architectures partagent des principes (services indépendants, couplage faible) mais diffèrent sur des aspects cruciaux.

Dimension	SOA	Microservices
Granularité	Services larges, souvent alignés sur les départements	Services fins, alignés sur les capacités métier
Communication	ESB, SOAP	HTTP/REST direct, messages asynchrones
Partage de données	Bases de données partagées fréquentes	Chaque service a sa propre BDD (idéalement)
Gouvernance	Centralisée (ESB, équipe d’intégration)	Décentralisée (équipes autonomes)
Ownership	Équipe d’intégration souvent propriétaire	Équipe produit propriétaire de bout en bout
Réutilisabilité	Objectif explicite	Objectif secondaire, privilégie la cohésion
Déploiement	Souvent coordonné	Indépendant par service

La distinction la plus importante est organisationnelle : le SOA favorise une gouvernance centralisée (équipe d’architecture, comité de validation, équipe ESB), tandis que les microservices favorisent des équipes autonomes qui possèdent leur service de bout en bout, de la conception au déploiement en production.

Leçons retenues#

La SOA n’a pas échoué — elle a résolu les problèmes d’intégration hétérogène pour lesquels elle avait été conçue. Mais elle a engendré ses propres problèmes, dont les microservices ont tiré des leçons.

Ce que SOA a apporté :

Le concept de service comme unité d’abstraction et de réutilisabilité.
La séparation interface/implémentation à l’échelle système.
Le vocabulaire des Enterprise Integration Patterns, toujours pertinent.
La conscience que l’intégration d’entreprise est un problème architectural sérieux.

Pourquoi les microservices ont émergé :

La complexité de SOAP et des stacks WS-* a poussé vers REST.
Les ESB centralisés sont devenus des goulots d’étranglement et des points de couplage.
Le mouvement DevOps a mis en avant l’autonomie des équipes de déploiement.
Le cloud et la conteneurisation ont rendu le déploiement de nombreux services manageable.
L’essor du DDD (Domain-Driven Design) a fourni un vocabulaire pour définir les frontières des services.

SOA n’est pas mort

Les principes SOA restent très présents dans l’intégration d’entreprise, particulièrement dans les organisations qui ont des systèmes legacy à intégrer. Les plateformes d’intégration modernes (MuleSoft, Azure Integration Services, AWS EventBridge) sont des ESB modernes. La SOA a évolué, pas disparu.

Visualisations#

Parse et affichage d’un message SOAP simulé#

import xml.etree.ElementTree as ET
import textwrap

# Message SOAP simulé
soap_message = """<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:tns="http://exemple.banque.fr/credit">
  <soap:Header>
    <tns:TransactionId>TXN-2024-001-847362</tns:TransactionId>
    <tns:Timestamp>2024-03-15T14:32:00Z</tns:Timestamp>
    <tns:CallerSystem>portail-web-v3</tns:CallerSystem>
  </soap:Header>
  <soap:Body>
    <tns:VerifierCreditResponse>
      <tns:ClientId>CLI-98765</tns:ClientId>
      <tns:ScoreCredit>742</tns:ScoreCredit>
      <tns:Decision>APPROUVE</tns:Decision>
      <tns:TauxPropose>3.75</tns:TauxPropose>
      <tns:MontantMaximal>35000.00</tns:MontantMaximal>
    </tns:VerifierCreditResponse>
  </soap:Body>
</soap:Envelope>"""

def parse_soap(xml_str: str) -> dict:
    """Parse un message SOAP et retourne un dictionnaire structuré."""
    ns = {
        "soap": "http://schemas.xmlsoap.org/soap/envelope/",
        "tns":  "http://exemple.banque.fr/credit",
    }
    root = ET.fromstring(xml_str)

    result = {"header": {}, "body": {}}

    # Header
    header = root.find("soap:Header", ns)
    if header is not None:
        for child in header:
            tag = child.tag.split("}")[-1] if "}" in child.tag else child.tag
            result["header"][tag] = child.text

    # Body
    body = root.find("soap:Body", ns)
    if body is not None:
        for response in body:
            op_name = response.tag.split("}")[-1] if "}" in response.tag else response.tag
            result["body"]["operation"] = op_name
            for child in response:
                tag = child.tag.split("}")[-1] if "}" in child.tag else child.tag
                result["body"][tag] = child.text

    return result

parsed = parse_soap(soap_message)

# Affichage structuré
print("=" * 55)
print("  ANALYSE DU MESSAGE SOAP")
print("=" * 55)

print("\n[EN-TÊTE SOAP]")
for k, v in parsed["header"].items():
    print(f"  {k:<20} : {v}")

print("\n[CORPS SOAP]")
op = parsed["body"].pop("operation", "N/A")
print(f"  Opération              : {op}")
for k, v in parsed["body"].items():
    print(f"  {k:<20} : {v}")

print("\n[STATISTIQUES]")
taille_brute  = len(soap_message.encode("utf-8"))
taille_payload = sum(len(str(v)) for v in parsed["body"].values())
print(f"  Taille totale message  : {taille_brute} octets")
print(f"  Taille charge utile    : ~{taille_payload} octets")
print(f"  Ratio overhead/payload : {taille_brute/taille_payload:.1f}x")
print(f"  Overhead XML/SOAP      : {(1 - taille_payload/taille_brute)*100:.0f}%")
print("=" * 55)

=======================================================
  ANALYSE DU MESSAGE SOAP
=======================================================

[EN-TÊTE SOAP]
  TransactionId        : TXN-2024-001-847362
  Timestamp            : 2024-03-15T14:32:00Z
  CallerSystem         : portail-web-v3

[CORPS SOAP]
  Opération              : VerifierCreditResponse
  ClientId             : CLI-98765
  ScoreCredit          : 742
  Decision             : APPROUVE
  TauxPropose          : 3.75
  MontantMaximal       : 35000.00

[STATISTIQUES]
  Taille totale message  : 725 octets
  Taille charge utile    : ~32 octets
  Ratio overhead/payload : 22.7x
  Overhead XML/SOAP      : 96%
=======================================================

Diagramme ESB avec patterns d’intégration#

import matplotlib.pyplot as plt
import matplotlib.patches as mpatches
import seaborn as sns

sns.set_theme(style="whitegrid", palette="muted", font_scale=1.1)

fig, ax = plt.subplots(figsize=(15, 9))
ax.set_xlim(0, 15)
ax.set_ylim(0, 9)
ax.set_aspect("equal")

def draw_box(ax, x, y, w, h, label, sublabel="", color="#3498db", fontsize=9):
    rect = mpatches.FancyBboxPatch((x, y), w, h,
                                    boxstyle="round,pad=0.1",
                                    facecolor=color, edgecolor="white",
                                    linewidth=2, alpha=0.85)
    ax.add_patch(rect)
    ax.text(x + w/2, y + h/2 + (0.15 if sublabel else 0), label,
            ha="center", va="center", fontsize=fontsize,
            fontweight="bold", color="white")
    if sublabel:
        ax.text(x + w/2, y + h/2 - 0.2, sublabel,
                ha="center", va="center", fontsize=7.5, color="white", alpha=0.9)

# Systèmes sources (gauche)
sources = [
    (0.2, 7.2, "Portail Web", "#3498db"),
    (0.2, 5.5, "App Mobile", "#3498db"),
    (0.2, 3.8, "ERP SAP", "#3498db"),
    (0.2, 2.1, "Mainframe\nCOBOL", "#3498db"),
]
for x, y, label, color in sources:
    draw_box(ax, x, y, 1.8, 0.9, label, color=color, fontsize=8)
    ax.annotate("", xy=(5.0, y + 0.45),
                xytext=(2.0, y + 0.45),
                arrowprops=dict(arrowstyle="-|>", color="#7f8c8d", lw=1.5))

# ESB central
esb_color = "#2c3e50"
draw_box(ax, 5.0, 1.0, 5.0, 7.5, "", color=esb_color)
ax.text(7.5, 8.1, "Enterprise Service Bus (ESB)", ha="center",
        fontsize=11, fontweight="bold", color="#2c3e50")

# Composants ESB internes
esb_components = [
    (5.2, 6.5, 2.1, 0.9, "Router", "Routage par contenu", "#8e44ad"),
    (7.6, 6.5, 2.1, 0.9, "Transformer", "Conversion de format", "#16a085"),
    (5.2, 5.1, 2.1, 0.9, "Orchestrator", "Coordination BPEL", "#d35400"),
    (7.6, 5.1, 2.1, 0.9, "Aggregator", "Fusion de réponses", "#27ae60"),
    (5.2, 3.7, 2.1, 0.9, "Splitter", "Division de messages", "#2980b9"),
    (7.6, 3.7, 2.1, 0.9, "Dead Letter\nQueue", "Erreurs", "#c0392b"),
    (5.2, 2.3, 2.1, 0.9, "Security\nGateway", "Auth · TLS · OAuth", "#7f8c8d"),
    (7.6, 2.3, 2.1, 0.9, "Monitor", "Logs · Métriques", "#1abc9c"),
    (5.9, 1.2, 3.2, 0.8, "Protocol Adapter  (SOAP ↔ REST ↔ JMS)", "", "#34495e"),
]
for comp in esb_components:
    draw_box(ax, comp[0], comp[1], comp[2], comp[3],
             comp[4], comp[5] if len(comp) > 5 else "", comp[6], fontsize=8)

# Systèmes cibles (droite)
targets = [
    (12.0, 7.2, "Service\nCrédit", "#e67e22"),
    (12.0, 5.5, "Service\nPaiement", "#e67e22"),
    (12.0, 3.8, "Service\nNotifs", "#e67e22"),
    (12.0, 2.1, "BDD\nCentrale", "#c0392b"),
]
for x, y, label, color in targets:
    draw_box(ax, x, y, 1.8, 0.9, label, color=color, fontsize=8)
    ax.annotate("", xy=(12.0, y + 0.45),
                xytext=(10.0, y + 0.45),
                arrowprops=dict(arrowstyle="-|>", color="#7f8c8d", lw=1.5))

ax.set_title("Enterprise Service Bus — Architecture et patterns d'intégration",
             fontsize=13, fontweight="bold", pad=15)
ax.axis("off")

plt.savefig("_static/07_esb.png", dpi=150, bbox_inches="tight")
plt.show()

_images/a761e80084fb58b222b0e23b42609868b83e54cda61768705131a14bf8121d06.png

Comparaison SOAP vs REST vs gRPC#

import matplotlib.pyplot as plt
import numpy as np
import seaborn as sns

sns.set_theme(style="whitegrid", palette="muted", font_scale=1.1)

critères = [
    "Performance (latence)",
    "Typage fort du contrat",
    "Facilité d'adoption",
    "Interopérabilité navigateur",
    "Streaming bidirectionnel",
    "Verbosité du message",
    "Outillage humain (lisibilité)",
    "Génération de code client",
    "Maturité (ancienneté)",
    "Adapté au web public",
]

# Scores /5 pour chaque protocole
scores_soap  = [2, 5, 2, 1, 1, 1, 2, 4, 5, 2]
scores_rest  = [3, 2, 5, 5, 2, 4, 5, 2, 4, 5]
scores_grpc  = [5, 5, 3, 2, 5, 5, 2, 5, 3, 2]

x = np.arange(len(critères))
width = 0.28

fig, ax = plt.subplots(figsize=(14, 8))

bars_soap = ax.barh(x + width, scores_soap, width, label="SOAP/WSDL",
                    color="#e74c3c", alpha=0.85)
bars_rest = ax.barh(x, scores_rest, width, label="REST/JSON",
                    color="#3498db", alpha=0.85)
bars_grpc = ax.barh(x - width, scores_grpc, width, label="gRPC/Protobuf",
                    color="#2ecc71", alpha=0.85)

for bars in [bars_soap, bars_rest, bars_grpc]:
    for bar in bars:
        v = int(bar.get_width())
        if v > 0:
            ax.text(bar.get_width() + 0.05, bar.get_y() + bar.get_height()/2,
                    f"{v}", va="center", ha="left", fontsize=8)

ax.set_yticks(x)
ax.set_yticklabels(critères, fontsize=10)
ax.set_xlabel("Score (5 = excellent)", fontsize=11)
ax.set_xlim(0, 7)
ax.set_title("Comparaison SOAP · REST · gRPC", fontsize=14, fontweight="bold")
ax.legend(fontsize=11, loc="lower right")
ax.axvline(3, color="#bdc3c7", linestyle="--", alpha=0.7)

plt.savefig("_static/07_soap_rest_grpc.png", dpi=150, bbox_inches="tight")
plt.show()

_images/e55ae1c4ef6aa76250f1027259e35191d0982d7fd637040b1a88afa85bf214f1.png

Timeline SOA → REST → microservices → serverless#

import matplotlib.pyplot as plt
import matplotlib.patches as mpatches
import seaborn as sns

sns.set_theme(style="whitegrid", palette="muted", font_scale=1.1)

fig, ax = plt.subplots(figsize=(16, 6))
ax.set_xlim(1995, 2030)
ax.set_ylim(-3, 4)

# Ligne de temps
ax.axhline(0, color="#bdc3c7", linewidth=2.5, zorder=1)

# Événements clés
events = [
    # (année, y_label, label, couleur, taille_pt)
    (1996, 1.5,  "CORBA\npopularisé",        "#95a5a6", 100),
    (1998, 1.0,  "XML-RPC\n(précurseur SOAP)","#95a5a6", 100),
    (2000, 2.2,  "Thèse REST\n(Fielding)",    "#3498db", 150),
    (2001, 1.5,  "SOAP 1.1\nW3C",             "#e74c3c", 130),
    (2002, 2.0,  "WSDL 1.1\nUDDI",            "#e74c3c", 130),
    (2003, 2.5,  "EIP Book\n(Hohpe & Woolf)", "#e67e22", 120),
    (2004, 1.5,  "ESB\ngénéralisé",           "#e67e22", 140),
    (2006, 2.2,  "Amazon S3\nAPI REST",       "#3498db", 140),
    (2007, 1.5,  "Twitter API\n(REST)",        "#3498db", 130),
    (2011, 2.5,  "Netflix\nMicroservices",    "#2ecc71", 150),
    (2013, 2.0,  "Docker",                    "#2ecc71", 130),
    (2014, 1.5,  "Article Fowler\nMicroservices", "#2ecc71", 130),
    (2014, -1.5, "gRPC\n(Google)",            "#9b59b6", 130),
    (2016, 2.2,  "Kubernetes\nGA",            "#2ecc71", 140),
    (2016, -1.5, "AWS Lambda\nGA",            "#f39c12", 130),
    (2018, -1.5, "Serverless\nmainstream",    "#f39c12", 150),
    (2020, 2.0,  "Service Mesh\n(Istio)",     "#1abc9c", 130),
    (2024, 1.5,  "Platform\nEngineering",     "#1abc9c", 120),
]

colors_map = {
    "#95a5a6": "Legacy / pré-SOA",
    "#e74c3c": "SOA / SOAP",
    "#e67e22": "ESB / EIP",
    "#3498db": "REST",
    "#2ecc71": "Microservices",
    "#9b59b6": "gRPC",
    "#f39c12": "Serverless",
    "#1abc9c": "Cloud Native",
}

for année, y, label, couleur, taille in events:
    ax.scatter(année, 0, s=taille, color=couleur, zorder=3, alpha=0.9)
    ax.plot([année, année], [0, y * 0.85], color=couleur,
            linewidth=1.2, linestyle="--", alpha=0.5, zorder=2)
    ax.text(année, y, label, ha="center", va="bottom" if y > 0 else "top",
            fontsize=7.5, color=couleur, fontweight="bold")

# Ères
ères = [
    (1996, 2002, "#e74c3c", "Ère SOA/SOAP"),
    (2006, 2012, "#3498db", "Ère REST"),
    (2012, 2020, "#2ecc71", "Ère Microservices"),
    (2016, 2025, "#f39c12", "Ère Serverless/Cloud Native"),
]
for debut, fin, couleur, label in ères:
    ax.axvspan(debut, fin, alpha=0.06, color=couleur)
    ax.text((debut + fin) / 2, -2.5, label, ha="center", fontsize=9,
            color=couleur, fontweight="bold")

ax.set_xlabel("Année", fontsize=11)
ax.set_yticks([])
ax.set_xlim(1995, 2028)

# Légende
legend_patches = [mpatches.Patch(color=c, label=l, alpha=0.8)
                  for c, l in colors_map.items()]
ax.legend(handles=legend_patches, loc="upper left", fontsize=8,
          ncol=2, bbox_to_anchor=(0, 1.0))

ax.set_title("Timeline des architectures distribuées : SOA → REST → Microservices → Serverless",
             fontsize=13, fontweight="bold", pad=15)

plt.savefig("_static/07_timeline.png", dpi=150, bbox_inches="tight")
plt.show()

_images/a955ac80b7e1c855a270bb1cc7da5490107797b7b72808ce0eab94522a708f19.png

Résumé#

La Service-Oriented Architecture est née d’un besoin réel : intégrer des systèmes hétérogènes accumulés sur des décennies dans les grandes entreprises. Elle a apporté un vocabulaire, des standards et des patterns qui restent pertinents aujourd’hui.

Points clés :

La SOA émerge dans les années 2000 pour résoudre l’intégration d’entreprise, avec SOAP/WSDL comme protocoles dominants et l’ESB comme infrastructure de médiation.
Les huit principes SOA (contrat, couplage faible, abstraction, réutilisabilité, autonomie, statelessness, composabilité) définissent un idéal rarement atteint dans sa totalité.
SOAP est puissant (typage fort, transactions distribuées, WS-Security) mais verbeux et rigide. REST a supplanté SOAP pour la plupart des usages grâce à sa simplicité et son alignement sur HTTP.
L’ESB centralise le routage, la transformation et l’orchestration des messages. Il tend néanmoins à devenir un point de couplage et de goulot organisationnel quand la logique métier y migre.
Les Enterprise Integration Patterns de Hohpe & Woolf restent une référence incontournable pour tout architecte travaillant avec des systèmes distribués ou d’intégration.
Les microservices ont émergé en réaction aux limites de la SOA centralisée : ESB trop complexe, gouvernance rigide, granularité trop large des services, manque d’autonomie des équipes.
La SOA n’est pas obsolète : les plateformes d’intégration modernes (MuleSoft, Azure Integration Services) en sont l’évolution, toujours essentielles pour l’intégration de systèmes legacy.

Retenez les patterns, pas le protocole

SOAP et WSDL sont aujourd’hui marginaux pour les nouvelles architectures. Mais les Enterprise Integration Patterns (Router, Transformer, Aggregator, Dead Letter Queue…) restent le vocabulaire de référence pour concevoir des systèmes d’intégration, qu’ils soient implémentés avec un ESB traditionnel, Kafka, ou des fonctions cloud.