Didacticiel sur les services Web SOAP : Qu'est-ce que le protocole SOAP ? EXEMPLE

Qu'est-ce que le SAVON ?

SOAP est un protocole basé sur XML pour accéder aux services Web via HTTP. Il comporte des spécifications qui pourraient être utilisées dans toutes les applications.

SOAP est connu sous le nom de Simple Object Access Protocol, mais plus tard, il a simplement été abrégé 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 communiquent 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 d’aujourd’hui, il existe un grand nombre d’applications construites sur différents langages de programmation. Par exemple, il pourrait y avoir 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 standard sur l’utilisation de XML dans tous les langages de programmation pour l’échange de données. 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é.

• Lors du développement de services Web basés sur SOAP, vous devez disposer d'un langage pouvant être utilisé par les services Web pour communiquer avec les applications clientes. SOAP est le support idéal qui a été développé pour atteindre cet objectif. Ce protocole est également recommandé par le consortium W3C qui est l'organisme directeur de tous 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 léger d'échange de données, SOAP est donc un protocole qui entre également dans la même catégorie.
• SOAP est conçu pour être indépendant de la plate-forme et est également conçu pour être indépendant du système d'exploitation. Ainsi, le protocole SOAP peut fonctionner avec n'importe quelle application basée sur un langage de programmation, à la fois sur Windows et Linux
• Il fonctionne sur le protocole HTTP – SOAP fonctionne sur le protocole HTTP, qui est le protocole par défaut utilisé par toutes les applications Web. Par conséquent, aucune sorte de personnalisation n’est requise pour exécuter les services Web basés sur le protocole SOAP afin de fonctionner sur le World Wide Web.

Blocs de construction SOAP

La spécification SOAP définit ce qu'on appelle un «Message SOAP» qui est ce qui est envoyé au service Web et à l'application client.

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.

• Un élément Enveloppe qui identifie le document XML en tant que message SOAP – Il s'agit de la partie contenant du message SOAP et est utilisé pour encapsuler tous les détails du message SOAP. Il s'agit de l'élément racine du message SOAP.
• Un élément d'en-tête qui contient des informations d'en-tête – L'élément d'en-tête peut contenir des informations telles que des informations d'authentification qui peuvent être utilisées par l'application appelante. Il peut également contenir la définition de types complexes qui pourraient être utilisés dans le message SOAP. Par défaut, le message SOAP peut contenir des paramètres qui peuvent être de types simples tels que des chaînes et des nombres, mais peuvent également être un type d'objet complexe.

Un exemple simple de service SOAP d'un type complexe est présenté ci-dessous.

Supposons que nous souhaitions envoyer un type de données structuré qui combine un « Nom du didacticiel » et un « Nom du didacticiel ». Description”, alors nous définirions le type complexe comme indiqué ci-dessous.

Le type complexe est défini par la balise element . 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>

• Un élément Body qui contient des informations d'appel et de réponse – Cet élément contient les données réelles qui doivent être envoyées entre le service Web et l'application appelante. Vous trouverez ci-dessous un exemple de service Web SOAP du corps SOAP qui fonctionne réellement sur le type complexe défini dans la section d'en-tête. Voici la réponse du nom du didacticiel et du didacticiel 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 la rubrique précédente de ce didacticiel SOAP, un simple message SOAP 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)

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

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. Le « Guru99Webservice » 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 voir à quel point les informations ci-dessus sont utiles à l'application client. Le message SOAP indique à l'application client quel est le nom du service Web, ainsi que les paramètres qu'elle attend et quel est le type de chaque paramètre pris 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 avoir un élément enveloppe racine. Il est absolument obligatoire que le message SOAP comporte un élément enveloppe.
• 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 renvoyée peut prendre deux formes : une réponse réussie ou une réponse d'erreur. Lorsqu'un succès est généré, la réponse du serveur sera toujours un message SOAP. Mais si des erreurs SOAP sont générées, elles sont renvoyées sous forme d'erreurs « HTTP 2 ».

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

1. – C'est le code qui désigne le code de l'erreur. Le code d'erreur peut être l'une des valeurs ci-dessous
   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 de défaut est donné ci-dessous. L'erreur est générée si le scénario dans lequel le client tente d'utiliser une méthode appelée TutorialID dans la classe GetTutorial.

Le message d'erreur ci-dessous est généré dans le cas où 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écutez le code ci-dessus, une erreur du type « Échec de la localisation de la méthode (GetTutorialID) dans la classe (GetTutorial) » s'affiche.

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.

Maintenant, dans ce didacticiel de l'API SOAP, examinons le diagramme ci-dessous pour voir comment fonctionne cette communication. Dans cet exemple, supposons que le serveur héberge un service Web qui fournit 2 méthodes comme

