| Author |
Message
|
| gpklos |
 Posted: Thu Feb 19, 2009 8:33 pm Post subject: JMS PUB SUB Help. |
 |
|
Centurion
Joined: 24 May 2002
Posts: 108
|
Hopefully this is the correct forum for the MQ PUB SUB feature.
I've been asked to setup PUB SUB on MQ version 6.0 using the broker that comes with MQ 6.0. They
are going to be using JMS to work with PUB SUB. I've been trying to go through the various documents and
find myself getting confused. I've done MQ for several years but no pub sub stuff.
When setting up the the broker to be used with JMS, it created numerous SYSTEM.JMS.* queues. Also when the
broker was started it created SYSTEM.BROKER.CONTROL.QUEUE and SYSTEM.BROKER.DEFAULT.STREAM.
So here are my questions related to JMS and pubsub.
1. Can a publisher use another queue to publish to instead of the SYSTEM.BROKER.DEFAULT.STREAM? My guess is yes because it says
you can with the regular MQ API coding, but I want to make sure you can when coding in JMS.
2. Now typically our installation doesn't allow access to SYSTEM.* queues (in general). Can we create an alias to the
SYSTEM.BROKER.CONTROL.QUEUE, so that we can give it a different name, but the messages still end up on the
SYSTEM.BROKER.CONTROL.QUEUE.
3. Of the various SYSTEM.JMS queues created below, are we allowed to make our own with our own naming standards in JMS? This
way different applications can each have their own set of JMS queues. OR if you can't create new ones can we have aliases point
to these queues? Does a JNDI allow the applications to have their own names which point to these SYSTEM queues?
SYSTEM.JMS.ADMIN.QUEUE
SYSTEM.JMS.PS.STATUS.QUEUE
SYSTEM.JMS.REPORT.QUEUE
SYSTEM.JMS.MODEL.QUEUE
SYSTEM.JMS.ND.SUBSCRIBER.QUEUE
SYSTEM.JMS.ND.CC.SUBSCRIBER.QUEUE
SYSTEM.JMS.D.SUBSCRIBER.QUEUE
SYSTEM.JMS.D.CC.SUBSCRIBER.QUEUE:
4. Of the SYSTEM.JMS, what type of security should be given to these queues? ie. browse, get, put, etc. Security is very
tough about giving complete access to all these queues. That is why we like to use aliases, so that security is
given to the aliases and never really the base queue.
5. What security needs to be given to the SYSTEM.BROKER.CONTROL.QUEUE.
Thanks for your help,
Gary |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Fri Feb 20, 2009 5:17 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
As for the default stream queue you could only grant put and inq. That should do for publishing. For the subscribers you will still need to grant system.broker.control.queue put and inq.
Any other queue for receiving the published messages should be aliased and have a different name :
DEF QA(SYSTEM.JMS.D.MYAPP) TARGET(MYAPP.MYSUBSCRIPTIONS).
This way security should have no compunction giving you access to SYSTEM.JMS.D.MYAPP*.
Of course in your subscriber topic you need to specify where the subscribed messages are to be delivered to...
Have fun. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| gpklos |
| Posted: Mon Feb 23, 2009 8:19 am Post subject: |
|
|
Centurion
Joined: 24 May 2002
Posts: 108
|
<<Any other queue for receiving the published messages should be aliased and have a different name : DEF QA(SYSTEM.JMS.D.MYAPP) TARGET(MYAPP.MYSUBSCRIPTIONS).
<<This way security should have no compunction giving you access to SYSTEM.JMS.D.MYAPP*.
Are you saying that any queue alias that receives published messages has to at least begin with SYSTEM.JMS.D.* or SYSTEM.JMS.ND.*?
Which will be an alias to some other queue name that doesn't have to start with SYSTEM.JMS.*?? Because I was thinking of having a stream queue named JR.ERP_STREAM.PUTQ and have a subscriber queue named JR.ERP_SUBSCRIBER.GETQ, which is an alias for JR.ERP_SUBSCRIBER.LQ. So the physical messages would end up on the JR.ERP_SUBSCRIBER.LQ for the subscribers to get from.
I just think it is odd that MQ would force users to have application queues that begin with SYSTEM.
Plus they seem to have different rules for durable vs Non-durable and multiple queues versus shared queues.
This is getting confusing.
Gary |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Feb 23, 2009 8:26 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Look it up it's all in the manual. Even the fact that the queue has to start with SYSTEM.JMS etc...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| gpklos |
| Posted: Tue Feb 24, 2009 8:37 am Post subject: |
|
|
Centurion
Joined: 24 May 2002
Posts: 108
|
Thanks for your quick response. I'm going to have to create some examples to verify things for myself.
Gary  |
|
| Back to top |
|
|
| cronydude |
| Posted: Fri Apr 09, 2010 12:37 pm Post subject: |
|
|
Voyager
Joined: 11 Nov 2001
Posts: 85
Location: US
|
Gary,
I am exactly in your situation where I am against using SYSTEM.JMS.* as subscription queues but our developers as well as IBM documentation seem to contradict my view.
One way we have achieved using custom subscription queues in the past is by creating subscriptions manually rather than letting the applications create their own subscriptions via WAS console. But developers argument is that this defeats the pub/sub model purpose.
Would you mind sharing your testing results and you ended up doing in your case ?
Appreciate your inputs and thanks in advance for your help.
_________________
Regs,
crony
IBM Certified Specialist - MQSeries |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Apr 09, 2010 8:47 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| cronydude wrote: |
Gary,
I am exactly in your situation where I am against using SYSTEM.JMS.* as subscription queues but our developers as well as IBM documentation seem to contradict my view.
One way we have achieved using custom subscription queues in the past is by creating subscriptions manually rather than letting the applications create their own subscriptions via WAS console. But developers argument is that this defeats the pub/sub model purpose.
Would you mind sharing your testing results and you ended up doing in your case ?
Appreciate your inputs and thanks in advance for your help. |
You can still use custom subscription queues... Just create the corresponding SYSTEM.JMS.* as an Alias queue.
Creating custom pub/sub queues may defeat the model purpose ... I think not... Custom pub/sub queues makes most sense when the subscription is durable. It may also make sense for a non durable subscription... However it does not break the fact that the publisher has no knowledge of the subscribers... The separation is still there... and having a queue to receive your subscriptions on may be a help when trying to figure out a problem...
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
