web services - services - ¿Para qué sirve WS-Addressing?
web services addressing (1)
Estoy empezando con los servicios web SOAP y tropecé con WS-Addressing.
He leído la página de Wikipedia , pero me está costando entender exactamente cuál es el objetivo de WS-Addressing.
Según Wikipedia y varias fuentes en la web, WS-Addressing permite poner "información de direccionamiento" o "información de enrutamiento" en el encabezado de una solicitud SOAP.
¿Por qué es esto útil? Si envío una solicitud a través de HTTP (o incluso a través de SMTP o UDP), la dirección a la que envío es la dirección del servidor que procesará mi solicitud, y el servidor simplemente puede responder por el mismo canal. Entonces, ¿por qué es necesaria la información de direccionamiento / enrutamiento?
Me interesaría particularmente algún ejemplo del mundo real (más o menos) en el que WS-Addressing sea útil.
He encontrado que WS-Addressing es especialmente útil en situaciones en las que la respuesta SOAP no se puede atender de inmediato. O los recursos para formar la respuesta no están disponibles de inmediato o el resultado en sí tarda mucho tiempo en generarse.
Eso puede suceder cuando su proceso de negocio involucra "un toque humano", por ejemplo (procesos como los que WS-HumanTask está apuntando). Puede incluir servicios web en su empresa, pero a veces las empresas toman tiempo. Puede ser una suscripción que debe verificarse manualmente, algo que debe aprobarse, lo que sea, pero lleva días hacerlo. ¿Vas a mantener la conexión abierta todo ese tiempo? ¿No vas a hacer nada más que esperar por la respuesta? ¡No! Eso es ineficiente.
Lo que necesitas es un proceso de notificación. El cliente realiza una solicitud pero no espera la respuesta. En su lugar, indica al servidor dónde enviar la respuesta mediante una dirección de "respuesta". Una vez que la respuesta está disponible, el servidor se conecta a esa dirección y envía la respuesta.
Y voila ... interacciones asincrónicas entre servicios web , desacoplando la vida útil del proceso de comunicación de la duración de la conexión HTTP. Muy útil...
Pero espera ... ¿conexión HTTP? ¿Por qué debería importarme eso? ¿Qué ocurre si quiero que la respuesta se envíe de vuelta a otro tipo de protocolo? (que SOAP amablemente proporciona, ya que no está vinculado a ningún protocolo).
Con un flujo de solicitud / respuesta normal, la respuesta llega en el mismo canal que la solicitud, porque es una conexión que conoces ... Entonces, por ejemplo, tienes una conexión HTTP ... eso significa HTTP in y HTTP out.
Pero con WS-Addressing no estás atado a eso. Puede exigir la respuesta en otro tipo de canal . La solicitud entra en HTTP, por ejemplo, pero puede indicar al servidor que envíe la respuesta a través de SMTP, por ejemplo.
De esta forma, WS-Addressing define formas estándar para enrutar un mensaje a través de múltiples transportes. Como dice la página wiki :
en lugar de confiar en el transporte a nivel de red para transmitir información de enrutamiento, un mensaje que utiliza WS-Addressing puede contener sus propios metadatos de despacho en un encabezado SOAP estandarizado.
y en cuanto a su observación:
y el servidor simplemente puede responder por el mismo canal
... lo que funciona para algunos, podría no funcionar para otros, y para otros tenemos WS-Addressing: D.