Partager via


Vue d’ensemble de la couche de modèle de service

L’API modèle de service WWSAPI modélise la communication entre un client et un service sous forme d’appels de méthode, plutôt que sous forme de messages de données. Contrairement à la couche de canal, qui prend en charge les échanges de messages plus traditionnels entre le client et le service, le modèle de service gère automatiquement la communication au moyen d’un proxy de service sur le client et d’un hôte de service sur le service. Cela signifie que le client appelle des fonctions générées et que le serveur implémente les rappels.

Par exemple, considérez un service de calculatrice qui effectue l’addition et la soustraction sur deux nombres. L’addition et la soustraction sont des opérations naturellement représentées sous forme d’appels de méthode.

Diagramme montrant comment un service de calculatrice communique avec un client à l’aide d’appels de méthode pour l’addition et la soustraction.

Le modèle de service représente la communication entre le client et le service en tant qu’appels de méthode déclarés, et masque donc les détails de communication de la couche de canal sous-jacente de l’application, ce qui facilite l’implémentation du service.

Spécification d’un service

Un service doit être spécifié en termes de ses modèles d’échange de messages, ainsi que de sa représentation des données réseau. Pour les services, cette spécification est généralement fournie sous forme de documents de schéma WSDL et XML.

Le document WSDL est un document XML qui contient la liaison de canal et les modèles d’échange de messages du service, tandis que le document de schéma XML est un document XML qui définit la représentation des données des messages individuels.

Pour le service de calculatrice et ses opérations d’addition et de soustraction, le document WSDL peut ressembler à l’exemple suivant :

<wsdl:definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" 
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" 
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns="http://Example.org" 
xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" 
xmlns:wsap="http://schemas.xmlsoap.org/ws/2004/08/addressing/policy" xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns:msc="http://schemas.microsoft.com/ws/2005/12/wsdl/contract" xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl" 
xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/" xmlns:wsa10="http://www.w3.org/2005/08/addressing" 
xmlns:wsx="http://schemas.xmlsoap.org/ws/2004/09/mex" targetNamespace="http://Example.org" 
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
 <wsdl:portType name="ICalculator">
  <wsdl:operation name="Add">
   <wsdl:input wsaw:Action="http://Example.org/ICalculator/Add" 
   message="tns:ICalculator_Add_InputMessage" />
   <wsdl:output wsaw:Action="http://Example.org/ICalculator/AddResponse" 
   message="tns:ICalculator_Add_OutputMessage" />
  </wsdl:operation>
 </wsdl:portType>
</wsdl:definitions>

De même, son schéma XML peut être défini comme suit :

<xs:schema xmlns:tns="http://Example.org" elementFormDefault="qualified" 
targetNamespace="http://Example.org" xmlns:xs="http://www.w3.org/2001/XMLSchema">
 <xs:element name="Add">
  <xs:complexType>
   <xs:sequence>
    <xs:element minOccurs="0" name="a" type="xs:int" />
    <xs:element minOccurs="0" name="b" type="xs:int" />
   </xs:sequence>
  </xs:complexType>
 </xs:element>
 <xs:element name="AddResponse">
  <xs:complexType>
   <xs:sequence>
    <xs:element minOccurs="0" name="result" type="xs:int" 
    />
   </xs:sequence>
  </xs:complexType>
 </xs:element>
</xs:schema> 

Conversion des métadonnées en code

Le modèle de service fournit l 'WsUtil.exe en tant qu’outil permettant de traiter ces documents de métadonnées, en convertissant un fichier WSDL en un en-tête C et des fichiers sources.

Diagramme montrant comment WsUtil.exe convertit un fichier WSDL en un en-tête C et des fichiers sources.

Le WsUtil.exe génère un en-tête et des sources pour l’implémentation du service, ainsi que des opérations de service côté client pour le client .

Appel du service calculatrice à partir d’un client

Comme pour l’implémentation du service, le client doit inclure le ou les en-têtes générés.

#include "CalculatorProxyStub.h"

À présent, l’application cliente peut créer et ouvrir un proxy de service pour commencer la communication avec le service de calculatrice.

WS_ENDPOINT_ADDRESS address = {0};
WS_STRING uri= WS_STRING_VALUE(L"http://localhost/example");
address.uri = uri;

if (FAILED (hr = WsCreateServiceProxy(WS_CHANNEL_TYPE_REQUEST, WS_HTTP_CHANNEL_BINDING, NULL, NULL, 0, &serviceProxy, error)))
    goto Error;

if (FAILED (hr = WsOpenServiceProxy(serviceProxy, &address, NULL, error)))
    goto Error;

L’application peut appeler l’opération Ajouter sur le service de calculatrice avec le code suivant :

if (FAILED (hr = DefaultBinding_ICalculator_Add(serviceProxy, heap, 1, 2, &result, NULL, 0, NULL, error)))
    goto Error;

Reportez-vous à l’exemple de code sur HttpCalculatorClientExample pour l’implémentation complète du service de calculatrice.

Composants du modèle de service

L’interaction des composants individuels du modèle de service WWSAPI dans l’exemple calculatrice est la suivante :

  • Le client crée un proxy de service et l’ouvre.
  • Le client appelle la fonction Add du service et passe le proxy de service.
  • Le message est sérialisé en fonction des métadonnées de sérialisation dans les fichiers d’en-tête et sources générés par l’outil de métadonnées (WsUtil.exe).
  • Le message est écrit dans le canal et est transmis au service via le réseau.
  • Côté serveur, le service est hébergé dans un hôte de service et a un point de terminaison à l’écoute du contrat ICalculator.
  • À l’aide des métadonnées du modèle de service dans le stub, le service désérialise le message du client et le distribue au stub.
  • Le service côté serveur appelle la méthode Add, en lui passant le contexte d’opération. Ce contexte d’opération contient la référence au message entrant.

Diagramme montrant l’interaction des composants individuels du modèle de service WWSAPI.

Components

  • Hôte de service : héberge un service.
  • Proxy de service : définit la façon dont un client communique avec un service.
  • Contexte : conteneur de propriétés permettant de mettre des informations spécifiques à l’état à la disposition d’une opération de service.
  • Contrat : définition d’interface d’un service. Par exemple, ICalculator représente un contrat pour le service de calculatrice dans notre exemple de code.
  • WsUtil.exe: outil de métadonnées de modèle de service pour générer des proxys et des stubs.