Uno de nuestros productos implementa la siguiente estructura servicio web en un solo sentido:petición-respuesta para SOAP híbrida a través de HTTP/JMS sobre middleware
Server <--------------------- Middleware <---------------- Client
SOAP over JMS (queue) SOAP over HTTP
En este modelo, los clientes enviar mensajes SOAP sobre HTTP en nuestro middleware (Progreso SonicMQ). Los mensajes son enviados a las colas JMS por SonicMQ y nuestro servidor los recupera desde allí. Sin embargo, como puede ver, el servidor no envía una respuesta al cliente (JMS asíncrono).
Queremos implementar un canal de respuesta a este modelo. La solución que a menudo se sugiere es crear una cola de ResponderTa temporal (sobre la marcha) en el middleware, permitiendo que el servidor envíe una respuesta a esa cola. Luego, el cliente puede buscar la respuesta y la cola de responder está cerrada. Esto parece bastante conveniente, pero desafortunadamente nuestros clientes operan en HTTP plano y no en 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 híbrido HTTP/JMS SOAP sería configurar el middleware para abrir la cola replyTo en cada recepción exitosa SOAP, anexar la información de Responder a la cola y del remitente al mensaje SOAP e impulsar el mensaje a la cola, donde sería captado por el servidor. Después de recibir y procesar el mensaje, el servidor podría enviar una respuesta a la respuesta indicada Cola en el middleware. Finalmente, el middleware enviará la respuesta (SOAP) a través de HTTP al cliente original utilizando los datos del mensaje SOAP (los datos que se insertaron allí en los procedimientos de middleware cuando se recibió la solicitud por primera vez).
Aunque es posible, esto suena como un hacky. Entonces la pregunta es: ¿formas más limpias de lograr dicho modelo de solicitud/respuesta en nuestro caso? El extremo del servidor se ha implementado en Java.
La solución:
Progreso SonicMQ apoya "Contenido Responder Enviar" aceptador de HTTP, que permite enviar fácilmente respuesta JMS. El contenido Responder Enviar obras aceptor en una siguiente manera:
- aceptador recibe el mensaje HTTP a un cliente envía
- aceptador crea una cola JMS temporal
- aceptador acumula un mensaje JMS, que contiene el cuerpo HTTP y agrega la identificación de la cola temporal al mensaje recién creado JMS empuja
- aceptador el mensaje JMS en su cola de destino (no la cola temporal)
- aceptador comienza a consumir el temporal cola de respuestas
- Cuando el cliente obtiene el mensaje de la cola de destino original, que contiene el conjunto de cola de respuestas de identificación
- cliente consume mensaje
- El cliente envía la respuesta a la cola de respuestas
- aceptador recibe mensaje de la cola
- aceptor envía mensaje como HTTP al cliente que envió originalmente el mensaje HTTP
en caso de consumo ("servidor" en nuestro caso) fallar y no enviar respuesta causando tiempo de espera, aceptador de HTTP de sonic envía un mensaje HTTP al cliente indicando el hora o Utah. 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 el extremo "servidor", evita cualquier programación personalizada en el middleware.
Todavía veo algunos problemas en el modelo JMS, pero esto definitivamente es una mejora.
Actualización 2009-11-05:
Después de investigar este asunto aún más, resulta que 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 tienen ambos extremos implementando la conexión JMS (que debería oscilar) o van con 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.
El soporte nativo para SOAP sobre JMS suena bien. No sabía que existía. Además de Spring, parece que la implementación de Metro JAX-WS también admite SOAP sobre JMS. Supongo que cualquiera de estos permite la configuración personalizada JMS fábrica y configuraciones de cola? Estoy reflexionando sobre eso, porque tenemos que establecer algunas propiedades específicas de SonicMQ. Además, SonicMQ envía una respuesta OK/fault por defecto, así que tengo que anular eso en el middleware. Sin embargo, supongo que debería ser fácil. Parece que tengo algunos estudios que hacer ... –
Parece que tienes algo interesante de ingeniería que hacer :) Supongo que Spring-WS usa Spring's JMS, que es bastante bueno, y debería permitirte personalizar todo lo que necesites. – skaffman