| Author |
Message
|
| MillsPerry |
 Posted: Thu Feb 27, 2003 2:13 pm Post subject: Best Practice: Pub/Sub vs. Destination Lists |
 |
|
Acolyte
Joined: 08 Oct 2001
Posts: 59
Location: ZyQuest, inc.
|
We need two things:
1. The ability to send messages to multiple destinations.
2. The sending application shouldn't have to change whenever a new system wants to get the message.
We have been using Pub/Sub for this, where one system publishes its messages and whoever wants the messages creates a static subscription. However, I am hearing through various conferences and consultants that this is not what pub/sub was designed to do and that most people use distribution lists.
I would like to know what the best practice is, so if your company uses multipoint messaging, can you please tell me which method you use and why?
Thanks!! |
|
| Back to top |
|
 |
| jgooch |
| Posted: Mon Mar 03, 2003 8:14 am Post subject: |
|
|
Acolyte
Joined: 29 May 2002
Posts: 63
Location: UK
|
We use distribution lists. As I understand Pub/Sub, if no one subscribes to a message, it's gone. Hence, this is no good to us.
If we get a new destination, we add its queue to the "routing" flow distribution list and re-deploy.
Seems the simplest solution. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Mar 03, 2003 8:18 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Alternately, you could create a simple database table, and populate the distribution list from that.
Then you wouldn't have to change the code to add or remove an item from the distribution list. |
|
| Back to top |
|
|
| MillsPerry |
| Posted: Mon Mar 03, 2003 12:19 pm Post subject: |
|
|
Acolyte
Joined: 08 Oct 2001
Posts: 59
Location: ZyQuest, inc.
|
| Yup! If we choose to use distribution lists, I would drive it from a table. |
|
| Back to top |
|
|
| kolban |
| Posted: Mon Mar 03, 2003 12:43 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
This sounds like exactly what Pub/Sub was designed for. There are many types of subscription that one could take and at least one of them should suffice.
Pub/Sub decouples the originator of the information from the reciever. Building your own distribution lists from table data sounds like way too much work than needed.
I would strongly suggest Pub/Sub. |
|
| Back to top |
|
|
| MillsPerry |
| Posted: Mon Mar 03, 2003 1:00 pm Post subject: |
|
|
Acolyte
Joined: 08 Oct 2001
Posts: 59
Location: ZyQuest, inc.
|
Kolban,
We are currently using Pub/Sub, but have a number of issues with it.
1. It is a black box. If it breaks (and it has), fixing it is extremely difficult.
2. We have talked to a number of consultants (from IBM and MQ Software) who have told us that Pub/Sub wasn't designed to support static subscriptions.
3. One consultant mentioned that performance & stability deteriorate when you have more than 30 subscriptions. We have twice that many and we don't like skating on thin ice.
You are a respected member of this group. Do you feel that these consultants are mistaken? |
|
| Back to top |
|
|
| kolban |
| Posted: Mon Mar 03, 2003 9:12 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
Thanks for the vote of confidence [respected group member etc etc] 
I hope I can be deserved of such.
Lets look at the multiple pub/sub implementations available:
o The free solution MA0C
o The WMQIB solution
o The WMQEB solution (high-speed JMS over IP)
Unless otherwise mentioned, I will assume MA0C.
1. Black box
I am hoping not. The MA0C pub/sub engine is documented and fully supported. If there are problems, you are entitled to open defect tickets with IBM. I would be interested to hear of problems that were difficult to fix.
2. Of all things, static subscribptions are the easiest and lease complex to manage. I would be interested in the explanation of why these folks think the product not designed to support such.
3. When a message is to be published, the broker will match the topic on the message with the subscriptions present. This will result in a subset of matching subscribers containing zero or more entries. For each of those entries, a copy of the message will be put to each. I know of no architectural nor performance limits. 30 subscribers should be nothing. I work with users who have expectations of 1000's of subscribers.
Again, I'd like the opportunity to enter into a great discussion on this topic. So I'll be watching here to see what transpires. I have just finished a large PoC on WMQEB and am all geared up to talk pub/sub in all its flavors |
|
| Back to top |
|
|
| MillsPerry |
| Posted: Tue Mar 04, 2003 10:49 am Post subject: |
|
|
Acolyte
Joined: 08 Oct 2001
Posts: 59
Location: ZyQuest, inc.
|
We are using the WMQI solution. We use message flows to publish, and a home grown application to subscribe.
When I say 'Black box', I mean that when something goes wrong, we can't tell what the problem is. Examples:
1. I register a subscription. It shows on the WMQI subscription tab, but it gets no published messages. This happens frequently enough to make us question the reliability of pub/sub.
2. I register subscriptions, but they do not show up at all in WMQI. This doesn't happen often, but even once or twice is difficult to accept.
Why do we question static subscriptions?
1. When speaking to a consultant from MQ Software about our pub/sub reliability issues, he practically shouted at us 'Do NOT use pub/sub for static subscriptions'. At first I wrote the guy off as a flake, but ...
2. We sent one of our guys to the Websphere conference in Las Vegas the other week. One of his assignments was to see how many companies used pub/sub for static subscriptions. The vast majority used them only for dynamic subscriptions.
3. We have just brought in a pair of IBM consultants to help us with some WMQI issues. One of them came as a pub/sub expert, and he told us that static subscriptions may not necessarily be a terrible thing to do, but it wasn't what pub/sub was designed for.
You are really the first person I have discussed this with who feels strongly that pub/sub is the best way to implement static subscriptions.
Maximum number of subscriptions:
The same consultant from IBM also mentioned that he had read 'somewhere' that WMQI only supports 30 subscriptions by default. I have asked him to find me a reference to that limit in a manual or redbook somewhere, but he hasn't responded yet. Other members of our team have looked for this limit and have not found it.
MQ users at my company are split over whether we should continue with pub/sub or write our own pub/sub application where systems would subscribe to a topic by writing to a table that associates topics to subscriber queues. If we go this direction, we will know that when there is a problem, we just have to fix our own application. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Mar 04, 2003 11:36 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| Quote: |
When I say 'Black box', I mean that when something goes wrong, we can't tell what the problem is. Examples:
1. I register a subscription. It shows on the WMQI subscription tab, but it gets no published messages. This happens frequently enough to make us question the reliability of pub/sub. |
If you can document this, you should file a problem ticket with IBM. It should not do that if the subscription really does match. You should also make sure you're at the latest CSD.
| Quote: |
| 2. I register subscriptions, but they do not show up at all in WMQI. This doesn't happen often, but even once or twice is difficult to accept. |
I'm only starting to play with WMQI pub/sub myself, but I've seen this happen when I create a malformed subscription request (like using uppercase when specifiying the psc folder). There's absolutely no notice to anything that a malformed subscription was attemtped and failed, as far as I'm aware. |
|
| Back to top |
|
|
| MillsPerry |
| Posted: Tue Mar 04, 2003 12:38 pm Post subject: |
|
|
Acolyte
Joined: 08 Oct 2001
Posts: 59
Location: ZyQuest, inc.
|
Thanks for your comments. I have written an application to register the subscriptions. While it could have a bug, I would expect it to either work all the time or not at all.
Currently, the prime suspect is a corrupt table in the underlying WMQI database. Unfortunately, the only way I know of to recover from this is to delete the broker and rebuild everything. |
|
| Back to top |
|
|
| kolban |
| Posted: Tue Mar 04, 2003 7:12 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
WQMI and WMQEB are most definitely IBM's story for Pub/Sub technology. If I were the designer of applications needing loose bound message distribution, I would use the Pub/Sub capabilities of these products. If you look at WMQEB, Pub/Sub is all it does (its a subset of WMQI with the option of unreliable high speed pub/sub included).
Simply, if you buy WMQEB (or WMQI) and use the Pub/Sub features, you can and should expect them to work as advertized. If they fail to achieve these goals, the IBM corp had better stand behind them and fix them sooner rather than later.
My experience has been mostly positive. The more one understands of them the better. I have no qualms recommending such.
See also the IBM Pub/Sub red-book:
Pub/Sub |
|
| Back to top |
|
|
|
|
