WebSphere Message Broker, Versión 8.0.0.5 Sistemas operativos: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

Consulte la información sobre la última versión del producto en IBM Integration Bus, Versión 9.0

Elección del comportamiento asíncrono para el nodo SOAPAsyncRequest

Elija entre la solicitud-respuesta asíncrona HTTP y WS-Addressing para realizar solicitudes asíncronas utilizando el nodo SOAPAsyncRequest con transporte HTTP.

Lea la información de concepto acerca de Utilización de consulta-respuesta asíncrona HTTP.

El nodo SOAPAsyncRequest puede utilizar transporte HTTP o JMS. Se enlaza como un par con un nodo SOAPAsyncResponse utilizando un identificador exclusivo para correlacionar los mensajes de respuesta con la solicitud original.

El nodo SOAPAsyncRequest envía una solicitud de servicio web, pero el nodo no espera a que se reciba la respuesta de servicio web asociada. Esta funcionalidad asíncrona permite realizar varias solicitudes de salida casi en paralelo, ya que la solicitud de salida no se bloquea en espera de la respuesta. El nodo SOAPAsyncResponse, que puede estar en un flujo de mensajes separado, recibe la respuesta del servicio web.

El nodo SOAPAsyncRequest soporta dos métodos de solicitudes asíncronas cuando se utiliza el transporte HTTP:
  1. Utilización de WS-Addressing para dirigir la respuesta al nodo SOAPAsyncResponse emparejado. El nodo SOAPAsyncRequest espera el acuse de recibo de HTTP 202 antes de continuar con el flujo de mensajes y el nodo SOAPAsyncRequest se bloquea si no se recibe el acuse de recibo. El servidor de fondo realiza una nueva conexión HTTP para responder al nodo SOAPAsyncResponse. Éste es el comportamiento predeterminado.
  2. Utilización de solicitud-respuesta asíncrona HTTP. Cuando se selecciona la propiedad de SOAPAsyncRequest Utilizar solicitud-respuesta asíncrona HTTP, el nodo SOAPAsyncRequest pasa el socket HTTP al nodo SOAPAsyncResponse emparejado para permitir que el servidor de fondo responda utilizando el mismo socket. Cuando se selecciona esta opción, las cabeceras de WS-Addressing se envían, pero es necesario que el servidor de fondo las comprenda. Las cabeceras WS-Addressing no se marcan como mustUnderstand y la cabecera replyTo se establece en anónima. Por consiguiente, el nodo utiliza el manejo de socket HTTP asíncrono en lugar de WS-Addressing para realizar solicitudes HTTP y recibir una respuesta asíncrona.

Normalmente elegirá el método de solicitud-respuesta asíncrona HTTP para realizar solicitudes asíncronas utilizando el nodo SOAPAsyncRequest con el transporte HTTP. Para utilizar este comportamiento, asegúrese de que se ha seleccionado la propiedad de nodo SOAPAsyncRequest Utilizar solicitud-respuesta asíncrona HTTP.

Sin embargo, es posible que, en lugar de ello, desee utilizar WS-Addressing para realizar solicitudes asíncronas utilizando el nodo SOAPAsyncRequest en los casos siguientes:
  • Si desea utilizar WS-Addressing para establecer de forma explícita la cabecera replyTo para el mensaje de respuesta
  • Si el servidor de fondo tiene una latencia alta, es aconsejable utilizar WS-Addressing en lugar de la solicitud-respuesta asíncrona HTTP para que el socket HTTP no se quede abierto durante mucho tiempo.
Para utilizar WS-Addressing en lugar del comportamiento de solicitud-respuesta asíncrona HTTP cuando se utiliza el transporte HTTP, asegúrese de que la propiedad de nodo SOAPAsyncRequest Utilizar solicitud-respuesta asíncrona HTTP se ha borrado. Éste es el comportamiento predeterminado del nodo SOAPAsyncRequest.
Avisos | Marcas registradas | Descargas | Biblioteca | Soporte | Comentarios

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        Última actualización:
        
        Última actualización: 2015-02-28 17:00:48


Tema de tareaTema de tarea | Versión 8.0.0.5 | bc19322_