Tutoriel sur les services Web SOAP : Qu’est-ce que le protocole SOAP ?

Qu'est-ce que le SAVON ?

SOAP est un protocole basé sur XML permettant d'accéder aux services web via HTTP. Il possède des spécifications communes à toutes les applications.

SOAP, ou Simple Object Access Protocol, a été abrégé plus tard en SOAP v1.2. SOAP est un protocole, ou en d'autres termes, une définition de la manière dont les services web communiquent entre eux ou avec les applications clientes qui les invoquent.

SOAP a été développé comme langage intermédiaire afin que les applications construites sur différents langages de programmation puissent communiquer facilement entre elles et éviter un effort de développement extrême.

Présentation du savon

Dans le monde actuel, il existe un grand nombre d'applications construites à l'aide de différents langages de programmation. Par exemple, il peut exister une application web conçue en Java, un autre en .Net, et un autre en PHP.

L'échange de données entre applications est crucial dans le monde interconnecté d'aujourd'hui. Mais l’échange de données entre ces applications hétérogènes serait complexe. Il en sera de même pour la complexité du code nécessaire à cet échange de données.

L'une des méthodes utilisées pour lutter contre cette complexité consiste à utiliser XML (Extensible Markup Language) comme langage intermédiaire pour l'échange de données entre applications.

Chaque langage de programmation peut comprendre le langage de balisage XML. Par conséquent, XML a été utilisé comme support sous-jacent pour l’échange de données.

Mais il n'existe pas de spécifications standardisées concernant l'utilisation du XML pour l'échange de données dans tous les langages de programmation. C'est là qu'intervient le logiciel SOAP.

SOAP a été conçu pour fonctionner avec XML sur HTTP et possède une sorte de spécification qui peut être utilisée dans toutes les applications. Nous examinerons plus en détail le protocole SOAP dans les chapitres suivants.

Avantages du savon

SOAP est le protocole utilisé pour l'échange de données entre applications. Vous trouverez ci-dessous quelques-unes des raisons pour lesquelles SOAP est utilisé.

• Quand développerping Pour les services Web basés sur SOAP, il est nécessaire de disposer d'un langage permettant aux services Web de communiquer avec les applications clientes. SOAP constitue le support idéal, développé à cet effet. Ce protocole est également recommandé par le W3C, l'organisme qui régit les standards du Web.
• SOAP est un protocole léger utilisé pour l’échange de données entre applications. Notez le mot-clé 'lumière« Étant donné que la programmation SOAP est basée sur le langage XML, qui est lui-même un langage d'échange de données léger, le protocole SOAP appartient également à la même catégorie. »
• SOAP est conçu pour être indépendant de la plateforme et du système d'exploitation. Le protocole SOAP peut donc fonctionner avec n'importe quelle application basée sur n'importe quel langage de programmation, aussi bien sur la plateforme que sur le système d'exploitation. Windows et Linux les plates-formes.
• Il fonctionne avec le protocole HTTP – SOAP utilise le protocole HTTP, qui est le protocole par défaut de toutes les applications web. Par conséquent, aucune personnalisation n'est nécessaire pour que les services web construits sur le protocole SOAP fonctionnent sur le Web.

Blocs de construction SOAP

La spécification SOAP définit ce qu'on appelle un «Message SOAP« », c’est-à-dire ce qui est envoyé au service web et à l’application cliente.

Le diagramme ci-dessous de l'architecture SOAP montre les différents éléments constitutifs d'un message SOAP.

Le message SOAP n'est rien d'autre qu'un simple document XML contenant les composants ci-dessous.

• An Enveloppe Élément identifiant le document XML comme un message SOAP – Il s'agit de la partie conteneur du message SOAP, servant à encapsuler tous les détails de ce dernier. C'est l'élément racine du message SOAP.
• A En-tête L'élément d'en-tête contient des informations telles que les identifiants d'authentification utilisés par l'application appelante. Il peut également contenir la définition de types complexes utilisables dans le message SOAP. Par défaut, un message SOAP peut contenir des paramètres de types simples (chaînes de caractères, nombres, etc.) ou de types d'objets complexes.

Un exemple simple de service SOAP pour un type complexe est présenté ci-dessous. Supposons que nous souhaitions envoyer un type de données structurées combinant un « Nom du tutoriel » et un « Tutoriel ». DescriptSi « ion », nous définirions le type complexe comme indiqué ci-dessous. Le type complexe est défini par l'élément tag Tous les éléments requis de la structure, ainsi que leurs types de données respectifs, sont ensuite définis dans la collection de types complexes.

<xsd:complexType>
   <xsd:sequence>
      <xsd:element name="Tutorial Name" type="string"/>
      <xsd:element name="Tutorial Description" type="string"/>
   </xsd:sequence>
</xsd:complexType>

