| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Require pub/sub-like consumption from a legacy p2p setup |
« View previous topic :: View next topic » |
| Author |
Message
|
| rizzo |
 Posted: Tue Oct 23, 2007 3:16 pm Post subject: Require pub/sub-like consumption from a legacy p2p setup |
 |
|
Novice
Joined: 02 Aug 2005
Posts: 14
|
Hello,
I am pretty new to WMQ and was wondering if anyone could help me with the following problem.
At our site we have two legacy systems using WMQ 5.3 in p2p fashion, the producer system, A, putting messages into a queue from which the consumer system, B, reads them. (No response message is sent back to system A). We would like to add a second consumer system, C, to read the same messages that system B reads, effectively requiring a pub/sub topology. Unfortunately we can't change the MQ client code of the existing systems to adapt it to pub/sub.
Could anyone tell me if WMQ offers a way in which a second consumer can be added to also receive the messages without having to change the existing systems. I.e. so that the new consumer, C, transparently reads the messages that B reads but without B knowing about it?
Could a user exit be used to read the message contents after the PUT is performed and write a copy of it into a new, separate queue from which the the new consumer system reads it? Or is this not possible in (or indeed the intended use of) user exits?
I appreciate any help you can offer.
Regards
Steve |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Tue Oct 23, 2007 4:28 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Do both B and C need to read the same message, or do they need to share the workload - i.e, B reads one message, C reads another?
If they both need to read the same message, you can use the sample program "mirrorq" as a starting point for your own solution - understanding that it's completely unsupported - but so is v5.3, at that.
If they can read different messages, then just point them both at the same queue and cross your fingers that they don't interfere with each other (perhaps because of MQOO_INPUT_EXCLUSIVE, or other similar issues).
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| rizzo |
| Posted: Wed Oct 24, 2007 5:24 am Post subject: |
|
|
Novice
Joined: 02 Aug 2005
Posts: 14
|
Hello,
Thank you for your quick reply. B and C need to read the same message, they are not sharing the workload.
Thanks for the pointer to the mirrorq sample. It looks like it could be a solution for us.
Regards
Steve |
|
| Back to top |
|
|
| rizzo |
| Posted: Fri Nov 09, 2007 4:38 pm Post subject: |
|
|
Novice
Joined: 02 Aug 2005
Posts: 14
|
Hello,
The mirrorq sample program seems to require that the original client doing the GETs (system B, above) is changed to read from the new queue written to by the trigger application.
This means changing the queue configuration of system B which we hoped to avoid. I had hoped that the triggered application could read all the messages transparently (including their content, not just notification of their presence) but the Application Programming Guide states that the queue manager treats triggered applications like any other clients, so if the triggered application has to do a GET in order to read the message contents, system B won't get that message and likewise the trigger application won't get messages that system B consumes.
Originally, I thought maybe the triggered application could just do a BROWSE, copy the data to the new queue, leaving the original message to be consumed by B but there is no way to influence the order in which the clients read messages that I know of.
Does anybody know of a solution which can achieve this? If not, we will have to see if we can change the queue definition of system B to read from the so called "staging" queue filled by the trigger app.
Thanks very much for your help.
Steve |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Nov 09, 2007 4:46 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Does B read from the exact same local q that A puts to? Or does A put to an Alias / remote q def that points to the q that B reads from?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Sat Nov 10, 2007 4:04 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Your three choices for this are a) pub/sub, b) some kind of exit, similar to mirrorq, c) change both programs to use BROWSE.
In all cases, you will have to make at least some changes to either A or B - to ensure that whatever messages are supposed to be read by A are not consumed by B.
I think, however, you should really re-examine the entire process.
There's also quite a lot that can be done if the queue names that A, B, and C use are externally configurable - rather than hardcoded into the app. This is what Peter is suggesting...
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| ashoon |
| Posted: Sat Nov 10, 2007 5:56 am Post subject: |
|
|
Master
Joined: 26 Oct 2004
Posts: 235
|
another option is to create a new program that takes one message and writes it to two queues... think of it like a 'broker'... like mirror q but not an exit...
you can make this change transparent to the applications as well using queue alias'...
_________________
IBM Certified - SOA Solution Designer & WebSphere Datapower SOA Appliances |
|
| Back to top |
|
|
| bower5932 |
| Posted: Sat Nov 10, 2007 11:09 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
| jefflowrey wrote: |
| I think, however, you should really re-examine the entire process. |
I agree on this. What are you going to do when application D comes along and wants a copy (or almost a copy) of the same message? |
|
| Back to top |
|
|
| rizzo |
| Posted: Tue Nov 13, 2007 4:42 pm Post subject: |
|
|
Novice
Joined: 02 Aug 2005
Posts: 14
|
Hello,
After checking our queue definitions I found that A and B do write to/read from the same local queue but they do it via (different) queue aliases.
As a short term solution, this will allow me to implement the mirror queue by adding the trigger to the original business queue and duplicate the message via a distribution list. I can re-map the queue alias used by system B so that it gets its messages from one of the mirror queues and the new system can get its messages from the other.
I say short term because, as you mention, once we get into the situation where multiple clients start consuming the same message, we really need to think about a pub/sub topology. This would suit our business processes better and be more flexible, especially when it comes to the "what about when system D comes along..." problem.
Once again thanks for all your feedback.
Regards
Steve |
|
| 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
|
|
|
|
