| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| MQ Client and Alias QMgr |
« View previous topic :: View next topic » |
| Author |
Message
|
| bruce2359 |
 Posted: Wed Oct 26, 2011 6:30 am Post subject: |
 |
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Some basics:
A WMQ Client platform has no qmgr, and thus, no queue definitions.
All of the definitions (QLocal, QRemote, QAlias, QModel, channels, etc.) are on the qmgr that the client app connects to.
So, your client app connects to a qmgr; then MQOPENs a queue definition. That definition can be any of the queue types. The resolved name will be a local queue. The local queue can be an xmit queue.
If you have no channels from this qmgr to other qmgrs, then you have no xmitqs. Therefore, it is not possible to have messages flow to other qmgrs.
Normally, a client only MQCONNects to one qmgr at a time.
So, without channels and xmitqs, how do you intend messages to flow to other qmgrs?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
 |
| bcostacurta |
| Posted: Wed Oct 26, 2011 6:33 am Post subject: |
|
|
Acolyte
Joined: 10 Dec 2009
Posts: 71
Location: Luxembourg
|
I tried to indent correctly the previous schemas
I understand my request is somewhere confused.
Sorry.
I'll try to make it clear via basic schema hereafter.
### schema 1 ###
MQ 'external' ----> MQ 'frontal' ----> MQ backend'
QRemote definition: ----> Alias Qmgr = QRemote Alias-01: ----> QLocal-xxx
RNAME = QLocal-xxx ........ RNAME = Qlocal
RQMANME = Alias-01 ........ RQMNAME = backend
QRemote definition: ----> *same Alias Qmgr Alias-01*- ----> QLocal-other
RNAME = QLocal-other
RQMANME = Alias-01
This schema 1 works very fine.
So the Alias Qmgr is *one* route to serve *many* messages destinations Qlocal (so from external to backend via frontal).
I insist : *one* route to server *many* message destinations.
This works fine because the RQMNAME in 'external' is resolved via Alias Qmgtr on the 'frontal'
### schema 2 ###
MQ Client 'external' ----> MQ 'frontal' ----> MQ 'backend'
Put Queue-A ----> Queue-A = QLocal/QRemote (not Alias Qmgr) ----> Queue-A
Put Queue-B ----> Queue-B = QLocal/QRemote (not Alias Qmgr) ----> Queue-B
So the questions are :
Now my question is : how to do the same from a MQ client 'external' ?
Obviously the MQ client cannot used QRemote definition on his side.
Indeed the MQ client can only does a put to a QLocal or normal QRemote (mean not Alias Qmgr) on the 'frontal', correct ?
To put from Client 'external' to an Alias Qmgr on 'frontal' will not help : Alias Qmgr do not contain the RName for the 'backend(
Note : If I need to define all routes on the 'frontal' this is not a router, but a simple *one* QRemote 'frontal' to *one* QLocal 'backend'.
I hope my request is clear.
Thanks for attention.
Bruno |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Oct 26, 2011 6:36 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| bcostacurta wrote: |
| Now my question is : how to do the same from a MQ client 'external' ? |
Again, the client DOES NOTHING DIFFERENT in terms of routing. |
|
| Back to top |
|
|
| bcostacurta |
| Posted: Wed Oct 26, 2011 6:40 am Post subject: |
|
|
Acolyte
Joined: 10 Dec 2009
Posts: 71
Location: Luxembourg
|
Question is now closed.
As already mentioned before, indeed without a Xmitq header a message cannot flow from one (here 'frontal') to other (here 'backend').
And a MQ client does not produce Xmitq header.
Thanks to all for attention and clarification.
Bye,
Bruno |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Oct 26, 2011 2:50 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| bcostacurta wrote: |
| ..And a MQ client does not produce Xmitq header... |
What does an application on the replying end of a Request/Response feedback need as a minimum to reply to a queue manager remote from the one to which it is 'attached' to? What is the difference between client application code and server application code? Why are you convinced that a client application cannot produce an XMIT header?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Oct 26, 2011 3:58 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| bcostacurta wrote: |
And a MQ client does not produce Xmitq header. |
Neither client- nor server-bindings apps explicitly create xmitq headers. The xmitq header is created when an app MQPUTs a message to an xmitq. The receiver-side channel agent (MCA) uses the XQH to determine what to do with the message when it arrives at that end of the channel.
The usual request-reply model has the requesting app place the name of the reply-to-queue and (optionally) the reply-to-queue-manager in the MQMD. This is how the replying app finds out how to send the reply back to the requesting app.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| bcostacurta |
| Posted: Wed Oct 26, 2011 11:33 pm Post subject: |
|
|
Acolyte
Joined: 10 Dec 2009
Posts: 71
Location: Luxembourg
|
| Quote: |
| What does an application on the replying end of a Request/Response feedback need as a minimum to reply to a queue manager remote from the one to which it is 'attached' to? |
The question I raised has *nothing* to do with the replying of reporting or any feedback, so called the request-reply model.
The question is about routing information and how to inform the router (called 'frontal' in schema) about the route (via the Alias Qmgr) to contact a backend from a MQ Client.
So how to send these information to the 'frontal' ?
As far as I can see *no* XMITQ header are produced by a MQ Client.
As other person mentioned in this mail thread, it simply seems that a MQ Client reach a MQ Server *without* routing or XMITQ information.
Bruno |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Oct 27, 2011 4:33 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| bcostacurta wrote: |
As far as I can see *no* XMITQ header are produced by a MQ Client.
As other person mentioned in this mail thread, it simply seems that a MQ Client reach a MQ Server *without* routing or XMITQ information. |
Exactly! When WMQ Client (client-bindings) apps issue any MQ calls, the call is shipped across the network to the SVRCONN channel of the qmgr named in the MQCONN. The call is processed on the qmgr the Client app MQCONNects to, just as if the application was a serve-bindings app. The r/c is returned to the WMQ Client app across the network.
An MQOPEN call issued by a WMQ Client app (again, shipped across to the SVRCONN channel) will drive the name resolution on the qmgr for the object name that the app MQOPENs. Again, this behavior is no different from a server-bindings app.
So, no XQH is needed or generated.
Your WMQ Client app could put some additional routing-type data into the application payload, or use Message Properties, in the messsage; and an app on the qmgr could interrogate this additional data to determine what next to do with the message.
Do some searching here for "hub queue manager". Hub qmgrs behave as message routers, BUT do the the routing via point-to-point (non-Client) channels, where XQHs are created. XQHs are NOT created explicitly by end-user applications. Rather, XQHs are created by a qmgr function when an app has MQOPENed and MQPUT a message to a transmission queue.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Oct 27, 2011 9:24 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I'm sure Bruce knows the following two points, its just as I read them as written I could see how someone new to MQ could interpret them incorrectly.
| bruce2359 wrote: |
So, no XQH is needed or generated.
|
If the message needs to go to another QM, a XQH is needed and generated. Its just that the app does not need to create it. The local queue manager will create the XQH for your message as it places the message on the correct XMITQ as part of Name Resolution if that Name Resolution determines your MQOPEN call wants to send messages to a remote QM. If the message is going to resolve to a local queue on the QM the app is connected to, then there is no need for a Transmission Q Header (XQH).
| Quote: |
| Rather, XQHs are created by a qmgr function when an app has MQOPENed and MQPUT a message to a transmission queue. |
While the putting app's MQOPEN and MQPUT call may resolve to a XMITQ, an app should never code its destination queue as the XMITQ. It should code the application queue name and optionally the destination QM name if required and let MQ magic resolve the MQ calls to the correct XMITQ behind the scenes.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Oct 27, 2011 9:33 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bcostacurta wrote: |
| As other person mentioned in this mail thread, it simply seems that a MQ Client reach a MQ Server *without* routing or XMITQ information. |
Because a MQ Client doesn't reach a MQ Server - it's connected to it directly. No routing is possibly, feasible or sensible. All traffic goes to the queue manager (to give MQ Server it's formal name) from the client. If the message is destined for a target not hosted by the queue manager to which the client is connected, then the queue manager will add the transmission header & send it on it's way. The client is not involved in this process any more than it's involved in stripping off a transmission header from a message sent from a remote queue manager before reading it.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Oct 27, 2011 9:37 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
I read the OP as misunderstanding how an MQPUT from a WMQ Client can cause a message to traverse a network without an XQH. The OP presumed that all messages must flow with an XQH. This is not the case with a WMQ Client app and SVRCONN channels.
XQHs are only used when a message needs to traverse a non-client channel - from Sender/Server to Receiver/Requester. These messages will have an XQH created from the QRemote definition that the application MQOPENs - if the app opens a QRemote definition.
So, if the OPs app (WMQ Client or server-bindings) opens a QLocal queue definition, the message is put to the local queue. If the app (WMQ Client or server-bindings) opens a QRemote definition, the qmgr will add an XQH to the message and place it in the transmission queue named explicitly in the QRemote def, or implicitly, or to the default-xmitq.
The OP needs to read about, and understand how client channels and client apps operate.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
