| Author |
Message
|
| George Carey |
 Posted: Thu Feb 26, 2009 9:48 am Post subject: JMS and pub/sub |
 |
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
Along the same lines as gpkplos post but thought I would start a separate topic ... I am seeing I need to get more heavily into pub/sub and JMS functionality and options ... but of course limited time ... so just need at this point to know if following is
1.) doable (standard stuff or not)
2.) JMS programming task
3.) MQ Admin task
4.) Where best to read first
The following: Need to have publishing JMS application (in an app server) publish to multiple destinations, so one plublished message lands on multiple destination queues (two or more) where the consuming applications are legacy MQ applications .... not doing topic subscription registering, one uses JMS and one does not but neither can be changed. They just want to read a queue as they have done before.
New applications may be added that will do normal JMS topic subscription registration. But current do not.
a.) Can the legacy apps recieve the published messages without doing a subscription for it? (which apply 1,2, 3 and then of course 4)
b.) With QMGR topology: publisher on QMGR A and two legacy MQ consuming applications on QMGR B and C respectively ... Question a.) again ? (in other words a broker hierarchy needs to be setup)
c.) Know of any example documentation that is close that could be read to give insight on how to setup.
JMS coders are thinking at this time that all they have to do is do JMS Topic publication and having the messages land on multiple destinations on remote QMGRS is an MQ Admin task. I thought a topic subscription had to be registered by an application subscriber to receive topic publications. But not certain .... this is all MQ v6.x not MQ v7.x and no other IBM software but MQ.
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Thu Feb 26, 2009 10:14 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Programs are not registered as subscribers, not really. Queues are.
You can manually create a subscription for both of your two applications. For base v6 Pub/Sub this can be done with RFHUTIL, for Broker v6/6.1 pub/sub this can be done in the Toolkit. |
|
| Back to top |
|
|
| George Carey |
| Posted: Thu Feb 26, 2009 1:27 pm Post subject: subscriptions |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
In WSMQ v6.x can one create a subscription for a topic with an admin tool for the legacy applications ... say a durable subscription so that messages when published on that topic land on the designated queues for them to consume. Without them having to do the subscription registration.
This can be done with RFHUTIL or can this be done in some other way?
The bottom line, however, a subscription on the topic being published must be registered before any messages will land on the destination/target queues, Correct ???
Remember no other IBM software but WSMQ. Also not using Windows, just Unix platforms. And publisher application is using JMS.
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Feb 26, 2009 1:44 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Subscriptions are created, no matter who creates them or when, by putting a RegSub message on the Pub Sub command queue.
RFHUtil makes it simple to create a RegSub message - but RFHUtil is Windows Only.
The destination of a subscription is a queue, not an application.
There is not anything that I am particularly aware of that says that a destination has to be a QLOCAL on the queue manager running the pub/sub engine.
Messages published on a topic are distributed to every subscription that has a matching topic string. If there are zero matching subscriptions, the message is published to nowhere (the blog model).
The registration of a queue in a subscription puts no additional control on the queue. Messages from any application that has permission may still directly or indirectly put messages to that queue.
So it is not correct to say that "a subscription on the topic being published must be registered before any messages will land on the destination/target queues". The only thing that will not put messages to any queues without a registered subscription is the pubsub broker process. |
|
| Back to top |
|
|
| George Carey |
| Posted: Thu Feb 26, 2009 2:34 pm Post subject: pubsub broker process indeed |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
That is all I am talking about on the publisher side is Broker pub/sub using JMS no base MQ pub/sub APIs.
A rude awakening for me (I believe) is there no such thing as a 'topic string' in JMS !! That is only base MQ pub/sub. JMS uses topic 'selectors' in the header ... different concept !!!!! Aaaargghh!!!
Searching IBM Pub/Sub manual for 'JMS' finds NOTHING!!! Great HELP!!!
My questions are really JMS questions ...
... and also how to do JNDI JMS topic definitions and how to map to queues in JMSAdmin tool not using the MQ Explorer tool ... looking for examples.
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| George Carey |
| Posted: Thu Feb 26, 2009 3:04 pm Post subject: wrong again |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
Looks like I may be incorrect on that ... good !!
IBM JAVA manual talks about JMS Topic strings like /SPORTS/SOCCER/* and the like so I guess that is cool in base MQ pub/sub and JMS Pub/sub just need to see where this is all defined. An JMS Message selectors are different animals that can be used to filter publications.
Aaarggh Aaaargh !!!
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Feb 26, 2009 9:38 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Please be aware that the WMB manual has also a section for pub/sub.
You need to set the pub/sub version on the tcf to distinguish between the 2 and the wildcards for topics are different between the 2.
Use JMSAdmin in 2 different ways.
First define the topic -- simple define
Second display the topic using ALL -- see all options available
Third ALTER the topic to take advantage of the options
Last but not least you may need to do a little programing to display the topic in a JMS program. This will show you the correct URI format for the topic with the options.
Finally keep in mind that messages are published with the RFH header.
So if you do not want to do some fancy programming to remove it in the legacy app you may want to front the app with a tiny JMS/XMS program that receives from QA and sends to QB where QB is defined as "queue://QMGR/QB?targetClient=1" to specify to strip the RFH header from the message. Remember to keep the session transactional and to commit often.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| George Carey |
| Posted: Fri Feb 27, 2009 9:02 am Post subject: JMS - ETC and XAQCF, QCF transport settings |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
Good input thanks ... where/what is full name of WMB manual .. I need to read JMS section.
Looking a IBM JAVA JMS manual and sample JMS IVT .mqsc files I see shared durable queue definitions and shared durable connection consumer queue definitions ... puzzled on what is the difference at this point ...
Also, on the unique CLIENTID of durable subscription so that a restarted subscriber app can consume the published messages waiting on the consumer queue ... is this not externally known say in some JNDI definition for CF or Topic ... how else does a failed subscriber app know what CLIENTID is to avoid stranded publication ... without hard coding in code which I assume is not done. ...
likely missing ... some concept here
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| George Carey |
| Posted: Fri Feb 27, 2009 2:48 pm Post subject: .bindings |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
Had a programmer send me his test .bindings file built from GUI on windows box that was working functionally how he wanted it ...
That cleared a few things up. ... Used the JMSAdmin tool to 'display t(*)' , etc to see what they had in them.
He thought messages were landing on queues that he had created ... I showed him how they were not and were actually using the SYSTEM.JMS.D.XXX queue names to route the published messages to the various subscribers ...
He wasn't convinced until I told him to delete his local queues and the pub/sub functions still worked (he had to reboot his app server containers to be sure!)
We even got some wildcard topic subscriptions working ... Which brings up ...
Any opinions on which way to go is best ... using Message Selectors or different topics with possible wildcards ... (wild cards I believe IBM only)
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Feb 28, 2009 3:43 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Quote: |
| Any opinions on which way to go is best ... using Message Selectors or different topics with possible wildcards ... (wild cards I believe IBM only) |
Well the question really calls for analysis. If you don't care about the topic, all you have to do is consume correctly according to topic any message delivered to your subscription queue you could use a QueueConsumer. It will show the Destination as having been a topic. The topic it was published on.
I am very much in favor of this approach for durable subscriptions.
It does not require you to know anything about the subscription not even the unique name it was made under... It does not need to do any filtering using a selector or any other mechanism that can be time consuming and performance costly.
Remember if you use a wildcard subscription for a topic, that your downstream programs will have to be able to process accordingly. Look at it like a queue where you have commingled message types. The next message (topic) will arrive but you have no idea what its type is and you have to process according to type. Well the topic is part of the destination on the message so that will help.
Wildcard topics are great for subscriptions to multiple topics in a common topic string or area of interest. They make admin easier. Processing them is still the receiver's responsibility and you will need logic for it.
Using filters and message selectors for splitting topics on a subscription are counterproductive for performance and will not give you the desired effect (this is my opinion only). Have your subscriptions all delivered to your own particular delivery queue, use a simple routing mdb and then use a queue per topic if you must. This makes the subscription management easier, and allows you for specific processing by topic difference. Be prepared to have an unknown bucket and keep the topic name in a user folder when you move messages to that queue.
Like I said I am not at all adverse at having a subscription delivered to your own queue and consumed by a QueueConsumer instead of a TopicConsumer. Have fun.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| George Carey |
| Posted: Sat Feb 28, 2009 3:59 pm Post subject: queue consumer |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
| Quote: |
| ...If you don't care about the topic, all you have to do is consume correctly according to topic any message delivered to your subscription queue you could use a QueueConsumer. ...it does not require you to know anything about the subscription not even the unique name it was made under... |
Yes, that looks like the ticket for me ... a publication to topic destinations that goes to individual subscriber queues and consumed by a QueueConsumer ...ignorant or agnostic of topics. I will have to read up on admin and programming implementation details of this ...
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| George Carey |
| Posted: Tue Mar 03, 2009 3:12 pm Post subject: QueueReciever and Registered subscriptions |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
| Quote: |
| ...you could use a QueueConsumer.... |
I assume you mean a QueueReceiver a sub-interface of MessageConsumer along with TopicSubscriber.
In MQ V7 I can just like a queue, create topics and subscriptions.
However, in JMS the only administered objects(as I read it) are ConnectionFactory(s) and Destinations(Queue or Topic). In MQ V7 very nice/simple interface to pre-create a durable subscription where I can provide a destination with a Destination class of 'Provided' and an associated QMGR and Destination name of a queue. Published messages land very nicely on this configured queue.
One problem, I need to use MQ V6 and no GUI.
How does one do this in MQ v6 ... does the RFHUTIL utility program have to be used or are there other options. And what object is created ... apparently not an administered object ... that can be put into a JNDI .bindings file like a Topic.
Is it(the pre-created subscription) just an MQ Broker control message held in its store??
Regards
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Mar 03, 2009 8:26 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
The subscription topic can be created using JMSAdmin.
Remember the queue name rules.
You can alternatively also use topic uris ("topic://topicstring?attr=value").
This also allows you to pass the subscription queue information.
RFHUtil can be your guide to programming. I used an alias for the broker control queue on a non broker qmgr to inspect the message created (by RFHUtil) using JMS programming. Pretending this is a broker qmgr you can use JMS to create your subscription and verify the content of the message (using RFHUtil) until you get it right... Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| George Carey |
| Posted: Wed Mar 04, 2009 8:05 am Post subject: Durable subscriptions registering |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
From some IBM documentation
| Quote: |
Broker durable subscription queue
The name of the broker's queue from which durable subscription messages are retrieved. The subscriber specifies the name of the queue when it registers a subscription ... |
Still trying to understand the best way to 'register a subscription' for MQ V6 as a proxy to an external legacy application that will not be doing any JMS Pub/Sub api's.
1.)Does a program need to be written to register a subscription specifying a destination queue for the messages, that the legacy app can then read, or
2.)Is there an Administerable object that can be created and placed into a JNDI .bindings file (a TopicSubscription if you will ... I don't think so here)
3.)Is there a utility for MQV6 that will register a subscription (as there is in MQ v7, is this only RFHUtil for MQ v6 ?)
4.)What is best way in MQV6 to (proxy) register a subscription ?
Likely, again I am missing something.
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Mar 04, 2009 2:52 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Use RFHUtil to proxy the subscription.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
