| Author |
Message
|
| KIT_INC |
 Posted: Fri Apr 10, 2015 9:32 pm Post subject: Can I publish to a remote Topic ? |
 |
|
Knight
Joined: 25 Aug 2006
Posts: 589
|
I am running V701 MQ.
When I use RFHUTIL to test publish to a Topic. The publish command message is going to SYSTEM.BROKER.CONTROL.QUEUE.
I want to do my publication from a different Qmgr. But there is no such thing as remote Topic (may be I am wrong). So I tried to PUT the publish command message to a remote Q pointing to the SYSTEM.BROKER.CONTROL.QUEUE on the Qmgr that has the Topic defined.
I did not get any error. But the subscriber simply do do get the publication.
Can I do it this way ? |
|
| Back to top |
|
 |
| smdavies99 |
| Posted: Fri Apr 10, 2015 11:05 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
You can do something if you write to a remote queue that points at an Alias queue on the Remote Qmgr. The alias queue can be set to write (i.e. Publish) to a topic.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Fri Apr 10, 2015 11:31 pm Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
I'm not saying that publishing to a remote topic is wrong but it is slightly against the notion of Publish/Subscribe. In Pub/Sub the idea is that the Publisher doesn't know or doesn't care who is subscribing to the data. The messaging system deals with all that. As a consequence you can add further subscribers anywhere in your network and they will also receive copies of the message. The idea that a publishers is targeting a particular remote Queue Manager seems against the paradigm.
As I said, I'm not saying it's wrong, there are times when performance or security etc may take precedence. However, it would be a shame to set up a system where you are publishing direct to QM2 only to find later that QM3 and QM4 are also interested,
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| KIT_INC |
| Posted: Sat Apr 11, 2015 7:38 am Post subject: |
|
|
Knight
Joined: 25 Aug 2006
Posts: 589
|
| Quote: |
| The alias queue can be set to write (i.e. Publish) to a topic. |
Thanks this works.
| Quote: |
| I'm not saying that publishing to a remote topic is wrong but it is slightly against the notion of Publish/Subscribe |
We have a large cluster with a weak network. So we do not want Topic to share across the entire cluster to avoid unnecessary traffic due to proxy subscriptions. The plan is have topic only in a couple of Qmgrs and every one else will just pub or sub to these couple of Qmgrs. We are at POC stages, that's why we try to PUB to 'remote Topics' |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Sat Apr 11, 2015 9:06 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
Ok, that makes sense, as I said, performance might be one of the reasons you want to do this.
Have you thought about using the 'routed pub/sub' feature in MQ V8 ? This was introduced to basically to solve this problem. You can decide where the topic is 'hosted'. Subscribers and Publishers talk to this host Queue Manager. This means that there is no need for proxy subscriptions to be generated to all corners of your cluster just the QMs involved.
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| KIT_INC |
| Posted: Sat Apr 11, 2015 12:44 pm Post subject: |
|
|
Knight
Joined: 25 Aug 2006
Posts: 589
|
| We tend to stay a little behind as you can see that we are only 701. I think our next upgrade will more than likely 7.5 and not v 8. Thanks for the adv, I will take a look at this new V8 feature |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Sat Apr 11, 2015 2:15 pm Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
Yes I noticed you were 701. I wasn't sure whether that was by design, by necessity or by budget.
Anyway, might be worth you taking a look at some of the goodies you get with V8. It seems a shame to compromise application architecture if MQ has a solution built in.
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| KIT_INC |
| Posted: Mon Apr 13, 2015 6:27 am Post subject: |
|
|
Knight
Joined: 25 Aug 2006
Posts: 589
|
| Quote: |
| It seems a shame to compromise application architecture if MQ has a solution built in. |
Paul, that's a good point. I'll try to push for V8 in our upgrade discussion. With the POC results, we probably will have a stronger reason.
Now, I have another question regarding subscription. My pub to remote Topic is resolved using remote Q which alias to the Topic. But subscription is using the MQSUB verb which using Topic name or String and no Qname.
I know that I probably can perform administrative subscription (i.e. using explorer or MQSC) on the Topic owning Qmgr. But the preference is doing it using application.
Yes, I still can have the application client connect to the Topic owning Qmgr. But a server to server connection is preferred.
How can I subscribe using program to a remote Topic ? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Apr 13, 2015 6:36 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
A topic is not really local or remote. It's a local in a tree - the whole topic tree, starting at either "/" or not.
An MQ Topic object is a point of control - allowing you to set access and shortcut paths being used within other MQ objects (or applications).
A subscription is either created as an administrative object or it is created by an application.
If you want a subscription to receive messages published to a remote queue manager, you need to configure the MQ network to allow that.
If you want publications to go to subscribers made on remote queue managers, you need to configure the MQ network to allow *that*.
If you want to limit the amount of traffic that crosses your queue manager server-to-server channels, you can use various ways to ensure that a single message is sent across a channel, rather than one message for each subscriber on the remote side.
I encourage you to review the panels and materials presented by Chris Frank at the MQTC. |
|
| Back to top |
|
|
|
|
