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
<operation name="myOperation">
<input message="tns:myInputMessage"/>
</operation>
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
<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>
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é. |
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

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.
- 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.
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.

![[Windows]](../images/windows.gif)
- En appliquant et en configurant un ensemble de règles WS-Addressing. Voir la rubrique Configuration de la règle WS-Addressing.
- En définissant la propriété com.ibm.websphere.webservices.use.async.mep sur le contexte de demande du client. Voir la rubrique Appels de services Web JAX-WS de manière asynchrone.
- En utilisant des éléments de descripteur de déploiement, des annotations @Addressing et des fonctions d'adressage, ou en ajoutant les assertions WS-Policy dans le document WSDL. Pour plus de détails, voir la rubrique Activation de la prise en charge de Web Services Addressing pour les applications JAX-WS et ses sous-rubriques.
- 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.