Modèles d'échange de messages WS-Addressing (Adressage des services Web)

La spécification des services W3C Web Services Addressing (WS-Addressing) définit les propriétés WS-Addressing de base des modèles d'échange de messages (MEP) définis par WSDL 1.0. Ces MEP sont présentés dans cette rubrique qui décrit les propriétés WS-Addressing obligatoires pour chaque modèle.

MEP unidirectionnel

Ce message direct unidirectionnel est défini dans WSDL 1.0 comme opération à entrée uniquement. Le fragment WSDL de cette opération a le format suivant :
<operation name="myOperation">
  <input message="tns:myInputMessage"/>
</operation>
Les propriétés MAP (Message Addressing Properties) WS-Addressing suivantes sont automatiquement ajoutées à l'en-tête d'un message d'entrée WS-Addressing unidirectionnel par l'exécution du serveur d'applications client pour assurer la conformité avec la spécification WS-Addressing.
Conseil : Vous pouvez remplacer ces valeurs à l'aide des interfaces SPI (system programming interfaces) WS-Addressing propriétaires IBM.
Tableau 1. Propriétés MAP (Message Addressing Properties) WS-Addressing qu'ajoute un client à l'en-tête d'un message d'entrée WS-Addressing unidirectionnel. Le tableau répertorie les différents noms de MAP WS-Addressing et fournit une description pour chacun d'eux.
Nom de MAP WS-Addressing abstrait, utilisant la convention à notation du jeu de données XML W3C Description d'un message d'entrée unidirectionnel
[action] Action WS-Addressing générée en conformité avec la version de la spécification WS-Addressing utilisée.
[reply endpoint] Noeud final de réponse WS-Addressing indiquant qu'aucune réponse n'est attendue pour ce message d'entrée. La valeur de cette MAP dépend de la version de la spécification WS-Addressing utilisée.
[message id] Identificateur de message unique généré. Bien qu'il ne soit pas rendu obligatoire par la spécification, le module d'exécution WebSphere Application Server définit automatiquement cette valeur.

Même si l'opération WSDL de cet échange de messages ne spécifie aucune réponse, les messages associés peuvent être envoyés dans le cadre des autres échanges de messages. Plus particulièrement, les applications peuvent utiliser les MAP de noeud final de réponse ou de noeud final d'erreur WS-Addressing pour indiquer à la cible d'un message unidirectionnel où les messages associés doivent être envoyés. Pour propager un noeud final de réponse ou un noeud final d'erreur, associez la propriété adéquate au contexte de demande de l'objet JAX-WS BindingProvider ou à l'objet JAX-RPC Stub ou Call, comme décrit dans Spécification et acquisition de propriétés d'adressage de message à l'aide des interfaces SPI WS-Addressing propriétés d'IBM. pour remplacer les valeurs par défaut.

Réponse de requête bidirectionnelle

Il s'agit d'un MEP de réponse de requête, comme défini dans WSDL 1.1. L'élément de réponse de l'opération peut être défini en tant que message de sortie ou message d'erreur (ou les deux). Le code WSDL suivant montre les diverses formes de définition pour une opération de ce genre :
<operation name="myOperation">
  <input message="tns:myInputMessage"/>
  <output message="tns:myOutputMessage"/>
  <fault="tns:myFaultMessage"/>
</operation>
<operation name="myOperation">
  <input message="tns:myInputMessage"/>
  <output message="tns:myOutputMessage"/>
</operation>
<operation name="myOperation">
  <input message="tns:myInputMessage"/>
  <fault="tns:myFaultMessage"/>
</operation>
L'exécution du client du serveur d'applications garantit que l'en-tête SOAP du message de demande sortant contient les en-têtes d'informations de message WS-Addressing adéquats. L'application appelante n'a pas à définir les en-têtes WS-Addressing. Une réponse est attendue. Vous devez donc spécifier un noeud final de réponse ou un noeud final d'erreur dans le message de demande.
Conseil : Dans la spécification 2005/08, un noeud final de réponse non spécifié est valide car il prend par défaut la valeur d'une référence de noeud final contenant l'URI anonyme.
Le tableau suivant répertorie les MAP que le produit définit par défaut dans une demande de service Web qui utilise le protocole WS-Addressing. Vous pouvez remplacer les MAP ou en spécifier d'autres à l'aide des interfaces SPI WS-Addressing propriétaires IBM.
Tableau 2. Propriétés d'adressage de message ajoutées dans une demande de service Web qu'utilise le protocole WS-Addressing. Le tableau répertorie les différents noms de MAP WS-Addressing et fournit une description pour chacun d'eux.
Nom de MAP WS-Addressing abstrait, utilisant la convention à notation du jeu de données XML W3C Description du message d'entrée d'une opération de réponse de requête
[action] Action WS-Addressing générée en conformité avec la version de la spécification WS-Addressing utilisée.
[message id] Identificateur de message unique généré.
Le tableau suivant répertorie les MAP que le produit définit par défaut pour un message de réponse ou d'erreur WS-Addressing.
Tableau 3. Propriétés d'adressage de message ajoutées dans une réponse ou un message d'erreur WS-Addressing. Le tableau répertorie les différents noms de MAP WS-Addressing et fournit une description pour chacun d'eux.
Nom de MAP WS-Addressing abstrait, utilisant la convention à notation du jeu de données XML W3C Description du message d'entrée d'une opération de réponse de requête
[action] Action WS-Addressing générée en conformité avec la version de la spécification WS-Addressing utilisée.
[relationship] Ensemble de relations contenant une relation de réponse à l'ID message transmis dans le message de requête.
[message id] Identificateur de message unique généré, même s'il n'est pas rendu obligatoire par la spécification, l'exécution du serveur d'applications définit automatiquement cette propriété.

