| Author |
Message
|
| Keka |
 Posted: Thu Oct 18, 2007 11:05 am Post subject: |
 |
|
Voyager
Joined: 28 Dec 2002
Posts: 96
|
Guys,
I know this post is old and pretty much closed. But I have a simillar situation and did not quite get what you guys were suggesting. Here is my setup
I have 4 qmgrs in cluster.
2 app qmgrs and 2 broker qmgrs in cluster.
There is also mainframe qmgr that is not part of the cluster.
The req comes from the app qmgr, gets parsed through the broker and sent to mainframe qmgr(outside the cluster). Now the reply comes back from mainframe to broker and gets parsed by broker and the reply needs to go back to app qmgr. But it needs to go back to the app that originated it.
I know the scenario you discussed is same but I cant picture this working unless the broker actually keeps track of the original msgs reply to Q and replytoQmgr and use that to send the final parsed reply back to the app.
So this is what I think should happen, let me know if you think otherwise.
1. App ---> broker --- ReplyQmgr=app qmgr, replyQ=appreplyQ
2.Broker--- creates a blank tracker msg, dumps to a q, create new msg
and send to mainframe. ReplytoQmgr-brokerqmgr, replyQ- BrokerReplyQ.
3.MainFrame- process the msg, copy the correlation ID to the reply send to brokerQmgr, BrokerReplyToQ.
4. Broker - Process the msg, use the correlation id to get the tracker msg, get the replytoQ and replytoQmgr and set it to the msg and then use ReplyNode or OutputNode to send it to the AppQmgr.
Does this sound correct or is there a simpler way to do it?? The other thing I could think of is to use alias qmgr name same as the app Qmgr and keep that in the replytoQmgr name in all the 4 steps.. and make the alias qmgr on mainframe to point to the broker..
sorry for long post, wanted to make sure I explain it correctly. Sorry if I overstated it.
Thanks
Keka
_________________
Keka |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Thu Oct 18, 2007 11:17 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Service Proxy is ( or should be? I haven't checked) a design pattern. And, yes, in a Proxy pattern, the piece acting as the proxy is responsible for a) knowing how to talk properly to the internal thing it is acting as a proxy for, and b) knowing how to respond back to the original requestor.
So, yes, in all cases when building a Broker flow that is acting as a Proxy, and accepting input in an MQ Request/Reply pattern, then the Broker flow needs to keep track of the original ReplyToQueue and ReplyToQueue Manager.
There's a bunch of different ways to do that.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Keka |
| Posted: Thu Oct 18, 2007 11:34 am Post subject: |
|
|
Voyager
Joined: 28 Dec 2002
Posts: 96
|
that is a quick reply and thanks.
That is what I thought. But in the picture and in your discussion, you dont talk about broker having to track the msg.
There is another way I thought i could do, it has been a while since I worked on broker flow dev so correct me if i am wrong
Lets say below is the set up to make the explanation easy
App Qmgrs= AppQM1, AppQM2
Brk Qmgrs=BrkQm1, BrkQm2
mainframe Qm=MfrmQm
Now the original request msg from App to the broker will have the replyToQmgr set to AppQm1.
It is received by ( could be either of the broker) for discussion sake BrkQM1. Now it sets the replyToQmgr on the msg sent to the MainFrame as still AppQM1.
On Mainframe the request has the ReplyToQmgr AppQm1, so when it sends the reply back, it sends it to the Qmgr AppQm1 but also keep the replyToQmgr in the reply still set to AppQm1.
I will define an alias qmgr on Mainframe AppQm1 pointing to BrkQm1. So the msg gets to the broker. Broker parses it and uses a replyNode to send it out and since the replyToQmgr is still set to AppQm1, it will make it to the originator.
Does this sound like a scenario that will work. I know I am being lazy here and not developing the flow but it will take a while for me to set this up to really test it. But logically and theoretically it seems like a flow that can work.
Your comments please..
Keka
_________________
Keka |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Oct 18, 2007 12:11 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Saying that you're being lazy is a good way to lose friends here fast.
In most cases, Broker needs to be involved on both sides of the proxied service call - the request and the reply.
This means it pretty much needs to go 1) Calling app 2) Broker 3) "MF" 4) Broker 5) calling App. It's four legs. it's what allows you to build an Integration Hub or an ESB.
If the calling app is capable of processing the MF response directly, then it's not clear what value the Broker provides in the first place - presumably the calling app could also be built to send the MF request directly. And then everyone is tightly coupled to all of their integration points.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Oct 18, 2007 2:32 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Quote: |
| I know the scenario you discussed is same but I cant picture this working unless the broker actually keeps track of the original msgs reply to Q and replytoQmgr and use that to send the final parsed reply back to the app. |
You need to find somewhere in the flow a space to keep the incoming MQMD and pass it on in the output to the MQReply node.
We use the environment for that....
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Oct 18, 2007 2:38 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
|
| Back to top |
|
|
| Keka |
| Posted: Thu Oct 18, 2007 3:33 pm Post subject: |
|
|
Voyager
Joined: 28 Dec 2002
Posts: 96
|
Thank you so much for the response. When I said I was lazy, I was only saying that I could have tested it right now and then asked what is going wrong. I just need to go through a lot of process to get this setup on my laptop as I just moved in to a new project (and group) and the env is not ready. Again that is not an excuse, i just wanted to get the information while i am getting ready with the setup. most importantly I wanted to make sure I am not losing my mind trying to figure out how I can just setup MQ to make this work without having the broker with the intelligence to keep the tracker msg.
Your replies confirms that my original Idea of Broker keeping the original msg and then using MQGet Node and MQ Reply node to combine that information with the final reply is the way to go.. I will test this and post back if I found any other way to get this accomplished..
Again thanks for your time and I have no intentions of losing friends and expertise here..
chao
Keka
_________________
Keka |
|
| Back to top |
|
|
| Keka |
| Posted: Tue Oct 23, 2007 10:02 am Post subject: |
|
|
Voyager
Joined: 28 Dec 2002
Posts: 96
|
All right guys, finally got all the access setup etc done and got my hands on the env.
I did one change to my original setup. I now added the MF qmgr in to the cluster as well to create more load balancing for the reply even though MF qmgr itself is a single point of failuer.. 
So my theory of using the replytoQ and replytoQmgr to create the back route to get to the proper source works.
There is no intelligence required in the broker side. The whole logic is driven by keeping the replyQ and ReplyToQmgr same as it is passing through different steps..
So no state maintenance needed in broker..
_________________
Keka |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Oct 23, 2007 10:20 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
As I said, this is only a valid approach if Broker doesn't need to perform any transformations on the return.
It also breaks the service proxy pattern...
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Keka |
| Posted: Tue Oct 23, 2007 10:53 am Post subject: |
|
|
Voyager
Joined: 28 Dec 2002
Posts: 96
|
Nope that is not true, if the broker does not need to do any transfermantion then there is no issue to begin with and MF could directly send the response back to WAS via xmit queue path. But Broker does need to transform the reply in the format understandable to WAS..
_________________
Keka |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Oct 23, 2007 11:11 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Oh, I see. I missed the part about the qmgr alias. I'd thought you were routing the reply directly back to the original app.
It's a workable solution, but it's not necessarily scalable - you always have to take extra action on the MF when you bring a new sending app qmgr on line.
And it also presents the problem of "what if some other application on the MF needs to send messages to AppQmgr1 - that can't go through BrkQmgr1".
Thirdly, someone looking at the message itself will be very confused about where it's going to go.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Keka |
| Posted: Tue Oct 23, 2007 11:29 am Post subject: |
|
|
Voyager
Joined: 28 Dec 2002
Posts: 96
|
All good points, but I disagree on couple things.. I love the disagreement that is how I learned what ever little I knew.. 
Also there is no qmgr alias in this whole setup.
Scalability, MF app does not know the origin of it. So let us say in future there is another QMgr that is added to the cluster that is sending msg to this then it will automatically do that as it is in the same cluster.
If they want to send msgs to WAS directly, they will do so since they are part of the cluster and hence visible to the MF.
As for the somebody looking at the msg, well it will show the origin of it and when you are dealing with request/reply this is more clearer to somebody than having the intermediate broker qmgr..
But there is one issue with this setup. If there is ever a need for a COA for the reply msg from MF, this wont cut it, if you know what i mean..
_________________
Keka |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Oct 23, 2007 11:40 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Okay, now I'm really confused.
You've posted two different setups - one that created an "alias qmgr" (which is to say, a qmgr alias) on the MF, and one that didn't.
In the one that didn't create a qmgr alias on the MF, you said you were keeping state on the Broker - by keeping track of what the original replytoqueue and replytoqmgr are.
You then said that you'd solved your problem by clustering things, and NOT keeping track of the state.
Is the MF app is addressing the reply message back to the replytoq and qmgr that the sending app sets, or to the one that the broker sets?
If the MF is addressing the reply message using the one that the sending app sets - and you need it to go to broker, then you have to do something to redirect that on the MF qmgr so that it goes to Broker instead.
And that affects all communications going to that qmgr from the MF. Even with clustering.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Keka |
| Posted: Tue Oct 23, 2007 4:24 pm Post subject: |
|
|
Voyager
Joined: 28 Dec 2002
Posts: 96
|
Sorry for doube posting,accidentally clicked something and posted incomplete..
Let me try again.. 
My apologies for the confusion.
You are correct initially when I posted the alternative method, i was thinkng in the lines of creating an alias qmgr on MF, that would work without having MF qmgr in the cluster. But it will create a specific route each of the brokers in the return path.
One thing that is common in both methods( MF not in cluster and in cluster) is to make the broker keep the replyToQ and replyToQmgr name same as the original sending app. So here goes the setup.
So discussion sake let us assume the below.
Location Qmgr Queues
WAS WAS1 WAS_REPLY
WAS WAS2 WAS_REPLY
BRK BRK1 BRK_REQ_IN, BRK_REPLY_IN
BRK BRK1 BRK_REQ_IN, BRK_REPLY_IN
MF MF MF_REQ_IN
All these are in cluster.
So app connected to WAS1 sends the msg to BRK_REQ_IN and lets say it goes to Broker1. In this msg the replyToQ is set to WAS_REPLY and ReplyToQmgr is set to WAS1.
Now broker does the conversion and as part of the process it copies the original correlationId, ReplyToQ and ReplyToQmgr in to the output msg and put msg to MF_REQ_IN.
Now MF process receive the msg and does it needs to and then creates the reply msg. But before it puts the reply back it copies the replyToQ and ReplyToQmgr from the incoming request from broker( Remember broker set it to WAS1 and WAS_REPLY by copying) to the reply msg. The reply msg is put to the queue BRK_REPLY_IN. This where the cluster comes in to picture. this queue is defined on Broker but visible to MF, hence no routing required( unlike the first method where I would have to create an alias qmgr with the name WAS1 and point to BRK1 or BRK2, hence a single route to each of the broker).
So when the broker receives the msg it does the transfermation and uses a replyNode instead of the outputNode. Hence it ends up where it started, i.e WAS1.
Hope this explains it better.
_________________
Keka |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Oct 23, 2007 4:36 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Okay... I *think* I see what you're getting at now.
You're not using the ReplyToQueue and ReplyToQmgr to address the message from the MF.
You're just putting them in the message from the MF.
So how does the MF know which queue to send the reply to?
Is it hardcoded, that it will always send to BRK_REPLY_IN? That's not very good.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
