Master 2 GLIA Notes

SOAP - Simple Object Access Protocol

6 min de lecture

Qu’est-ce que SOAP ?

SOAP est un protocole de messagerie XML pour l’échange d’informations structurées dans les services web. Il permet la communication entre applications indépendamment des plateformes et langages.

Les 3 rôles principaux de SOAP

  1. Enveloppe (Envelope) : Définit le cadre pour décrire le contenu du message et comment le traiter
  2. Règles d’encodage : Définit comment représenter les types de données de l’application
  3. Convention RPC : Définit une convention pour représenter les appels de procédures distantes et leurs réponses

Structure d’un message SOAP

<?xml version="1.0"?>
<soap:Envelope 
    xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    
    <soap:Header>
        <!-- Informations optionnelles : authentification, transaction, routing -->
    </soap:Header>
    
    <soap:Body>
        <!-- Contenu principal du message : requête ou réponse -->
    </soap:Body>
    
</soap:Envelope>

Composants

Envelope : Élément racine obligatoire qui identifie le document XML comme un message SOAP

Header (optionnel) : Contient des informations de méta-données

  • Authentification
  • Informations de transaction
  • Routage
  • Peut contenir plusieurs blocs d’en-tête

Body (obligatoire) : Contient les données réelles du message

  • Requête ou réponse
  • Peut contenir un élément Fault pour les erreurs

Attributs SOAP importants

mustUnderstand

<soap:Header>
    <m:Transaction 
        xmlns:m="http://www.example.org/transaction"
        soap:mustUnderstand="1">
        <transactionID>12345</transactionID>
    </m:Transaction>
</soap:Header>
  • Valeur “1” ou “true” : Le destinataire DOIT comprendre et traiter cet en-tête
  • Si non compris : le destinataire doit rejeter le message avec une erreur
  • Permet de garantir le traitement de fonctionnalités critiques

encodingStyle

<soap:Body soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding">
    <!-- Données encodées selon le style spécifié -->
</soap:Body>
  • Définit les règles de sérialisation des données
  • Peut être appliqué à n’importe quel élément SOAP
  • Hérité par les éléments enfants

Namespaces XML dans SOAP

Les namespaces évitent les conflits de noms entre éléments :

<soap:Envelope 
    xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
    xmlns:m="http://www.exemple.com/meteo"
    xmlns:c="http://www.exemple.com/commande">
    
    <soap:Body>
        <m:GetTemperature>
            <m:City>Paris</m:City>
        </m:GetTemperature>
    </soap:Body>
    
</soap:Envelope>

Namespaces courants :

Exemple de message SOAP complet (Requête)

<?xml version="1.0"?>
<soap:Envelope 
    xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
    xmlns:bank="http://www.example.com/banking">
    
    <soap:Header>
        <bank:Authentication soap:mustUnderstand="1">
            <bank:Username>john.doe</bank:Username>
            <bank:Password>secret123</bank:Password>
        </bank:Authentication>
    </soap:Header>
    
    <soap:Body>
        <bank:GetAccountBalance>
            <bank:AccountNumber>123456789</bank:AccountNumber>
        </bank:GetAccountBalance>
    </soap:Body>
    
</soap:Envelope>

Exemple de message SOAP complet (Réponse)

<?xml version="1.0"?>
<soap:Envelope 
    xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
    xmlns:bank="http://www.example.com/banking">
    
    <soap:Body>
        <bank:GetAccountBalanceResponse>
            <bank:Balance>15420.50</bank:Balance>
            <bank:Currency>EUR</bank:Currency>
        </bank:GetAccountBalanceResponse>
    </soap:Body>
    
</soap:Envelope>

SOAP Fault (Gestion des erreurs)

<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
    
    <soap:Body>
        <soap:Fault>
            <soap:Code>
                <soap:Value>soap:Sender</soap:Value>
            </soap:Code>
            <soap:Reason>
                <soap:Text xml:lang="fr">Numéro de compte invalide</soap:Text>
            </soap:Reason>
            <soap:Detail>
                <error>Le compte 123456789 n'existe pas</error>
            </soap:Detail>
        </soap:Fault>
    </soap:Body>
    
</soap:Envelope>

Codes d’erreur SOAP 1.2 :

  • soap:Sender : Erreur côté client (message mal formé, données invalides)
  • soap:Receiver : Erreur côté serveur (service indisponible, erreur interne)
  • soap:MustUnderstand : En-tête obligatoire non compris
  • soap:VersionMismatch : Version SOAP incompatible

Styles d’interaction SOAP

1. Style RPC (Remote Procedure Call)

Orienté opération : on appelle une méthode distante avec des paramètres.