A Body Élément contenant les informations d'appel et de réponse – Cet élément contient les données à échanger entre le service web et l'application appelante. Voici un exemple de corps de requête SOAP pour un service web SOAP, fonctionnant avec le type complexe défini dans l'en-tête. Voici la réponse pour le nom et le tutoriel. Description qui est envoyé à l’application appelante qui appelle ce service Web.

<soap:Body>
   <GetTutorialInfo>
      <TutorialName>Web Services</TutorialName>
      <TutorialDescription>All about web services</TutorialDescription>
   </GetTutorialInfo>
</soap:Body>

Structure des messages SOAP

Une chose à noter est que les messages SOAP sont normalement générés automatiquement par le service Web lors de son appel.

Chaque fois qu'une application client appelle une méthode dans le service Web, le service Web génère automatiquement un message SOAP contenant les détails nécessaires sur les données qui seront envoyées du service Web à l'application client.

Comme indiqué dans le sujet précédent de ce tutoriel SOAP, un message SOAP simple comporte les éléments suivants :

• L'élément Enveloppe
• L'élément d'en-tête, et
• L'élément corps
• L'élément Fault (facultatif)

Prenons l'exemple ci-dessous d'un message SOAP simple et voyons ce que chaque élément fait réellement.

1. Comme le montre le message SOAP ci-dessus, la première partie du message SOAP est l'élément d'enveloppe qui est utilisé pour encapsuler l'intégralité du message SOAP.
2. L'élément suivant est le corps SOAP qui contient les détails du message réel.
3. Notre message contient un service web qui porte le nom de «Guru99WebService".
4. L'événement Guru« 99Webservice » accepte un paramètre de type « int » et porte le nom de TutorialID.

Désormais, le message SOAP ci-dessus sera transmis entre le service Web et l'application client.

Vous pouvez constater l'utilité des informations ci-dessus pour l'application cliente. Le message SOAP indique à l'application cliente le nom du service Web, les paramètres attendus et le type de chaque paramètre accepté par le service Web.

Élément d'enveloppe SOAP

Le premier élément de base est l’enveloppe SOAP.

L'enveloppe SOAP est utilisée pour encapsuler tous les détails nécessaires des messages SOAP, qui sont échangés entre le service Web et l'application client.

L'élément d'enveloppe SOAP est utilisé pour indiquer le début et la fin d'un message SOAP. Cela permet à l'application client qui appelle le service Web de savoir quand le message SOAP se termine.

Les points suivants peuvent être notés sur l’élément enveloppe SOAP.

• Chaque message SOAP doit comporter un élément Envelope racine. La présence d'un élément Envelope est absolument obligatoire pour tout message SOAP.
• Chaque élément d'enveloppe doit avoir au moins un élément de corps de savon.
• Si un élément Envelope contient un élément header, il ne doit pas en contenir plus d’un et il doit apparaître comme le premier enfant de l’Envelope, avant l’élément body.
• L'enveloppe change lorsque les versions de SOAP changent.
• Un processeur SOAP compatible v1.1 génère une erreur lors de la réception d'un message contenant l'espace de noms d'enveloppe v1.2.
• Un processeur SOAP compatible v1.2 génère une erreur de non-concordance de version s'il reçoit un message qui n'inclut pas l'espace de noms d'enveloppe v1.2.

Vous trouverez ci-dessous un exemple d'API SOAP de la version 1.2 de l'élément d'enveloppe SOAP.

<?xml version="1.0"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope" SOAP-ENV:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
   <soap:Body>
      <Guru99WebService xmlns="http://tempuri.org/">
         <TutorialID>int</TutorialID>
      </Guru99WebService>
   </soap:Body>
</SOAP-ENV:Envelope>

Le message de défaut

Lorsqu'une requête est adressée à un service web SOAP, la réponse peut prendre deux formes : une réponse positive ou une réponse d'erreur. En cas de succès, la réponse du serveur est toujours un message SOAP. En cas d'erreur SOAP, celle-ci est renvoyée sous la forme d'une erreur HTTP 500.

Le message d'erreur SOAP comprend les éléments suivants.

1. <faultCode> – Ce code désigne le code d'erreur. Le code d'erreur peut prendre l'une des valeurs suivantes :
   1. SOAP-ENV:VersionMismatch – C'est lorsqu'un espace de noms non valide pour l'élément SOAP Envelope est rencontré.
   2. SOAP-ENV:MustUnderstand – Un élément enfant immédiat de l'élément Header, avec l'attribut mustUnderstand défini sur « 1 », n'a pas été compris.
   3. SOAP-ENV:Client – ​​Le message était mal formé ou contenait des informations incorrectes.
   4. SOAP-ENV:Serveur – Il y a eu un problème avec le serveur, le message n'a donc pas pu continuer.
