| Author |
Message
|
| skiv |
 Posted: Wed Jun 28, 2006 12:48 am Post subject: Identifying if its pub or sub |
 |
|
Apprentice
Joined: 19 Jun 2006
Posts: 33
|
Hi
I need some advise regarding the identifying of the client if its pub or sub.
Right now I got a code that will authenticate the client before connecting to the Qmanager. The code is placed at the websphere mq v6 side.... I used MQ_AUTHENTICATE_USER function to accomplish that...
I would like to know if it is possible for me to identify if the client is pub or sub from this function or any other function that i can call from this function?
Thanks alot |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Wed Jun 28, 2006 2:24 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The only difference between a pub/sub connection and a point-to-point connection is the content of the messages.
Someone may argue that the queues being used are different as well, but that's not a meaningful difference in my opinion.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| wschutz |
| Posted: Wed Jun 28, 2006 3:09 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
If the queue was opened for OUTPUT, then wouldn't it be PUB (and conversely, open for Input=SUB) ?
Or are you talking about sending a subscription message to the broker?
_________________
-wayne |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Jun 28, 2006 3:28 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
An app could have any particular queue open for OUTPUT and not be publishing messages.
An app could have SYSTEM.BROKER.CONTROL.QUEUE open for output and not be publishing messages - although that might be a bit pathological, it's still entirely possible. Thus I don't think you can rely on this.
As for receiving subscriptions - an app could have *any* queue open for INPUT to receive subscriptions.
You might be able to look for broker processes that have queues open for OUTPUT and see that someone is receiving a subscription.
But then you'd have to know for sure which broker (base or EB/MB) was being used.
So, really, in order to do what skiv wants to do - which is implement security for pub/sub, one probably needs to use an API exit, and look for messages with an RFH2 that have a psd folder. This would also be a relatively broker-neutral solution, in that you only have to know the broker type if you need to handle the two types differently from a security point of view. Otherwise you can identify the command (publish, register subscription) without caring what broker you are using and act accordingly.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| skiv |
| Posted: Wed Jun 28, 2006 5:00 pm Post subject: |
|
|
Apprentice
Joined: 19 Jun 2006
Posts: 33
|
| sorry but do you have any example or sample that I can look through? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Jun 28, 2006 5:10 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
No, I don't. I've never written an API exit.
If you considered the mirrorq sample code, and looked at the Publish/Subscribe User's Guide for the definition of what pub/sub messages looked like, then you should be able to piece together two thirds of your puzzle. The other third is interrogating the userid and querying your user registry. And the last third is figuring out if you can trust the userid.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| skiv |
| Posted: Wed Jun 28, 2006 5:40 pm Post subject: |
|
|
Apprentice
Joined: 19 Jun 2006
Posts: 33
|
actually i already got the authentication for userid and password up, right now i just need to see from which parameter I can deduce if the client is a publisher or subscriber
especially when i have wrote a MQ_AUTHENTICATE_USER function already, I wondering if i can identify the publisher or subscriber through any parameters from here or if not any functions that allow me to identify if its publisher or subscriber that I can call from the MQ_AUTHENTICATE_USER function that i wrote |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jul 04, 2006 5:59 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Again, the difference between a connection that is acting as a publisher/subscriber and one that is acting in a point-to-point is pretty much in the content of the messages that are being sent.
The code that one writes is exactly the same up to the point of sending messages. Then, if one wishes to publish, one builds a publication message and puts it to SYSTEM.BROKER.CONTROL.QUEUE.
Subscriptions are even worse. Subscriptions can be registered manually - so an application does not need to do anything with SYSTEM.BROKER.CONTROL.QUEUE in order to receive subscriptions. The app can open *any* queue, and get messages from it, and be a subscriber.
You could use any of the sample programs that GET messages as subscription apps! Without changing the code!
So you have to examine the contents of the messages! And then be able to associate those messages back to the connection that was made.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Jul 04, 2006 10:03 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
er Jeff, I thought the publication went into the "SYSTEM.BROKER.DEFAULT.STREAM" Queue. Did I get it wrong somewhere?
The publication registration would go to the control queue right ? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jul 04, 2006 2:30 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
First off, my memory is probably a bit faulty.
Secondly, if I recall, there's a difference between which broker is being used. So the WMB broker has different behavior and inputs than the base MQ broker.
What I remember is that the publication node itself would put your message to SYSTEM.BROKER.CONTROL.QUEUE, from which necessary copies would go out to all subscribers. But that's from 2.1 when the Publication node was more of a convenience and less "opaque" than it is now.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
