| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| With Read/Write messaging, Sender/Receiver Channel required? |
« View previous topic :: View next topic » |
| Author |
Message
|
| spasco |
 Posted: Fri Aug 01, 2003 4:08 pm Post subject: With Read/Write messaging, Sender/Receiver Channel required? |
 |
|
Newbie
Joined: 23 Jul 2003
Posts: 4
Location: North Hollywood
|
We currently employ the MQSeries sender/receiver channel paradigm. Division A (Div.A) has an MQSeries environment and Division B (Div.B) has their own separate MQ environment. Each are setup to send and receive messages via Remote/Local Queues and Sender/Receiver channels. One example of how they communicate is by Div.A sending Div.B a message by Remote Queue (Div.A) > Sender Channel (Div.A) > Receiver Channel (Div.B) > Local Queue (Div.B). Div.B would send Div.A a message following the same process. What would be the disadvantage if say Div.A were to just directly connect to Div.B's local queues to extract and write message? In other words, the extract process in both environments would just pull messages off a local queue in the other environment. This approach would eliminate the need for Remote Queues and Sender/Receiver channels currently in both environments. Sending a response message from either side would also be simplified via the SVR CONN CHANNEL. This eliminates the need for Sender/Receiver channels and Remote Queues in both environments. Is this OK?
Thank you,
Stephen Pasco |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Fri Aug 01, 2003 7:09 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
While this would work, it introduces the fact that both queue managers on both sides need to be available at all times.
With remote queues and SNDR/RCVR channels, DivA can send a message to DivB, even if the DivB server is off. (They would just queue up in the XMIT queue while the SNDR channel was retrying.)
Using SRVCONN channels means DivB would have to have its server and queue manager up to recieve messages are allow messages to be gotten.
Note that the applications on either side can still be down, so you still do benifit from MQ's asynchronous nature. just not as much as possible.
You do get the benifit of less MQ infrastructure as you have noted. If this design otherwise meets your critria, go for it.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| spasco |
| Posted: Sun Aug 03, 2003 2:40 am Post subject: |
|
|
Newbie
Joined: 23 Jul 2003
Posts: 4
Location: North Hollywood
|
Thanks Peter.
I've left out clustering. We've also implemented Queue Manager clustering across several machines on both ends (Div.A and Div.B).
Thanks for the help,
Stephen |
|
| 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
|
|
|
|
