La première partie du sujet ‘Comprendre SOAP’ nous a permis d’identifier les principes, le fonctionnement et les limites de SOAP. C’est donc sur cet aspect « théorique » que nous nous sommes arrêtés.

Dans cet article, je vais aborder la partie technique du protocole. Pour cela, nous allons analyser le modèle de traitement SOAP, le format du message, la procédure de l’appel à distance, et enfin l’enveloppe SOAP.

Modèle de traitement SOAP

Un message SOAP peut être véhiculé par plusieurs protocoles de transport comme illustrés dans la figure ci-dessous.

Le modèle de traitement SOAP décrit un modèle de traitement distribué, les participants, les nœuds SOAP et la manière dont un récepteur traite un message SOAP. Les nœuds SOAP suivants sont définis :

Émetteur SOAP (SOAP sender)

Un émetteur SOAP est un nœud qui envoie le message SOAP.

Récepteur SOAP (SOAP receiver)

Un récepteur SOAP est un nœud qui reçoit le message SOAP.

Parcours du message SOAP (SOAP message path)

Afin d’obtenir le nœud de destination, le message SOAP doit progresser à travers les différents nœuds. Le parcours que suit un message SOAP vers le récepteur est appelé parcours du message SOAP (SOAP message path).

Initiateur de l’émetteur SOAP (Initial SOAP sender)

Le nœud qui crée un message SOAP au début du parcours est appelé initiateur émetteur SOAP (Initial SOAP sender) .

Intermédiaire SOAP (SOAP intermediary)

Un intermédiaire SOAP est à la fois un récepteur SOAP et un émetteur SOAP et ciblé à partir d’un message SOAP. Il traite les blocs d’en-tête SOAP ciblés et agit en amont d’un message SOAP vers un récepteur SOAP final.

Récepteur SOAP final (Ultimate SOAP receiver)

Le récepteur SOAP est la destination finale d’un message SOAP. Il est responsable du traitement du contenu du corps SOAP et de tous les blocs d’en-tête SOAP ciblés. Dans certains cas, un message SOAP peut ne pas parvenir au récepteur SOAP final, par exemple en raison d’un problème sur un intermédiaire SOAP. Le récepteur ne peut pas aussi être un intermédiaire SOAP pour le même message SOAP.

Format du message

La partie principale de ce message a un type MIME text/xml et contient l’enveloppe SOAP. Cette enveloppe est un document XML. L’enveloppe contient un entête (facultatif) et le corps (obligatoire).
La partie du corps de l’enveloppe est toujours prévue pour le destinataire final du message, tandis que les blocs d’entête peuvent cibler les intermédiaires qui effectuent le traitement de l’acheminement du message. Les pièces jointes, binaires ou autres, peuvent être ajoutées à l’enveloppe.

Les en-têtes envoyés en complément du contenu principal du message SOAP, sont utiles dans l’ajout d’informations au message qui n’affectent pas le traitement du corps du message. Les en-têtes, par exemple, peuvent être utilisés pour fournir des signatures numériques pour une demande contenue dans le corps. Dans ce cas, un serveur indépendant d’authentification ou d’autorisation pourrait extraire la donnée de l’entête pour valider la signature. Une fois validé, le reste de l’enveloppe pourrait être répercuté sur le serveur SOAP, ce qui permettrait de traiter le corps du message. Un examen plus poussé de l’enveloppe SOAP aidera à clarifier la mise en place et le but de l’en-tête SOAP et les éléments du corps.

Appel de la méthode distante SOAP

Les messages SOAP sont des transmissions fondamentalement à sens unique d’un émetteur à un récepteur, mais ils sont souvent combinés pour mettre en œuvre des mécanismes de demande/réponse. Pour faire du RPC en utilisant SOAP, quelques conventions doivent être respectées. Tout d’abord, la demande des messages de réponse doit être codée comme des structures. Pour chaque paramètre d’entrée d’une opération, il doit y avoir un élément avec le même nom que le paramètre, et pour chaque paramètre de sortie, il doit y avoir un élément avec un nom correspondant. La demande invoque la méthode additionCalcul. Remarquez que la réponse définit une opération additionCalculResponse. Une convention commune à des appels SOAP pour ajouter la réponse à la fin d’une demande, afin de créer une structure de réponse.
Cette structure de sortie contient un élément appelé result, qui renvoie le résultat de l’appel de la méthode.

Bloc d’entête, de corps

Bloc <SOAP-ENV:Header>

SOAP définit des attributs optionnels applicables sur les éléments fils directs du bloc Header. Ces attributs sont:

• actor : cet attribut identifie le destinataire de l’élément fils. En effet, comme on l’a vu précédemment, un message SOAP peut traverser plusieurs composants avant d’atteindre le destinataire final du message. Il peut être nécessaire d’adresser des informations aux composants intermédiaires qui composent le chemin vers le destinataire final. C’est par l’intermédiaire de cet attribut que cela est rendu possible, en lui donnant comme valeur une URL qui correspond à ou aux destinataires de l’élément.
  Note : En l’absence de cet attribut, l’élément fils est à destination du destinataire final du message SOAP.
• mustUnderstand : cet attribut indique si le destinataire de l’élément doit absolument comprendre l’élément ou non. Si cet attribut est à 1, alors le destinataire doit absolument comprendre l’élément. Si ça n’est pas le cas, un message d’erreur (par ex., contenant un bloc Fault) est retourné.
  Note : Si cet attribut est à 0, l’élément peut être ignoré. C’est le comportement par défaut quand l’attribut n’est pas spécifié.
• encodingStyle : la signification de cet attribut est la même que pour le bloc Envelope. Sa portée reste cependant limitée à l’élément fils.

Voici un exemple du bloc Header :

Ici, on voit que l’élément Utilisateur est à destination du composant User et qu’il contient un nom d’utilisateur (Yohann).
L’élément suivant, Session, est à destination du destinataire final du message SOAP. Il indique un numéro de session (ABC123), et doit absolument être compris par le destinataire pour pouvoir traiter le message.

Bloc <SOAP-ENV:Body>

Ce bloc contient le corps du message, sa signification est spécifique à l’application.

Voici un exemple du bloc :

Un prochain article nous permettra de mettre en application ce que nous venons d’étudier sur le protocole SOAP. Ainsi, nous écrirons un simple service Web permettant d’additionner / soustraire deux entiers.

N’hésitez pas à me partager vos remarques sur cet article.