| Author |
Message
|
| jsware |
 Posted: Wed Apr 16, 2008 12:31 am Post subject: Using QREMOTE/XMITQs to add routing slips to messages |
 |
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
Anybody see any problems with the following theoretical example:
Application A uses A.OUT.Q to send messages to Application B (who reads from B.INB.Q) - normal MQ intercomms to connect A.OUT.Q->B.INB.Q.
I want to intercept those messages using a generic flow (e.g. to wiretap the messages and capture a copy). Thus I do the following:
Change A.OUT.Q to deliver messages to W.INB.A.Q
W.INB.A.Q is a QREMOTE with the RQMNAME/RNAME set to B.INB.Q @ B's qmgr. It has an xmitq of W.INB.Q.
A message flow reads the W.INB.Q (which now has an XQH structure), removes this structure from the message, records it on W.TAP.B.INB.Q (prefixing the XQH.RNAME with "W.TAP." which is a queue I have set up).
The message flow then uses the XQH it removed (but remembered) to forward the message on in the same way the a receiver MCA would do with the XQH.
With this generic flow, I could intercept C.OUT.Q->D.INB.Q by redirecting it in the same manner C.OUT.Q->W.INB.C.Q(D.INB.Q@DQM/W.INB.Q) so that the same flow captures the message on W.TAP.D.INB.Q.
While it seems I am bending the use of QREMOTE/XMITQs, am I leaving myself open to some pain in the future? (The boxes are big enough that performance is not a concern - well it is but I can recommend bigger boxes  ).
I could extend this to implement "utility services" for example, an XSLT service which (somehow, not sure yet) applies an XSLT to the input message before forwarding it on to its original destination. Other possibilities are recording the messages in a database, changing the reply-to details to intercept the response to perform further processing - all sorts of things.
My basic concern was the impact of bending the use of a QREMOTE/XMITQ pair.
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
| Back to top |
|
 |
| AkankshA |
| Posted: Wed Apr 16, 2008 2:21 am Post subject: |
|
|
Grand Master
Joined: 12 Jan 2006
Posts: 1494
Location: Singapore
|
 
