Modelo de solicitud-respuesta para SOAP híbrido sobre HTTP / JMS sobre middleware

Question

Uno de nuestros productos implementa la siguiente estructura de servicio web unidireccional:

Server <--------------------- Middleware <---------------- Client
        SOAP over JMS (queue)              SOAP over HTTP

En este modelo, los clientes envían mensajes SOAP a través de HTTP a nuestro middleware (Progress SonicMQ). SonicMQ empuja los mensajes a las colas JMS y nuestro servidor los recupera desde allí. Sin embargo, como puede ver, el servidor no envía una respuesta al cliente (JMS asíncrono).

Nos gustaría implementar un canal de respuesta a este modelo. La solución a menudo sugerida es crear una respuesta temporal a la cola (sobre la marcha) en el middleware, lo que permite al servidor enviar una respuesta a esa cola. Luego, el cliente puede recuperar la respuesta y se cierra la respuesta a la cola. Esto suena bastante conveniente, pero desafortunadamente nuestros clientes operan a través de HTTP simple y no a través de JMS, por lo que sus clientes no pueden configurar fácilmente las colas de respuesta.

Un enfoque para lograr un canal de respuesta en dicho modelo SOAP HTTP / JMS híbrido sería configurar el middleware para abrir la cola replyTo en cada recepción SOAP exitosa, agregar la información de la cola y emisor replyTo al mensaje SOAP y empujar el mensaje a la cola, donde sería recuperado por el servidor. Después de recibir y procesar el mensaje, el servidor podría enviar una respuesta a la respuesta a la cola indicada en el middleware. Finalmente, el middleware enviaría la respuesta (SOAP) a través de HTTP al cliente original mediante el uso de los datos del mensaje SOAP (los datos que se insertaron allí en los procedimientos de middleware cuando se recibió la solicitud por primera vez).

Si bien es posible, esto suena un poco hacky. Entonces la pregunta es: ¿alguna forma más limpia de lograr tal modelo de solicitud / respuesta en nuestro caso? El extremo del servidor se ha implementado en Java.

La solución:

Progress SonicMQ admite " Contenido Responder Enviar " HTTP Acceptor, que permite enviar fácilmente respuestas JMS. El aceptador de envío de respuesta de contenido funciona de la siguiente manera:

• Acceptor recibe el mensaje HTTP que envió un cliente
• Acceptor crea una cola JMS temporal
• Acceptor crea un mensaje JMS, que contiene el cuerpo HTTP, y agrega la identificación de la cola temporal al mensaje JMS recién creado
• El aceptador empuja el mensaje JMS a su cola de destino (no la cola temporal)
• Acceptor comienza a consumir la cola temporal de respuesta a
• Cuando el cliente recupera el mensaje de la cola de destino original, contiene la identificación establecida de la cola de respuesta a
• El cliente consume el mensaje
• El cliente envía una respuesta a la cola de respuesta
• El receptor recibe un mensaje de la cola
• Acceptor envía un mensaje como HTTP al cliente que originalmente envió el mensaje HTTP

En caso de que el consumidor (& "; servidor &"; en nuestro caso) falle y no envíe la respuesta causando el tiempo de espera, el Aceptador HTTP de Sonic envía un mensaje HTTP al cliente que indica el tiempo de espera. Esta es una característica muy estándar en SonicMQ. Supongo que también existe en otros productos.

Esto permite usar SOAP estándar sobre JMS (ver la respuesta de skaffman) en " server " end evita cualquier programación personalizada en el middleware.

Todavía veo algunos problemas en el modelo JMS, pero definitivamente es una mejora.

Actualización 2009-11-05:

Después de investigar este problema aún más, resulta mi sospecha contra HTTP < - > middleware < - > JMS ha sido relevante.

Hay algunos problemas críticos en este modelo. El modelo síncrono-asíncrono con middleware simplemente no es conveniente. O bien, ambos extremos implementan la conexión JMS (que debería funcionar bien) o utilizar HTTP en ambos extremos. Mezclarlos solo produce dolores de cabeza. De estos dos, SOAP-over-HTTP es más simple y mejor soportado que SOAP-over-JMS.

Una vez más: si está diseñando este tipo de sistema ... NO LO HAGA.

Answer 1

No creo que su solución sugerida sea un truco, creo que es la solución correcta. Tiene la capa intermedia del cliente con un protocolo síncrono, y luego la capa intermedia del servidor con una capa asincrónica, a la que debe agregar una ruta de respuesta para satisfacer la semántica síncrona. Para eso es el middleware. Recuerde que JMS proporciona soporte explícito para colas de respuesta temporales, no tendrá que meterse con la carga útil en absoluto.

Una posibilidad más del campo izquierdo es aprovechar el hecho de que SOAP 1.2 fue diseñado con JMS en mente, por lo que podría usar la capa de servicio web entre el middleware y la capa de servidor que hace SOAP sobre JMS. Eso significa que puede mantener SOAP de principio a fin, con el middleware cambiando solo el transporte.

La única pila de servicios web que conozco que admite el transporte JMS es Spring Web Servicios , donde el proceso y el desarrollo es documentado aquí . Esto también le daría la oportunidad de portar su capa SOAP a Spring-WS, lo que lo hace genial :)

Answer 2

¿Por qué no agregar un enlace a una página que permita a los usuarios verificar si una respuesta está lista, como un identificador de seguimiento de Fed Ex? Proporcione a sus usuarios la identificación del rastreador cuando envíen la solicitud.

Esto encajaría en el lenguaje de solicitud / respuesta HTTP, y sus usuarios aún sabrían que la solicitud es " dispare y olvide " ;.