Patrones de intercambio de mensajes de Web Services Addressing
La especificación de W3C (World Wide Web Consortium) de WS-Addressing (Web Services Addressing) define explícitamente las propiedades principales de WS-Addressing para los patrones de intercambio de mensajes (MEP) definidos por WSDL 1.0. En este tema se resumen estos MEP y se ilustran las propiedades de WS-Addressing obligatorias de cada patrón.
MEP unidireccional
<operation name="myOperation">
<input message="tns:myInputMessage"/>
</operation>
Nombre MAP de WS-Addressing abstracto, utilizando el convenio de notación del conjunto de información W3C XML | Descripción de un mensaje de entrada unidireccional |
---|---|
[acción] | La acción WS-Addressing que se genera en función de la versión de la especificación de WS-Addressing en uso. |
[punto final de respuesta] | El punto final de respuesta de WS-Addressing que indica que no se esperan respuestas a este mensaje de entrada. El valor de esta MAP depende de la versión de la especificación de WS-Addressing en uso. |
[ID de mensaje] | Identificador de mensaje generado exclusivamente. Aunque no sea obligatorio según la especificación, el tiempo de ejecución de WebSphere Application Server define su valor automáticamente. |
Aunque la operación WSDL de este intercambio de mensajes no especifica respuestas, se pueden enviar mensajes relacionados como parte de otros intercambios de mensajes. En concreto, las aplicaciones pueden utilizar el punto final de respuestas WS-Addressing o las MAP del punto final de error para indicar el destino de un mensaje unidireccional donde enviar los mensajes relacionados. Para propagar un punto final de respuesta o un punto final anómalo, asocie la propiedad apropiada con el contexto de solicitud para el objeto BindingProvider de JAX-WS o con el objeto Stub o Call de JAX-RPC, tal como se describe en Especificación y adquisición de las propiedades de direccionamiento de mensajes mediante el uso de las SPI de direccionamiento de servicios web propiedad de IBM, para alterar temporalmente los valores predeterminados.
Solicitud y respuesta bidireccionales
<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>
Nombre MAP de WS-Addressing abstracto, utilizando el convenio de notación del conjunto de información W3C XML | Descripción del mensaje de entrada de una operación de solicitud y respuesta |
---|---|
[acción] | La acción WS-Addressing que se genera en función de la versión de la especificación de WS-Addressing en uso. |
[ID de mensaje] | Identificador de mensaje generado exclusivamente. |
Nombre MAP de WS-Addressing abstracto, utilizando el convenio de notación del conjunto de información W3C XML | Descripción del mensaje de entrada de una operación de solicitud y respuesta |
---|---|
[acción] | La acción WS-Addressing que se genera en función de la versión de la especificación de WS-Addressing en uso. |
[relación] | Un conjunto de relaciones que contiene una relación de respuesta con el ID de mensaje que se pasa en el mensaje de solicitud. |
[ID de mensaje] | Identificador de mensaje generado exclusivamente. Aunque no es obligatorio según la especificación, el tiempo de ejecución del servidor de aplicaciones establece automáticamente esta propiedad. |
Solicitud y respuesta síncronas

Para las invocaciones síncronas JAX-WS, si está establecido el punto final de respuesta o el punto final de error, la referencia de punto final que se defina debe utilizar el URI anónimo. Si la referencia de punto final no utiliza el URI anónimo, se genera una excepción javax.xml.ws.WebServiceException. Aunque la referencia de punto final utiliza el URI anónimo, puede utilizar parámetros de referencia en la referencia de punto final para destinar el punto final de la anomalía o la respuesta.
- No tiene habilitada WS-Security o no ha utilizado una herramienta de ensamblaje para especificar que los elementos ReplyTo y FaultTo del mensaje SOAP deben firmarse. En esta situación, es posible utilizar un punto final JAX-WS para enviar mensajes a un tercero, tomando parte potencialmente en un ataque de denegación de servicio. Para evitar estos ataques, especifique el patrón de intercambio de mensajes síncronos y habilite WS-Policy para que los clientes conozcan este requisito.
- Un cliente JAX-WS se comunica a través de un dispositivo NAT. Los URI de los elementos ReplyTo o FaultTo del mensaje SOAP no se puede direccionar a través de este tipo de dispositivo. En esta situación, el cliente debe utilizar el URI anónimo definido por la especificación WS-Addressing y un patrón de intercambio de mensajes síncronos. Para asegurarse de que el cliente cumple con estos requisitos aunque el servidor utilice WS-Policy para solicitar un URI no anónimo en el elemento ReplyTo, especifique el patrón de intercambio de mensajes síncronos en el cliente.
Solicitud y respuesta asíncronas
El modelo de programación JAX-RPC 1.0 no permite las respuestas asíncronas a una operación de solicitud y respuesta bidireccional ni los errores asíncronos generados a partir de ésta.

![[Windows]](../images/windows.gif)
- Aplicando y configurando un conjunto de políticas WS-Addressing. Consulte el tema Configuración de la política WS-Addressing.
- Estableciendo la propiedad com.ibm.websphere.webservices.use.async.mep en el contexto de solicitud del cliente. Consulte el tema Invocación asíncrona de los servicios web JAX-WS.
- Mediante el uso de elementos del descriptor de despliegue, anotaciones @Addressing, características de direccionamiento o añadiendo aserciones WS-Policy en el documento WSDL. Consulte el tema Habilitación de soporte de direccionamiento de servicios web para aplicaciones JAX-WS y sus subtemas.
- La compartición de WS-Policy está habilitada.
- La compartición de WS-Policy no está habilitada, pero:
- el WSDL empaquetado (tal como ha recuperado la solicitud HTTP GET) contiene la información de política relevante.
- Se han utilizado anotaciones @Addressing en el código. En este caso, el tiempo de ejecución del servidor genera un documento WSDL que contiene las conexiones de WS-Policy.