<soap:Body>
    <m:CalculerSomme xmlns:m="http://exemple.com/math">
        <m:nombre1>15</m:nombre1>
        <m:nombre2>25</m:nombre2>
    </m:CalculerSomme>
</soap:Body>

Réponse :

<soap:Body>
    <m:CalculerSommeResponse xmlns:m="http://exemple.com/math">
        <m:resultat>40</m:resultat>
    </m:CalculerSommeResponse>
</soap:Body>

Caractéristiques :

  • Nom de l’opération visible dans le Body
  • Paramètres individuels
  • Ressemble à un appel de fonction
  • Couplage fort

2. Style Document

Orienté document : on échange des documents XML complets.

<soap:Body>
    <Commande xmlns="http://exemple.com/commandes">
        <numeroCommande>CMD-2024-001</numeroCommande>
        <client>
            <nom>Dupont</nom>
            <email>dupont@example.com</email>
        </client>
        <articles>
            <article>
                <reference>ART-123</reference>
                <quantite>2</quantite>
            </article>
        </articles>
    </Commande>
</soap:Body>

Réponse :

<soap:Body>
    <ConfirmationCommande xmlns="http://exemple.com/commandes">
        <numeroCommande>CMD-2024-001</numeroCommande>
        <statut>Acceptée</statut>
        <montantTotal>150.00</montantTotal>
    </ConfirmationCommande>
</soap:Body>

Caractéristiques :

  • Document métier complet
  • Structure flexible
  • Validation par schéma XML possible
  • Couplage faible
  • Plus adapté aux échanges B2B

Différences clés

AspectRPCDocument
OrientationOpération/MéthodeDocument/Message
StructureParamètres distinctsDocument structuré
ValidationDifficileVia XML Schema
CouplageFortFaible
Usage typiqueAppels simplesProcessus métier complexes

Quand utiliser chaque style ?

Style RPC :

  • Opérations simples avec peu de paramètres
  • Appels synchrones rapides
  • API de calcul ou de requête simple
  • Exemple : Calculatrice, conversion de devises

Style Document :

  • Échanges complexes de données métier
  • Validation stricte nécessaire
  • Traçabilité et audit
  • Processus asynchrones
  • Exemple : Commandes, factures, dossiers médicaux

Fiabilité et Ordre des messages

WS-ReliableMessaging

Protocole qui garantit la livraison fiable des messages SOAP malgré les défaillances réseau.

Fonctionnalités :

  • Garantie de livraison (au moins une fois, au plus une fois, exactement une fois)
  • Détection et élimination des doublons
  • Ordre de livraison garanti
  • Gestion des accusés de réception

Création d’une séquence

<soap:Envelope xmlns:soap="..." xmlns:wsrm="http://schemas.xmlsoap.org/ws/2005/02/rm">
    <soap:Header>
        <wsrm:CreateSequence>
            <wsrm:AcksTo>
                <wsa:Address>http://client.example.com/callback</wsa:Address>
            </wsrm:AcksTo>
        </wsrm:CreateSequence>
    </soap:Header>
    <soap:Body>
        <!-- Corps vide pour création de séquence -->
    </soap:Body>
</soap:Envelope>

Message dans une séquence

<soap:Envelope xmlns:soap="..." xmlns:wsrm="...">
    <soap:Header>
        <wsrm:Sequence>
            <wsrm:Identifier>uuid:12345-67890-abcdef</wsrm:Identifier>
            <wsrm:MessageNumber>3</wsrm:MessageNumber>
        </wsrm:Sequence>
    </soap:Header>
    <soap:Body>
        <TransferFunds>
            <amount>1000</amount>
            <fromAccount>123</fromAccount>
            <toAccount>456</toAccount>
        </TransferFunds>
    </soap:Body>
</soap:Envelope>

Accusé de réception

<soap:Header>
    <wsrm:SequenceAcknowledgement>
        <wsrm:Identifier>uuid:12345-67890-abcdef</wsrm:Identifier>
        <wsrm:AcknowledgementRange Lower="1" Upper="5"/>
        <wsrm:AcknowledgementRange Lower="7" Upper="10"/>
        <!-- Message 6 manquant, sera retransmis -->
    </wsrm:SequenceAcknowledgement>
</soap:Header>

Garantie de l’ordre

L’ordre de traitement est garanti par :

  1. Numérotation séquentielle des messages
  2. Le récepteur attend les messages manquants avant de traiter les suivants
  3. Retransmission automatique des messages perdus

Exemple de scénario :

  • Messages envoyés : 1, 2, 3, 4, 5
  • Messages reçus : 1, 2, 4, 5 (3 perdu)
  • Le récepteur traite 1 et 2, puis attend 3
  • Une fois 3 reçu (retransmis), il traite 3, 4, 5 dans l’ordre