i am completely lost and confused.... 
may be if u can tell us the business requirement then i might be able to think a lil more...
_________________
Cheers |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Apr 16, 2008 4:32 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
No, don't read from the XMITQ, please.
You will cause more problems than you expect.
Make W.INB.A.Q a QALIAS to a local queue, or a QREMOTE to a different remote queue on the other side.
Then you can just read the message normally, audit it without transforming it and forward it to the final destination.
I understand that you're trying to use the XQH to store the "original destination", so you don't have to derive it from the message data or from a configuration somewhere. But that's really being too clever, and will end up tying you in knots when you don't expect it.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jsware |
| Posted: Wed Apr 16, 2008 7:23 am Post subject: |
|
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
| jefflowrey wrote: |
| No, don't read from the XMITQ, please. |
Why not? Its not an XMITQ used by an MCA, its a QLOCAL with the type(XMITQ) attribute (which I know is an XMITQ by any other name). Your "please" pleading implies something important you are not alluding to...
| jefflowrey wrote: |
| You will cause more problems than you expect. |
Such as?
| jefflowrey wrote: |
Make W.INB.A.Q a QALIAS to a local queue, or a QREMOTE to a different remote queue on the other side.
Then you can just read the message normally, audit it without transforming it and forward it to the final destination. |
Now I don't know what the final destination was/is so I can't forward it.
| jefflowrey wrote: |
| I understand that you're trying to use the XQH to store the "original destination", so you don't have to derive it from the message data or from a configuration somewhere. But that's really being too clever, and will end up tying you in knots when you don't expect it. |
"To clever" is a subjective term (I don't think its that clever)
How am I going to get tied up in knots (I am not a newbie)? The
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Apr 16, 2008 7:31 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I know you're not a newbie... I'm saying that *I* wouldn't try this.
I'm calling it "too clever" because it's using obscure details to get around doing things in an obvious and clearly understandable way. Therefore, it's subject to mishandling at the administrative level and by whoever maintains it.
What happens when your well-meaning MQ admin discovers that you've got a qlocal with usage(xmitq), that's being read by an application program?
What happens when a well-meaning broker developer sees that your flow is processing an XQH header, and doesn't understand how it gets there, and starts writing their code to add one - or changes your code to ignore it?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jsware |
| Posted: Wed Apr 16, 2008 7:34 am Post subject: |
|
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
| AkankshA wrote: |
| may be if u can tell us the business requirement then i might be able to think a lil more... |
Erm... I am not asking you to solve my business problems...but
| I wrote: |
| I want to intercept those messages using a generic flow (e.g. to wiretap the messages and capture a copy). |
What I means by that is I cannot change applications A and B which interact using messages. I want to "insert" an intermediary in the interaction - such as a wiretap or detour without having to build a custom flow for each interaction.
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
| Back to top |
|
|
| jsware |
| Posted: Wed Apr 16, 2008 7:44 am Post subject: |
|
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
| jefflowrey wrote: |
| it's using obscure details to get around doing things in an obvious and clearly understandable way. Therefore, it's subject to mishandling at the administrative level and by whoever maintains it. |
All your points are well taken. I am in the fortunate position of being both MQadmin & MBdev & allMQ guy. However, how else can I add a routing slip to a message if I cannot change COTS package A or COTS package B and don't want to write a separate message flow for each interaction?
| jefflowrey wrote: |
| What happens when your well-meaning MQ admin discovers that you've got a qlocal with usage(xmitq), that's being read by an application program? |
They'll know about it because I will have "trained" them in what happens.
| jefflowrey wrote: |
| What happens when a well-meaning broker developer sees that your flow is processing an XQH header, and doesn't understand how it gets there, and starts writing their code to add one - or changes your code to ignore it? |
They won't unless they don't read the program spec I am going to have to write to do this (if somebody else writes it and not me).
Having said all that, your points are well taken.
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Apr 16, 2008 8:04 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
It really depends on what you mean by a "separate flow".
A generic flow that does the auditing, can be deployed to read and write to lots of different queues - by overriding the queue names on the bar file.
Or you can add more than one MQInput to a flow, with a compute node that routes-to-label and sets the token. Does V6 set a "source queue" on the InputRoot.Properties? I thought it did... maybe not.
The other way to do this is with an API exit... something like mirrorq, only without the "mirror".
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jsware |
| Posted: Wed Apr 16, 2008 8:26 am Post subject: |
|
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
| jefflowrey wrote: |
| Does V6 set a "source queue" on the InputRoot.Properties? |
Ahh, I think it does. That's an interesting thought. I'll have a look at that too
Thanks.
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
| Back to top |
|
|
| Bill.Matthews |
| Posted: Wed Apr 16, 2008 10:52 am Post subject: |
|
|
Master
Joined: 23 Sep 2003
Posts: 232
Location: IBM (Retired)
|
I noticed that you did not specify whether or not you were using MQ Clustering ...
For a non-cluster channel, the XMIT queue is opened with exclusive control by the Sender channel - therefore, you would have to stop that channel before the broker could open the queue to process any messages.
In the mean time, you would be flooding the error log with messages resulting from the broker trying to open the queue.
_________________
Bill Matthews |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Apr 16, 2008 10:58 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| Bill.Matthews wrote: |
| the XMIT queue is opened with exclusive control by the Sender channel |
He's not planning on using an XMITQ that is tied to a channel. Just a random queue that has USAGE(XMITQ).
Which is the first thing most MQ admins would adjust if they saw it... "why is this queue an XMITQ? it's not being used by a channel. Must be a mistake... <clickety-click>".
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Apr 16, 2008 6:55 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
there are no guarantees that the next release of MQ wouldn't change the structure of the transmit q header. You could then change your flow, but its work...
If A sends to B, change A to send to C. C is read by a flow thats hardcoded to write to B ( the original) and B.Log (ur copy).
If D sends to E, change D to send to F. F is read by a flow thats hardcoded to write to E ( the original) and E.Log (ur copy).
And just repeat as many times as you need it.
In MQ 7 you will be able to as an MQ Admin change a typical one to one point to point app to a one to many pub subber with no changes to the putting or getting app at all. Very cool.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jsware |
| Posted: Wed Apr 16, 2008 11:23 pm Post subject: |
|
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
| PeterPotkay wrote: |
| there are no guarantees that the next release of MQ wouldn't change the structure of the transmit q header. You could then change your flow, but its work... |
The MQXQH structure is documented in the pgmr's ref with statements about what to do if reading an MQXQH. The MQe bridge reads the MQXQH when receiving messages from big MQ. Therefore I would say that the MQXQH is as likely to change as the other documented header structures.
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
| Back to top |
|
|
| jsware |
| Posted: Wed Apr 16, 2008 11:32 pm Post subject: |
|
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
| Bill.Matthews wrote: |
I noticed that you did not specify whether or not you were using MQ Clustering ...
For a non-cluster channel, the XMIT queue is opened with exclusive control by the Sender channel - therefore, you would have to stop that channel before the broker could open the queue to process any messages.
In the mean time, you would be flooding the error log with messages resulting from the broker trying to open the queue. |
You may misunderstand my original post. There would be no channel accessing the xmitq so no exclusive access would occur because of that. I'm not talking about using a QLOCAL with XMITQ usage as an actual transmission queue accessed by a channel.
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
| Back to top |
|
|
| jsware |
| Posted: Wed Apr 16, 2008 11:39 pm Post subject: |
|
|
Chevalier
Joined: 17 May 2001
Posts: 455
|
| PeterPotkay wrote: |
| In MQ 7 you will be able to as an MQ Admin change a typical one to one point to point app to a one to many pub subber with no changes to the putting or getting app at all. Very cool. |
Yeah, I noticed that little goodie too. It seems to me that MQv6 was about as fast as they could make it (effort to improve giving fewer performance enhancements) and they've concentrated on pushing some of the JMS topic/async readers/selector stuff down into the MQI to make it available to all and respond to improvements in other messaging systems by adding functionality.
_________________
Regards
John
The pain of low quaility far outlasts the joy of low price. |
|
| Back to top |
|
|
|
|
