|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
Request/Reply coordination using Correlation Id |
« View previous topic :: View next topic » |
Author |
Message
|
mooretis |
Posted: Tue Feb 25, 2003 9:47 am Post subject: Request/Reply coordination using Correlation Id |
|
|
Newbie
Joined: 13 Nov 2001 Posts: 9 Location: Kansas City
|
We are trying to develop a standard for coordinating a reply with an inital request. The request may take several hops along the way to the back-end server, so we need a strategy for using the correlation id field in the MQMD.
Everything we have been told to date says to create a unique message id when you put the request and then use that as the correlation id for the response. This works well when you do not have too many hops. We want some of our hops to not have to know if they are the first, second or last hop along the path. If we use what we have been told to date, each hop has to have a way to determine whether to copy the MsgId to the CorrelationId or if it should copy the CorrelationId as is.
In the PMO options, you can specify PMO_NEW_CORREL_ID. This creates a unique correlation id for the message put on the queue. By using this then my hops (and any step along the way) simply has to copy the CorrelationId as is, no additional logic needed.
So, after my long winded question, Is there a reason not to use the last method I detailed above (PMO_NEW_CORREL_ID)? It seems to simplify things, but the IBM documentation continually talks about copying the MsgId to the CorrelationId.
Any insight would be greatly appreciated.  |
|
Back to top |
|
 |
jefflowrey |
Posted: Tue Feb 25, 2003 11:13 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
The basic idea of a request-reply is that one request goes to one application which generates one reply.
It appears that in your model, one request goes to multiple applications which generate multiple replies (or at least, multiple partial replies). Or do I misunderstand what you mean by 'multiple hops'?
There are a variety of fields in the MQMD that could be used to correlate each of these partial or addtional replies to the orignal request. The Correlation ID is one of them. It is very easy to filter messages on a queue by the Message ID or the Correlation ID. This is an advantage to use either of those fields instead of some of the other fields.
Your solution is perfectly workable. It seems to me that each 'hop' has to know how to add it's own reply to the replies from every other hop in your model. That may add unnecessary complexity to the code for each hop.
Another solution would be to have each 'hop' send it's own reply back to the ReplyToQueue. Then each requesting process has to know how to assemble all the replies into a comprehensive answer.
You could also implement a different model. One request goes to one replying process. That replying process then makes new requests for each relevant partial reply needed, and aggregates all the replies itself before it responds to the inital requestor. This might seem like it adds unnecessary wait time for the final reply - however, you still have to wait for each partial reply to be generated and assemble the replies into a unified answer no matter how you do it. |
|
Back to top |
|
 |
mooretis |
Posted: Tue Feb 25, 2003 2:32 pm Post subject: |
|
|
Newbie
Joined: 13 Nov 2001 Posts: 9 Location: Kansas City
|
Jeff,
Thanks for the reply. Here is some clarification on our situation.
For example:
App A ----> Transform -----> Route -----> App B
where at each arrow the message is removed from a queue and put onto another. This is what I meant by hop. App B would ultimately get the message and respond directly to App B or the reverse would happen.
We had been using the MsgId to CorrelId method when I ran across the PMO_NEW_CORREL_ID option. This seemed so much easier than to worry about when I copy the MsgId to CorrelId and when to leave CorrelId alone. It was just that everything until now suggested that we use the MsgId to CorrelId method, and I was wondering if there was a problem with just generating a new CorrelId using PMO_NEW_CORREL_ID instead. |
|
Back to top |
|
 |
|
|
 |
|
Page 1 of 1 |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|
|
|