| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| ESB Request / reply with provider outside of cluster |
« View previous topic :: View next topic » |
| Author |
Message
|
| Keka |
 Posted: Tue Oct 23, 2007 4:48 pm Post subject: |
 |
|
Voyager
Joined: 28 Dec 2002
Posts: 96
|
You are correct it is and this is how it is implemented right now and the way the application was developed( god knows who did, old legacy code) they are using this as part of the configuration. So you are correct in the sense that this is not a good design. But originally ( atleast that is what they told me) when this was developed the reply msg was an independent msg not a reply msg. go figure.. But they dont want to change the way the app responds, in my opinion they should use the replyToQ of the incoming msg to figure out where to send the reply back to. since they already have this in place, I used that infrastructure to implement my logic.. 
_________________
Keka |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Tue Oct 23, 2007 4:50 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Well, honestly. It's better for them to hardcode the broker reply queue than the WAS reply queue! 
I'd still tend to save the state in Broker, and set the "correct" thing on the request message to the MF for the replytoq and replytoqmgr... becuase this way the Broker flow will continue to work even if the MF changes it's implementation to do "the right" thing.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Keka |
| Posted: Tue Oct 23, 2007 5:13 pm Post subject: |
|
|
Voyager
Joined: 28 Dec 2002
Posts: 96
|
OK, now I need to ask this question. So lets say you want to maintain state in the broker that means, it has to store the incoming info (MQMD) fom WAS some place. Either on an MQ queue then use GETNode or Database.
If you were to do it how else would you do it??
Also it has been a while since i did broker dev, my last big project was on 2.1, that should tell you how many ages it has been. So I really wanted to do this setup just using MQ and it was fun trying to figure out how to make mq maintain the state for me without really affecting the logic. If you think about it you would never populate the reply msg with the replyToQ and ReplyToQmgr unless you need a COA and COD. so essentially i did not really impact much.
As for the msg coming from broker, the only thing they would populate would be their reply queue. Again this has to be hard coded or May be there is a way now to read the environment or config..
Also somebody suggested using environment in broker, can anybody shed some light on that..
Thanks again for all the suggestions, I wanted to do it this way for 2 reasons that we always deal with.
1. Minimum code change because we dont know MQ and minimum impact.
2. Project deadline, any bigger code change we need to re-think the design.
3. Top it all of, I wanted to see how I can do it just using (mostly I should say) MQ..
_________________
Keka |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Oct 23, 2007 6:15 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Well, for one... if at all possible, I would process the "upstream" reply (from the MF) synchronously in the broker flow - using an MQGet node.
Then I wouldn't have to do anything "fancy" to store the state. Just either copy the original replytoq and replytoqmgr into Environment, or configure MQGet to not overwrite original message.
If there were good solid business reasons not to process the reply synchronously, then I would examine the requirements to find out if it was feasible to a) store the "state" in the request message (to MF) itself, or b) use a SHARED variable in v6 (likely a SHARED ROW) to store the data, or c) use Aggregation and an additional request or reply message to store the state, or finally look at using a DB or a queue to store state.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Keka |
| Posted: Wed Oct 24, 2007 2:40 am Post subject: |
|
|
Voyager
Joined: 28 Dec 2002
Posts: 96
|
Beautiful but did not really understand the 1st two options. I need to readup more about environment and MQget Node. My understanding of MQGet node is that it gives you ability to read an additional MQQueue apart from the MQInput and can be done at any part of the flow. Ofcourse it automatically combines the result tree with the input tree etc. So even if I make the broker synchronous, I would still have to keep the original request from WAS some where to use the MQGet in the reply flow to grab that info. Am i missing something really simple here??
As for environment, Again, I need to readup, that will be my todo today.
SHARED ROW sounds interesting, more to read.. 
Aggregation, again lost, i thought its purpose is to combine multiple msgs for ex: multiple replies for a single request and form a msg. How is this appropriate here??
Boy am i so backwards in MessageBroker now.. 
Thanks for all the pointers Jeff, I will definitely read up on these.. I want to make this flow( whole of the process) as scallable and ready for future as possible..
_________________
Keka |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Oct 24, 2007 12:19 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
No, you can tell the MQGet node where to insert the message it reads - it does not have to overwrite the input message. So you can, for example, append to the original message tree with the reply data.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