2. – Il s’agit du message texte qui donne une description détaillée de l’erreur.
3. (Facultatif) – Il s'agit d'une chaîne de texte qui indique qui est à l'origine du défaut.
4. (Facultatif) – Il s'agit de l'élément destiné aux messages d'erreur spécifiques à l'application. Ainsi, l'application peut avoir un message d'erreur spécifique pour différents scénarios de logique métier.

Exemple de message d'erreur

Un exemple de message d'erreur est fourni ci-dessous. Cette erreur se produit lorsque le client tente d'utiliser la méthode `TutorialID` de la classe `GetTutorial`. Le message d'erreur ci-dessous s'affiche si la méthode n'existe pas dans la classe définie.

<?xml version='1.0' encoding='UTF-8'?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema">
   <SOAP-ENV:Body>
      <SOAP-ENV:Fault>
      <faultcode xsi:type="xsd:string">SOAP-ENV:Client</faultcode>
      <faultstring xsi:type="xsd:string">
         Failed to locate method (GetTutorialID) in class (GetTutorial)
      </faultstring>
      </SOAP-ENV:Fault>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Sortie :

Lorsque vous exécuterez le code ci-dessus, il affichera une erreur du type « Impossible de localiser la méthode (GetTutorialID) dans la classe (GetTutorial) ».

Modèle de communication SOAP

Toutes les communications par SOAP se font via le protocole HTTP. Avant SOAP, beaucoup de services Web utilisé le style standard RPC (Remote Procedure Call) pour la communication. C’était le type de communication le plus simple, mais il présentait de nombreuses limites.

Dans ce tutoriel sur l'API SOAP, examinons le schéma ci-dessous pour comprendre le fonctionnement de cette communication. Supposons, dans cet exemple, que le serveur héberge un service web proposant deux méthodes :

• ObtenirEmployé – Cela permettrait d'obtenir toutes les informations concernant les employés.
• DéfinirEmployé – Cela permettrait de définir en conséquence la valeur des informations telles que le service, le salaire, etc. d'un employé.

Dans la communication normale de style RPC, le client appellerait simplement les méthodes dans sa requête et enverrait les paramètres requis au serveur, et le serveur enverrait ensuite la réponse souhaitée.

Le modèle de communication décrit ci-dessus présente les limitations importantes suivantes :

1. Pas indépendant de la langue – Le serveur hébergeant les méthodes serait écrit dans un langage de programmation particulier, et normalement les appels au serveur seraient effectués uniquement dans ce langage de programmation.
2. Pas le protocole standard – Lorsqu'un appel est effectué vers la procédure distante, l'appel n'est pas effectué via le protocole standard. C'était un problème puisque la plupart des communications sur le Web devaient être effectuées via le protocole HTTP.
3. Les pare-feu – Étant donné que les appels RPC ne transitent pas par le protocole normal, des ports distincts doivent être ouverts sur le serveur pour permettre au client de communiquer avec le serveur. Normalement, tous les pare-feu bloquent ce type de trafic, et de nombreuses configurations étaient généralement nécessaires pour garantir que ce type de communication entre le client et le serveur fonctionnerait.

Pour surmonter toutes les limitations citées ci-dessus, SOAP utiliserait alors le modèle de communication suivant.

1. Le client formatait les informations relatives à l'appel de procédure et à ses arguments dans un message SOAP et l'envoyait au serveur dans le cadre d'une requête HTTP. Ce processus d'encapsulation des données dans un message SOAP était appelé Triage.
2. Le serveur déballe alors le message envoyé par le client, examine la requête de ce dernier, puis renvoie la réponse appropriée au client sous forme de message SOAP. Cette pratique de déballage est appelée « unwrapped ».ping une requête envoyée par le client est appelée Démarshalling.

Exemple pratique de savon

Maintenant dans ce SoapUI Dans ce tutoriel, prenons un exemple pratique de SOAP. L'une des meilleures façons de comprendre la génération des messages SOAP est sans doute d'observer un service web en fonctionnement.

Ce sujet examinera l'utilisation du MicrosoftFramework .Net pour créer un service Web ASMX. Ce type de service Web prend en charge à la fois SOAP version 1.1 et version 1.2.

Les services Web ASMX génèrent automatiquement le Langage de définition de service Web (WSDL) document. Ce document WSDL est requis par l'application cliente appelante afin que l'application sache ce que le service Web est capable de faire.

Dans notre exemple, nous allons créer un service web simple qui renverra une chaîne de caractères à l'application appelante. Ce service web sera hébergé sur un serveur web. Asp.Net application Web. Nous invoquerons ensuite le service Web et verrons le résultat renvoyé par le service Web.

