This topic is an overview of implementing a SOAP/JMS Web service using the MQGet node and describes the costs and benefits of this approach.
When you use a synchronous request-reply pattern, the request message is sent using an MQOutput node and the reply is received inline with an MQGet node.
A flow like the one in the following simplified diagram would enable synchronous SOAP-over-HTTP to SOAP-over-JMS translation:
The above flow provides a simple mechanism to implement a synchronous translation of HTTP to SOAP-over-JMS in which each incoming HTTP request is fully processed and responded to before moving onto the next HTTP request. To avoid the failure of the SOAP-over-JMS service, set a timeout on the MQGet node. An advantage of this flow model is that the whole request-reply translation is handled in a single transaction enabling simple rollback and recovery.
This synchronous flow might not be appropriate in cases where the SOAP-over-JMS processing are long running, because the processing of other incoming HTTP requests cannot be initiated until the current request is completed. In this situation the Message Flow must be designed asynchronously, with separate request and reply flows, with any required correlation context being saved to a storage medium in the request flow and restored during the reply flow. A solution is to use a queue to store the required correlation context and use an MQGet node in the reply flow to retrieve it. This flow design allows the HTTP requests to be dispatched to the SOAP-over-JMS service as they are received and replies are delivered back to HTTP in the order that they are received. This prevents, for example, fast running enquiry requests being blocked by a longer running update request.