Author |
Message
|
PeterPotkay |
Posted: Fri Jul 15, 2005 5:39 am Post subject: Pub Sub on the Brokers |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Couple of quick questions...I gotta run to a meeting and am not sure on these, even though I looked at the Intro to Pub Sub doc:
Assume WB-IMB is my Broker
1. I assume subcribers can send a Subscription request from anywhere in my network, provided they know the destination q and QM to send the sub request to. But what about receiving the subscriptions? Do I have to allow all my subscribers to connect directly to my brokers to get their info? (I do NOT want to go there) Or can a subscriber send in a "Reply" queue in their sub request, so the publisher can send the publication anywhere in my MQ network?
2. Publications and subscriptions are queue based. So if a client wants this functionality, they have to be MQ enabled?
3. As soon as the app says they need a reply for these publications, this disqualifies it as a Pub Sub app, right? Now they become a typical Req / Reply app? _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
jefflowrey |
Posted: Fri Jul 15, 2005 6:07 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
There's an entire "Using Pub/Sub Manual" these days, and some good stuff in the WBIMB Info Center.
1. Subscribers can register any queue for subscriptions that the broker can put to. The queue that subscribers register is SET by the ReplyToQ/ReplyToQmgr of the subscription request.
2. There is also, with WBIMB, "Real Time Transport", which is JMS over RMI or something. Pub/Sub can be conducted over this Transport.
3. A publisher should be entirely independant of it's subscribers. This does not mean that a single application can not be both a publisher and a subscriber. It is not necessarily a bad design pattern to publish requests for services and subscribe to replies. But the important thing is to maintain the logical separation between publishers and subscribers. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Fri Jul 15, 2005 6:18 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Quote: |
There's an entire "Using Pub/Sub Manual" these days, and some good stuff in the WBIMB Info Center.
|
Never noticed that one, always ignored it because we had no need for it. Thanks Jeff, it is printing as we speak.
Quote: |
1. Subscribers can register any queue for subscriptions that the broker can put to. The queue that subscribers register is SET by the ReplyToQ/ReplyToQmgr of the subscription request.
|
Well that makes me feel better. Subscribers can connect to QM1, and put to a remote q def that aims at the subscription q that is inside my MQ cluster of brokers. They will specify a particular reply to q, and the reply to QM will be QM1, and as valid publications are produced by any of my brokers, the publication will make its way back to QM1. Cool.
Time to go Read That FINE Manual! _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
malammik |
Posted: Fri Jul 15, 2005 7:26 am Post subject: |
|
|
 Partisan
Joined: 27 Jan 2005 Posts: 397 Location: Philadelphia, PA
|
|
Back to top |
|
 |
wschutz |
Posted: Fri Jul 15, 2005 7:34 am Post subject: |
|
|
 Jedi Knight
Joined: 02 Jun 2005 Posts: 3316 Location: IBM (retired)
|
and Peter... while reading that fine manual, also make sure to read about broker collectives (not related to Borg)  _________________ -wayne |
|
Back to top |
|
 |
PeterPotkay |
Posted: Fri Jul 15, 2005 8:23 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
hmmm, came back from the meeting, and they are hot on the concept of using http SOAP headers as the publishers, and having the WB-IMB brokers shoot out http with SOAP headers to all the subscribers. That this is a feature of WB-IMB 6.0. They envision all the pub sub happening without MQ queueing from the apps perspective, straight http.
Possible? Good idea?
If possible, would it make sense to create a new dedicated broker to handle this type of activity?
(Moderator, this is turning into a WB-IMB discussion, can you move it please?) _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
bower5932 |
Posted: Fri Jul 15, 2005 10:10 am Post subject: |
|
|
 Jedi Knight
Joined: 27 Aug 2001 Posts: 3023 Location: Dallas, TX, USA
|
I wouldn't have used the word 'http' for what you are describing. I would have said realtime transport for JMS subscribers. They register a non-durable subscription and the broker sends them messages directly without any queues involved. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Fri Jul 15, 2005 1:57 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
But the apps in question may or may not be JMS apps. These non JMS apps I suppose would be a pure http/SOAP play? _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
PeterPotkay |
Posted: Thu Aug 04, 2005 7:01 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Could someone confirm or deny that Pub Sub can happen thru WB-IMB without using MQ messages or the MQ Real Time transport for the Publishers or the Subscribers?
The publsihers and subscribers would be .NET apps with http interfaces. The Pub/Sub flow can have an HTTP inpute node and the subscriptions can go out via http as well? Wasn't 100% sure looking in the manual if this was possible. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
jefflowrey |
Posted: Thu Aug 04, 2005 8:06 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
PeterPotkay wrote: |
The publsihers and subscribers would be .NET apps with http interfaces. The Pub/Sub flow can have an HTTP inpute node and the subscriptions can go out via http as well? Wasn't 100% sure looking in the manual if this was possible. |
You will have to write a flow that will start with an HTTPInput node and end with a publication node, and then another flow that will act as a subscriber and end with an HTTPRequest node. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Thu Aug 04, 2005 1:50 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
jefflowrey wrote: |
You will have to write a flow that will start with an HTTPInput node and end with a publication node, and then another flow that will act as a subscriber and end with an HTTPRequest node. |
So the publication node can only publish MQ messages?
In Orlando, there was Session M57, WB-IMB and Pub/Sub. There was a slide listing all the transports (both in and out) that were valid. On the outbound side they had, MQ, MQ Mobile, MQ Telemetry, MQ RealTime (JMS Interface), Multicast (JMS Interface) and MQ Web Services. MQ Web Services was described as "Provides a reliable managment network infrastructure for clients connected through the HTTP protocol.".
This lead me to believe HTTP in and out for Pub Sub. Or are they assuming your design, with the double message flows tied together with MQ in between them? _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
|