Réponse de requête synchrone

Par défaut, si vous n'utilisez pas l'interface SPI WS-Addressing propriété d'IBM pour définir le noeud final de réponse ou le noeud final d'erreur, l'élément de réponse d'un message bidirectionnel est renvoyé conformément au protocole sous-jacent utilisé. Plus particulièrement, pour une demande HTTP, la réponse est renvoyée de façon synchrone dans la réponse HTTP.
Le client envoie un message au service Web. L'en-tête SOAP contient l'élément <wsa:To>http://example.com/fabrokam/acct</wsa:To>. Le service Web renvoie une réponse synchrone.

Pour les appels synchrones JAX-WS, si vous définissez le noeud final de réponse ou le noeud final d'erreur, la référence de noeud final que vous définissez doit utiliser l'URI anonyme. Si la référence de point de contact n'utilise pas l'URI anonyme, une exception javax.xml.ws.WebServiceException est émise. Bien que la référence de point de contact utilise l'URI anonyme, vous pouvez utiliser des paramètres de référence dans la référence de point de contact pour cibler le point de contact de réponse ou d'erreur.

Pour les applications JAX-WS, vous pouvez spécifier un modèle d'échange de message synchrone en appliquant et en configurant un type de règle WS-Addressing. Ce modèle d'échange est particulièrement utile dans les cas suivants :
  • WS-Security n'est pas activé ou vous n'avez pas utilisé d'outil d'assemblage pour spécifier que les éléments ReplyTo et FaultTo du message SOAP doivent être signés. Dans ce cas, il est possible qu'un noeud final JAX-WS soit utilisé pour envoyer des messages dans une attaque de refus de service. Pour empêcher de telles attaques, spécifiez le modèle d'échange de message synchrone et activez WS-Policy afin que les clients soient avertis de cette exigence.
  • Un client JAX-WS communique via un périphérique NAT. Les URI contenus dans les éléments ReplyTo ou FaultTo du message SOAP ne peuvent pas être acheminés via un tel périphérique. Dans ce cas, le client doit utiliser l'URI anonyme défini par la spécification WS-Addressing et un modèle d'échange de message synchrone. Pour garantir que le client est conforme à ces exigences même si le serveur utilise WS-Policy pour demander un URI non anonyme dans l'élément ReplyTo, spécifiez le modèle d'échange de message synchrone sur le client.
Vous pouvez vous assurer que les serveurs ou les clients sont conscients de l'exigence de messagerie synchrone en activant WS-Policy.

Réponse de requête asynchrone

Le modèle de programmation JAX-RPC 1.0 n'autorise pas les réponses ou erreurs asynchrones pour une opération de réponse de requête bidirectionnelle.

Les réponses aux demandes (ou les erreurs générées à partir de celles-ci) qui sont dirigées vers les noeuds finaux hébergés sur WebSphere Application Server sont destinées au noeud final de réponse ou au noeud final d'erreur conformément à la spécification WS-Addressing. La connexion au client qui génère la requête sera terminée avec une réponse HTTP 202.
Le client envoie un message au service Web. L'en-tête SOAP contient l'élément <wsa:ReplyTo> qui contient lui-même l'élément <wsa:address>http://example.com/fabrokam/acct/replyEP</wsa:address>. Le service Web envoie une réponse au noeud final de réponse. L'en-tête SOAP du message de réponse contient l'élément <wsa:To>http://example.com/fabrokam/acct</wsa:To>.
Pour les appels asynchrones JAX-WS, le noeud final de réponse est généré automatiquement à des fins d'utilisation par l'implémentation JAX-WS. Si vous tentez de définir un noeud final de réponse ou un noeud final d'erreur, une exception javax.xml.ws.WebServiceException est lancée.
[Windows]Remarque : Sur les systèmes d'exploitation Windows, le nom d'hôte local envoyé par le client doit pouvoir être résolu par le service cible, sinon les réponses ne parviennent pas à l'application client. Vous avez également la possibilité de configurer le client pour qu'il envoie son adresse au format IP. Cependant, vous ne bénéficierez pas de DHCP. Pour plus d'informations, voir Appels de services Web JAX-WS de manière asynchrone.
Pour les applications JAX-WS, vous pouvez spécifier un modèle d'échange de message asynchrone de différentes façons. Ce modèle d'échange est particulièrement utile si un noeud final JAX-WS présente un temps d'appel long. Des ressources client et serveur sont utilisées pour garder la connexion ouverte, mais cette consommation de ressources peut s'avérer peu pratique si le service met du temps à répondre.
La configuration du modèle d'échange de messages est indiquée dans les annexes WS-Policy du document WSDL. Les clients pourront accéder aux informations relatives à cette configuration de modèle d'échange de messages si l'une des conditions suivantes a la valeur true :
  • Le partage WS-Policy est activé.
  • Le partage WS-Policy n'est pas activé mais :
    • Le WSDL stocké en package (comme extrait par une requête HTTP GET) contient les informations appropriées sur les règles.
    • Les annotations @Addressing ont été utilisées dans le code. Dans ce cas, l'environnement d'exécution du serveur génère un document WSDL contenant les annexes WS-Policy.
Voir la rubrique fournisseurs de services Web et partage de configuration des règles pour plus de détails.

Icône indiquant le type de rubrique Rubrique de concept



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cwbs_wsa_meps
Nom du fichier : cwbs_wsa_meps.html