| Author |
Message
|
| bruce2359 |
 Posted: Tue Nov 20, 2007 4:55 pm Post subject: |
 |
|
Guest
|
| Quote: |
| We have a client that sends data to us. However they do not have authority to initiate a session (because of firewall rules in place). So we chose to use the svr-rqstr, with client being server. |
Please clear up a little more confusion.
Which end of the channel is inside the firewall? Requester or Server?
If I had to guess, I'd guess that from inside the firewall you can start your server end of the channel; but the requester, outside the firewall, can not. If this is what's happening, it's definitely a firewall issue and must be resolved by the firewall folks. This is not an MQ issue.
Are you saying that your clients application has successfully sent messages; but now fails when you changed channel pairs to requester-server? |
|
| Back to top |
|
 |
| rparti |
| Posted: Tue Nov 20, 2007 6:01 pm Post subject: |
|
|
Voyager
Joined: 05 Oct 2005
Posts: 86
Location: U.S.A.
|
| Quote: |
| Which end of the channel is inside the firewall? Requester or Server? |
The client is an external business. They have their own firewall and we have our own firewall.
Consider this scenario ( we are company A in this example). Please note that the project scope is wider than mentioned below. I am only mentioning relevant information.
Company A - receives data from company B
Company B - sends data to company A
Svr Channel - Defined at company B
Rqstr Channel - Defined at company A
Company B cannot initiate session, because company A's policies prevent that.
Requirement
Need a triggered svr-rqstr channel, so when data is available in xmit queue related to svr channel (hosted in Company B), the channel starts running if it is not already running. But again company B cannot start session.
How would you do this? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Nov 20, 2007 6:11 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| rparti wrote: |
| How would you do this? |
I wouldn't.
I would remind Company A that it was their choice to use a server/requester pair, and therfore their choice to take complete control for when messages were delivered to them.
If their business requirements say that they need to receive messages from me as soon as available, then I would move them to a sender/receiver pair. Or at least a server/receiver pair.
The only reason for using a requester channel is to pass the buck on when the channel starts from the sender side to the other side.
Your architecture conflicts with your requirements.
Something's gotta give.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| rparti |
| Posted: Wed Nov 21, 2007 1:02 pm Post subject: |
|
|
Voyager
Joined: 05 Oct 2005
Posts: 86
Location: U.S.A.
|
| jefflowrey wrote: |
Your architecture conflicts with your requirements.
Something's gotta give. |
I beg to differ Jeff.
If I connect to abc.com on http, I want data back from them only when I request it. I do not want abc.com sending data to be if they choose to.
Like I said in my earlier post, I am mentioning only relavent information and not the entire project scope.
Continuing with the previous scenario
Company A actually sends data to Company B through a sdr-rcvr channel. This is a triggered channel and is working like expected. COD replies with payload come back from company B to company A. This is currently through the svr-rqstr channel, because of company policy (and rightly so) of the client not being able to initiate a session with us.
I am looking for a solution to have the svr-rqstr also as a triggerd channel instead of keeping the channel alive all the time. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Nov 21, 2007 1:30 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| rparti wrote: |
If I connect to abc.com on http, I want data back from them only when I request it. I do not want abc.com sending data to be if they choose to.
Like I said in my earlier post, I am mentioning only relavent information and not the entire project scope.
Continuing with the previous scenario
Company A actually sends data to Company B through a sdr-rcvr channel. This is a triggered channel and is working like expected. COD replies with payload come back from company B to company A. This is currently through the svr-rqstr channel, because of company policy (and rightly so) of the client not being able to initiate a session with us.
I am looking for a solution to have the svr-rqstr also as a triggerd channel instead of keeping the channel alive all the time. |
So How about this scenario:
You send a msg from A to B and commit
Xmitq is triggered and the msg gets to B
You send a pcf msg to start the requester chl on A (direction B to A) and commit
And you pick up your answer....
Enjoy 
_________________
MQ & Broker admin
Last edited by fjb_saper on Wed Nov 21, 2007 1:44 pm; edited 1 time in total |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Nov 21, 2007 1:34 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| rparti wrote: |
| If I connect to abc.com on http, I want data back from them only when I request it. I do not want abc.com sending data to be if they choose to. |
Moving to the abstract (and not directly connected to the issue under discussion) one of the principle differences between http and MQ is the decoupling of sender and receiver. There are cases where there is value in abc.com sending unsolicited information.
| rparti wrote: |
| This is currently through the svr-rqstr channel, because of company policy (and rightly so) of the client not being able to initiate a session with us. |
Again in the abstract many companies find value in clients being able to initiate sessions with them. Not in every case clearly, but it does have it's advantages and there are plenty of ways such communication can be secured and monitored.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Nov 21, 2007 1:42 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
To add to Vitor's value here:
A requester channel does not protect you from the other side sending unwanted messages (or malignant ones). They just stay in the xmitq and you WILL get them when you start the requester channel...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| rparti |
| Posted: Wed Nov 21, 2007 2:12 pm Post subject: |
|
|
Voyager
Joined: 05 Oct 2005
Posts: 86
Location: U.S.A.
|
I agree with both of you guys, and may I say that I proposed part of the "abstract" to management and they did not agree. I was in favor of a sdr-rcvr in the first place, for the COD's
And to take care of the malignant messages, we have filtering mechanisms in place to ignore them.
Good points. Thanks.
In conclusion though, I think we all agree (since no one has come up with a solution) that there is no way to set up a svr-rqstr triggered channel. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Nov 21, 2007 2:51 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| rparti wrote: |
| In conclusion though, I think we all agree (since no one has come up with a solution) that there is no way to set up a svr-rqstr triggered channel. |
No, we are all saying that you can trigger a svr-rqstr, but from the sending side only.
I suppose you could do something silly* like write a script that starts up that svr-rqstr from B.to.A everytime you trigger your A.to.B sndr-rcvr, on the assumption that if you are sending something to them you expect a COD almost immediatly.
*I say silly because its still not clear what the big deal is for the B.to.A channel to be a plain old sndr-rcvr. Who cares if they initiate that connection? They got some info for you and you want that info!
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| David.Partridge |
| Posted: Fri Nov 23, 2007 6:13 am Post subject: |
|
|
Master
Joined: 28 Jun 2001
Posts: 249
|
I'm wondering if what the OP wants is the ability to have a sender channel that can be triggered at QM A, and a rqstr at QM B
This would allow the sdr to be started by triggering at QM A, or for a person at QM B to issue a start to the rqstr channel to cause the sdr to be started at the other end (even if it's in stopped state I think).
_________________
Cheers,
David C. Partridge |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Nov 24, 2007 6:04 pm Post subject: |
|
|
Guest
|
| Quote: |
| In conclusion though, I think we all agree (since no one has come up with a solution) that there is no way to set up a svr-rqstr triggered channel. |
As you've discovered, we don't agree.
In summary:
MQ supports triggering (meaning a message arrives in a queue) for applications and channels.
For applications, a message arrives in an application queue, and a program is started.
For channels, a message arrives in a transmission queue, and the channel named in the transmission queue definition is started.
MQ only supports triggered channels from the Sender and Server end of channels - where transmission queues exist.
A channel may be started at the Server/Sender end, or at the requester end. If at the requester end, there is no transmisison queue. Therefore, the requester end of the channel can not be triggered - using MQs definition of triggered.
It seems to me that you are asking for something called triggering that is not the MQ kind of triggering.
You have been offered other methods of starting a requester end of a channel, if that is what you require.
The Intercommunications manual covers the finite set of channel pairs that you may pick from. Keep in mind the MQ definition of triggering as you read. |
|
| Back to top |
|
|
|
|