Visual Studio affichera également le message SOAP échangé entre le service web et l'application appelante. La première étape, préalable à la configuration de notre application de service web, est décrite ci-dessous. Veuillez vous assurer que Visual Studio 2013 est installé sur votre système pour cet exemple.

Étape 1) La première étape consiste à créer une application Web ASP.Net vide. Depuis Visual Studio 2013, cliquez sur l'option de menu Fichier->Nouveau projet.

Une fois que vous avez cliqué sur l'option Nouveau projet, Visual Studio vous proposera alors une autre boîte de dialogue pour choisir le type de projet et donner les détails nécessaires du projet. Ceci est expliqué à l’étape suivante.

Étape 2) Dans cette étape,

1. Assurez-vous de choisir d'abord le C# Modèle web d'application web ASP.NET. Ce type de projet est nécessaire pour créer un projet de services SOAP. En choisissant cette option, Visual Studio effectuera les étapes nécessaires pour ajouter les fichiers requis par toute application web.
2. Donnez un nom à votre projet, par exemple webservice.asmx. Indiquez ensuite l'emplacement où seront stockés les fichiers du projet.

Une fois l'opération terminée, vous verrez le fichier projet créé dans l'explorateur de solutions de Visual Studio 2013.

Étape 3) Dans cette étape, nous allons ajouter un fichier de service Web à notre projet.

1. Tout d'abord, cliquez avec le bouton droit sur le fichier de projet comme indiqué ci-dessous.

2. Après avoir cliqué avec le bouton droit sur le fichier de projet, vous pouvez sélectionner l'option « Ajouter > Service Web (ASMX) » pour ajouter un fichier de service Web. Nommez ce fichier « Service Tutoriel ».

Étape 4) Ajoutez le code suivant à votre fichier asmx de service de didacticiel.

Code Explication:

1. Cette ligne de code fournit un nom pour votre fichier de service Web. Il s'agit d'une étape importante car elle permet à l'application client d'appeler le service Web via le nom du service Web.
2. Normalement, un fichier de classe est utilisé pour encapsuler les fonctionnalités d'un service Web. Ainsi, le fichier de classe aura la définition de toutes les méthodes Web qui fourniront certaines fonctionnalités à l'application client.
3. Ici, [WebMethod] est un attribut qui décrit une fonction. L'étape suivante crée une fonction appelée «GuruL'ajout de l'attribut [WebMethod] à la méthode 99WebService permet à une application cliente de l'appeler. Sans cet attribut, la méthode reste inaccessible.
4. Nous définissons ici une fonction appelée 'GuruLa fonction « 99WebService » renverra une chaîne de caractères à l'application cliente appelante. Il s'agit d'un service web accessible par toute application cliente.
5. Nous utilisons l'instruction return pour renvoyer la chaîne « Ceci est un Guru99 Service Web » à l'application cliente.

Si le code est exécuté avec succès, la sortie suivante s'affichera lorsque vous exécutez votre code dans le navigateur.

Sortie :

• Le résultat montre clairement que le nom de notre service web est «Guru« 99 Service Web », qui est le résultat du choix d'un nom pour notre service Web.
• Nous pouvons également constater que nous pouvons appeler le service web. Si nous cliquons sur le bouton « Appeler », nous obtiendrons la réponse ci-dessous dans le navigateur web.

Résultat ci-dessus :

• Cela montre clairement qu'en invoquant la méthode web, la chaîne « Ceci est un Guru« 99 Service Web » est renvoyé.
• Visual Studio vous permet également d'afficher la demande de message SOAP et la réponse générée lorsque le service Web ci-dessus est appelé.

La requête SOAP générée lorsque le service Web est appelé est présentée ci-dessous.

Code Explication:

1. La première partie d'un message SOAP est l'élément d'enveloppe, abordé dans les chapitres précédents. Il s'agit de l'élément d'encapsulation présent dans chaque message SOAP.
2. Le corps SOAP est l'élément suivant et contient les détails réels du message SOAP.
3. La troisième partie est l'élément qui spécifie que nous voulons appeler le service appelé «Guru99WebService'.

<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <soap:Body>
      <Guru99WebServiceResponse xmlns="http://tempuri.org/">
         <Guru99WebServiceResult>string</Guru99WebServiceResult>
      </Guru99WebServiceResponse>
   </soap:Body>
</soap:Envelope>

Code Explication:

1. La première partie d'un message SOAP est l'élément d'enveloppe, abordé dans les chapitres précédents. Il s'agit de l'élément d'encapsulation présent dans chaque message SOAP.
2. Le corps SOAP est l'élément suivant et contient les détails réels du message SOAP.
3. L'élément intéressant que vous allez découvrir est l'attribut « string ». Celui-ci indique à l'application cliente que le service web appelé renvoie un objet de type chaîne de caractères. C'est très utile, car sans cela, l'application cliente ne saurait pas ce que le service web renvoie.

FAQ