Author |
Message
|
bartland |
Posted: Tue May 04, 2004 8:09 pm Post subject: Queue managers - why care about the channel/server? |
|
|
Novice
Joined: 04 May 2004 Posts: 15
|
I have a (no doubt naive) question on MQ architecture.
On IP, QMs are defined 1 to 1 with IP sockets (I gather?). The QM is effectively a service. As a client I want to connect to a QM. I don't care where it lives and I should not have to specify such info. Why isn't this available via SAP? (I don't run AD). Why all the complications with having to specify the channel/socket? _________________ bruce |
|
Back to top |
|
 |
EddieA |
Posted: Wed May 05, 2004 9:35 am Post subject: |
|
|
 Jedi
Joined: 28 Jun 2001 Posts: 2453 Location: Los Angeles
|
Quote: |
I want to connect to a QM. I don't care where it lives |
But you have to. Name *any* IP based, client, program that is able to connect to a server without knowing the IP and port.
Quote: |
Why all the complications with having to specify the channel |
Think of the channel as your "profile" that is used to negotiate the communication and security settings. As an example, a Mail client may want to connect to a POP server for internet mail and an Exchange server for intranet mail. How does it do it. It has 2 profiles.
Cheers, _________________ Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
Back to top |
|
 |
jefflowrey |
Posted: Wed May 05, 2004 9:42 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
One way to avoid having your application know directly where a QM is, and how to connect to it, is to use some sort of a "directory service" that holds this information.
Then, your application can connect *to the directory service*, and get it's needed configuration information.
But then your application needs to know how to connect to the directory service.
Or you can put this information in a properties file, and have your application read that.
But then your application has to know where the properties file is.
Or you could put this information in the arguments passed to your application when it is launched.
But then your application has to know to look in the arguments. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
bartland |
Posted: Wed May 05, 2004 4:07 pm Post subject: |
|
|
Novice
Joined: 04 May 2004 Posts: 15
|
If IP Service Advertising Protocol were used you wouldn't need any of that. Each QM advertises itself (registers with the SAP Agents).
The client just issues a SAP request for a named service (ie. the QM name) which then autobinds to an IP socket.
Simple. No explicit IP sockets, files or directory services required.
Just wondering why it's not used?
cheers _________________ bruce |
|
Back to top |
|
 |
jefflowrey |
Posted: Wed May 05, 2004 4:22 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
So, this IP SAP protocol...is not a directory service, even though a "client" makes a "request" for a "named service".
And this request... would be made over IP? To some fixed server somewhere? Which has an address, that the client would have to know about before hand? _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
EddieA |
Posted: Wed May 05, 2004 4:51 pm Post subject: |
|
|
 Jedi
Joined: 28 Jun 2001 Posts: 2453 Location: Los Angeles
|
Not having heard of IP Service Advertising Protocol, I did a Google. This brought back pages of references to Netware and IPX.
I couldn't find any references to TCP anywhere. Seems it's a Netware protocol that runs over IPX. Kinda limiting for MQ.
But I'm willing to be proved wrong.
Cheers, _________________ Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
Back to top |
|
 |
bartland |
Posted: Wed May 05, 2004 4:57 pm Post subject: |
|
|
Novice
Joined: 04 May 2004 Posts: 15
|
oops. sorry. Acronym confusion.
SAP is the Novell IPX protocol. The IP equivalent is Service Location Protocol (SLP). Anyway same thing applies and I've used both.
These are multicast protocols. Any client can broadcast a request for an SLP service on a given subnet. Any server on the same subnet (can also do it across subnets if the routers allow the multicast packets through) can respond. They respond to the client with their IP address and port.
So client with IP address 192.168.1.1 broadcasts to subnet 192.168 for any service with name ABC. ABC responds with 192.168.9.9:1234.
Client caches the response so it doesn't have to broadcast next time unless the connect fails.
Just like AD. Clients ask for services on the same directory they're already conected to. _________________ bruce |
|
Back to top |
|
 |
bartland |
Posted: Wed May 05, 2004 4:59 pm Post subject: |
|
|
Novice
Joined: 04 May 2004 Posts: 15
|
|
Back to top |
|
 |
jefflowrey |
Posted: Wed May 05, 2004 5:03 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
bartland wrote: |
Just like AD. |
A directory service.
I believe, but don't remember the details, that there are ways of advertising queue managers in AD.
bartland wrote: |
Clients ask for services on the same directory they're already conected to. |
So, much like JNDI. Another directory service. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
bartland |
Posted: Wed May 05, 2004 5:14 pm Post subject: |
|
|
Novice
Joined: 04 May 2004 Posts: 15
|
My point is that conceptually SLP (and SAP) operate the same way as AD/LDAP/JNDI/NDS regarding service location. Except that you don't need the infrastucture of a directory or DNS. Even if you do have such infrastructure in place in is often much easier to implement SLP services.
My original query, was given how easy it use to implement SLP and use it as a client, why isn't it in MQ? Is there some architectural/operational issue regarding queue managers? (I am pretty new to MQ).
regards _________________ bruce |
|
Back to top |
|
 |
|