Cas d’usage

Utiliser WS-ReliableMessaging quand :

  • Les messages ne doivent pas être perdus (transactions financières)
  • L’ordre est critique (étapes d’un workflow)
  • Le réseau est instable
  • Communication asynchrone sur longue période

Ne pas utiliser si :

  • Communication synchrone simple suffit
  • Overhead de performance inacceptable
  • Les messages sont idempotents et l’ordre n’importe pas

Analyse d’un message SOAP complexe

Exemple complet avec authentification, transaction et gestion d’erreurs potentielles :

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope 
    xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
    xmlns:wsa="http://www.w3.org/2005/08/addressing"
    xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
    xmlns:bank="http://www.example.com/banking/v2">
    
    <soap:Header>
        <!-- Authentification -->
        <wsse:Security soap:mustUnderstand="1">
            <wsse:UsernameToken>
                <wsse:Username>john.doe@example.com</wsse:Username>
                <wsse:Password Type="...#PasswordDigest">Hy6...==</wsse:Password>
                <wsse:Nonce>MTIzNDU2Nzg5MA==</wsse:Nonce>
                <wsse:Created>2024-01-15T10:30:00Z</wsse:Created>
            </wsse:UsernameToken>
        </wsse:Security>
        
        <!-- Adressage -->
        <wsa:To>http://bank.example.com/services/transfer</wsa:To>
        <wsa:Action>http://www.example.com/banking/TransferFunds</wsa:Action>
        <wsa:MessageID>uuid:abcd-1234-efgh-5678</wsa:MessageID>
        <wsa:ReplyTo>
            <wsa:Address>http://client.example.com/callback</wsa:Address>
        </wsa:ReplyTo>
        
        <!-- Transaction -->
        <bank:TransactionContext soap:mustUnderstand="1">
            <bank:TransactionID>TXN-2024-001-XYZ</bank:TransactionID>
            <bank:Timeout>PT30S</bank:Timeout>
        </bank:TransactionContext>
        
        <!-- Séquence fiable -->
        <wsrm:Sequence xmlns:wsrm="http://schemas.xmlsoap.org/ws/2005/02/rm">
            <wsrm:Identifier>uuid:seq-9876-5432</wsrm:Identifier>
            <wsrm:MessageNumber>42</wsrm:MessageNumber>
        </wsrm:Sequence>
    </soap:Header>
    
    <soap:Body>
        <bank:TransferFunds>
            <bank:FromAccount>
                <bank:AccountNumber>FR76 1234 5678 9012 3456 7890 123</bank:AccountNumber>
                <bank:AccountType>CHECKING</bank:AccountType>
            </bank:FromAccount>
            <bank:ToAccount>
                <bank:AccountNumber>FR76 0987 6543 2109 8765 4321 098</bank:AccountNumber>
                <bank:BankCode>BNPAFRPP</bank:BankCode>
            </bank:ToAccount>
            <bank:Amount currency="EUR">2500.00</bank:Amount>
            <bank:Description>Paiement facture #INV-2024-156</bank:Description>
            <bank:ExecutionDate>2024-01-16</bank:ExecutionDate>
        </bank:TransferFunds>
    </soap:Body>
    
</soap:Envelope>

Analyse étape par étape :

  1. Envelope et namespaces

    • SOAP 1.2 (soap)
    • WS-Addressing (wsa)
    • WS-Security (wsse)
    • Namespace métier personnalisé (bank)

  2. Header - Sécurité (mustUnderstand=“1”)

    • Authentification par username/password
    • Password hashé (Digest)
    • Nonce pour éviter les attaques par rejeu
    • Timestamp de création

  3. Header - Adressage

    • Destination du message (To)
    • Action à effectuer
    • ID unique du message
    • Adresse de réponse asynchrone

  4. Header - Contexte transactionnel (mustUnderstand=“1”)

    • ID de transaction pour traçabilité
    • Timeout de 30 secondes

  5. Header - Messaging fiable

    • Séquence identifiée
    • Numéro de message dans la séquence

  6. Body - Données métier

    • Opération : TransferFunds
    • Compte source avec type
    • Compte destination avec code banque
    • Montant avec devise
    • Métadonnées : description, date d’exécution

Points d’attention :

  • Deux en-têtes avec mustUnderstand=“1” : le service doit les supporter
  • Communication asynchrone (ReplyTo différent de l’émetteur)
  • Sécurisé et fiable (Security + ReliableMessaging)
  • Traçable (MessageID, TransactionID, MessageNumber)

Vue Graphique

Liens retour