• ObtenirEmployé – Cela permettrait d'obtenir tous les détails de l'employé
• DéfinirEmployé – Cela définirait la valeur des détails tels que le service des employés, le salaire, etc.

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 ci-dessus présente les sérieuses limitations ci-dessous

1. Pas indépendant de la langue – Le serveur hébergeant les méthodes serait dans un langage de programmation particulier et normalement les appels au serveur se feraient 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 ci-dessous

1. Le client formate les informations concernant l'appel de procédure et les éventuels arguments dans un message SOAP et les envoie au serveur dans le cadre d'une requête HTTP. Ce processus d'encapsulation des données dans un message SOAP était connu sous le nom de Triage.
2. Le serveur déballerait ensuite le message envoyé par le client, verrait ce que le client a demandé, puis renverrait la réponse appropriée au client sous forme de message SOAP. La pratique consistant à déballer une demande envoyée par le client est connue sous le nom de Démarchage.

Exemple pratique de savon

Maintenant, dans ce didacticiel SoapUI, voyons un exemple pratique de SOAP,

L'un des meilleurs moyens de voir comment les messages SOAP sont générés est probablement de voir un service Web en action.

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 servira à renvoyer une chaîne à l'application qui appelle le service web.

Ce service Web sera hébergé dans un Asp.Net application Web. Nous invoquerons ensuite le service Web et verrons le résultat renvoyé par le service Web.

Visual Studio nous montrera également quel est le message SOAP transmis entre le service Web et l'application appelante.

La première condition préalable pour configurer notre application de service Web qui peut être effectuée en suivant les étapes 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. Le projet doit être de ce type afin de créer un projet de services SOAP. En choisissant cette option, Visual Studio effectuera alors les étapes nécessaires pour ajouter les fichiers requis par toute application Web.
2. Donnez un nom à votre projet qui dans notre cas a été donné comme webservice.asmx. Assurez-vous ensuite de donner un emplacement où les fichiers du projet seront stockés.

Une fois cela fait, vous verrez le fichier projet créé dans votre explorateur de solutions dans Visual Studio 2013.

Étape 3) Dans cette étape,

Nous allons ajouter un fichier de service Web à notre projet

1. Faites d’abord un clic droit sur le fichier du projet comme indiqué ci-dessous

2. Une fois que vous avez fait un clic droit sur le fichier du projet, vous avez la possibilité de choisir l'option « Ajouter->Service Web (ASMX) pour ajouter un fichier de service Web. Fournissez simplement un nom de service de didacticiel pour le fichier de nom du service Web.

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

Explication du code :

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 connu comme un attribut qui décrit une fonction. L'étape suivante crée une fonction appelée « Guru99WebService », mais avec l'inclusion de cette étape d'ajout d'un attribut [WebMethod] garantit que cette méthode peut être invoquée par une application client. Si cet attribut n'est pas en place, la méthode ne pourra jamais être appelée par une application client.
4. Nous définissons ici une fonction appelée 'Guru99WebService' qui sera utilisée pour renvoyer une chaîne à l'application cliente appelante. Cette fonction est un service web qui peut être appelé par n'importe quelle application client.
5. Nous utilisons l'instruction return pour renvoyer la chaîne « Ceci est un service Web Guru99 » à l'application client.

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 « Guru99 Web Service », ce qui est le résultat du nom donné à notre service Web.
• Nous pouvons également voir que nous pouvons invoquer le service Web. Si nous cliquons sur le bouton Invoquer, nous obtiendrons la réponse ci-dessous dans le navigateur Web.

La sortie ci-dessus,

• Cela montre clairement qu'en invoquant la méthode Web, la chaîne « Ceci est un service Web Guru99 » est renvoyée.
• 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.

Explication du code :

1. La première partie du message SOAP est l'élément enveloppe qui a été 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>

Explication du code :

1. La première partie du message SOAP est l'élément enveloppe qui a été 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 partie intéressante que vous verrez maintenant est l'attribut 'string'. Cela indique à l'application client que le service Web appelé renvoie un objet du type chaîne. Ceci est très utile car si l'application cliente ne saurait autrement ce que renvoie le service Web.

Résumé

• SOAP est un protocole utilisé pour échanger des données entre des applications construites sur des bases différentes. langages de programmation.
• SOAP est basé sur la spécification XML et fonctionne avec le protocole HTTP. Cela le rend parfait pour une utilisation dans les applications Web.
• Les blocs de construction SOAP consistent en un message SOAP. Chaque message SOAP se compose d'un élément d'enveloppe, d'un en-tête et d'un élément de corps.
• L'élément enveloppe est l'élément obligatoire du message SOAP et est utilisé pour encapsuler toutes les données du message SOAP.
• L'élément d'en-tête peut être utilisé pour contenir des informations telles que des informations d'authentification ou la définition de types de données complexes.
• L'élément body est l'élément principal qui contient la définition des méthodes Web ainsi que toutes les informations sur les paramètres si nécessaire.