| Author |
Message
|
| jeevan |
 Posted: Fri Feb 10, 2006 10:25 am Post subject: BEst practice in MQ app |
 |
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
Is there any website which has best practices in MQ appls.
thanks |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Fri Feb 10, 2006 10:26 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Yes.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jeevan |
| Posted: Fri Feb 10, 2006 10:30 am Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
where ?
can you please give me the link
thanks |
|
| Back to top |
|
|
| ramires |
| Posted: Fri Feb 10, 2006 11:10 am Post subject: |
|
|
Knight
Joined: 24 Jun 2001
Posts: 523
Location: Portugal - Lisboa
|
MQSeries.net it's a great site!  |
|
| Back to top |
|
|
| jeevan |
| Posted: Fri Feb 10, 2006 11:26 am Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
that fine. Can some one give me some of the best practice in programming for MQ? or MDB?
thanks |
|
| Back to top |
|
|
| mvic |
| Posted: Fri Feb 10, 2006 11:57 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| jeevan wrote: |
| best practice in programming for MQ? |
The sample programs available in the MQ installation are intended to show best practices. There are also others availabe here (see "repository") and on developerWorks.
There may also be IBM education classes available (there used to be, anyway). |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Feb 10, 2006 1:28 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| jeevan wrote: |
that fine. Can some one give me some of the best practice in programming for MQ? or MDB?
thanks |
And talking specifically about MDB there is a great readbook about JMS Topology.
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| hdjur |
| Posted: Thu Nov 16, 2006 11:58 am Post subject: |
|
|
Centurion
Joined: 16 Sep 2004
Posts: 116
Location: Zagreb
|
Can someone give me the best practice for opening the reply queue? As I see it, there are no more than two reasonable ways:
1. request driven - take ReplyToQ and ReplyToQMgr from request MQMD and provide it as ObjectName and ObjectQMgrName input to MQOD 2. hard coded ObjectName and blank (default) ObjectQMgrName input to MQOD
Looking at Table 3. Resolving queue names when using MQOPEN: http://publibfp.boulder.ibm.com/epubs/html/csqzal06/csqzal061x.htm#HDROPENOBJ
from application developer point of view is there any other possible choice? I'm talking about establishing standard for writing applications in my company regarding that matter, in order to achieve portable, scalable, etc. applications, so that an MQadmin may introduce new qmgrs, clusters, message brokers etc. with no changes in applications required. |
|
| Back to top |
|
|
| mvic |
| Posted: Thu Nov 16, 2006 12:30 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| hdjur wrote: |
| from application developer point of view is there any other possible choice? |
I know of none. Is there a reason the above two options are not acceptable? |
|
| Back to top |
|
|
| tleichen |
| Posted: Thu Nov 16, 2006 12:34 pm Post subject: |
|
|
Yatiri
Joined: 11 Apr 2005
Posts: 663
Location: Center of the USA
|
| hdjur wrote: |
Can someone give me the best practice for opening the reply queue? As I see it, there are no more than two reasonable ways:
1. request driven - take ReplyToQ and ReplyToQMgr from request MQMD and provide it as ObjectName and ObjectQMgrName input to MQOD 2. hard coded ObjectName and blank (default) ObjectQMgrName input to MQOD
Looking at Table 3. Resolving queue names when using MQOPEN: http://publibfp.boulder.ibm.com/epubs/html/csqzal06/csqzal061x.htm#HDROPENOBJ
from application developer point of view is there any other possible choice? I'm talking about establishing standard for writing applications in my company regarding that matter, in order to achieve portable, scalable, etc. applications, so that an MQadmin may introduce new qmgrs, clusters, message brokers etc. with no changes in applications required. |
Well, I've had now issues with method 1 above. What other kind of choice would you be looking for? 
_________________
IBM Certified MQSeries Specialist
IBM Certified MQSeries Developer |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Nov 16, 2006 5:09 pm Post subject: |
|
|
Guest
|
Hard-coding object names is not a best practice.
An application that puts a request message and expects another application to send a reply needs to have a reply-to-queue.
In a distributed queue manager (network of qmgrs) scenario, the name of the reply-to-queue must be resolved on the requesting qmgr before the message is put to the xmit queue. The replying application takes the reply-to-queue and reply-to-queue-manager from the MD, assumes these to be resolved, and uses them to mqput the reply in the transmission queue whose name equals the reply-to-queue-mnager from the inbound MD. The requesting application does an MQGET with a wait on the reply-to-queue for the reply message. This works.
If I understand your Choice 2 (if you consider this a choice) is to have aQLocal defined by a sysadmin (not a dynamic queue) to be used for the requesting application to receive replies. This works fine for one instance of the requesting app and replying app.
But, what if multiple (many, hundreds, thousands)instances of the requesting program send request messages, and multiple replying applications send replies. Now, multiple requestors must find the appropriate reply from all the replies that have arrived in the pre-defined-reply-to-queue.
I had a sysadmin tell me that Choice 2 is a dramatic processor saving idea given the machine cycles it takes for a dynamic reply queue to be created each time one is needed. While this might seem to be intuitive, this technique creates the programming challenge above.
My rule of thumb is not to write applications around hardware configurations because they change frequently. |
|
| Back to top |
|
|
| hdjur |
| Posted: Fri Nov 17, 2006 11:13 am Post subject: |
|
|
Centurion
Joined: 16 Sep 2004
Posts: 116
Location: Zagreb
|
| tleichen wrote: |
| Well, I've had now issues with method 1 above. |
Did you mean:
| Quote: |
| Well, I've had no issues with method 1 above. |
Consider this. There is a cluster of qmgrs in which requesting appls put requests to clustered queues hosted only by qmgrs local to replying appls, which on the other hand put replies to clustered queues hosted only by qmgrs local to requesting appls. Since there are multiple instances of the same reply queues hosted by multiple qmgrs local to requesting appls (and multiple instances of requesting appls, both requesting and replying appls are MQ server appls holding only a connection to a local qmgr), replying appls use method 1 to reply to a "proper" instance of a reply queue. I'm not sure whether we call it message affinity too, I think so, although, reply consists of only one physical and logical message, there is no groups, no segmentation etc. And method 1 seems to be a natural convention for such an environment. If I want to introduce message broker qmgr in between (message flows are also MQ server appls connected only to a broker qmgr), transparently to both applications, what steps are required from MQadmin side, and from message flow developer side? I will make it a part of the same qmgr cluster, but I see no simple (natural) way to ensure that replying appls put replies back to a broker qmgr hosted queue. I may save ReplyToQMgr from request MQMD in a copy of a request message in a backup queue on broker qmgr, and I may input broker qmgr name instead of original ReplyToQMgr when transforming request message in a compute node in message flow which handles request, and then when I get reply, in a message flow which handles reply, I may match it with a copy of a request (by correl Id) so that I may put reply in a proper instance of a reply queue. Or, is there something simpler? I'm talking about benefits from qmgr cluster technology, benefits from message broker technology, ease of administration, simplicity of application code, ease of transformation from clustered "no broker" to a clustered broker environment etc. Maybe, I may establish standard for writing replying applications using method 2., and copying ReplyToQMgr from request MQMD to a reply MQMD? Which also does not seem to be natural. So I ask which is the best practice for this transformation.
Last edited by hdjur on Sun Nov 19, 2006 3:54 am; edited 2 times in total |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Nov 17, 2006 11:21 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Request/Reply is a design pattern.
I have never seen any documentation of this pattern that specifies that the Reply queue can be hard coded.
That is, there is only option 1 as far as I know.
There are additional design patterns that might allow this kind of thing - for example a Request/Acknowledge + Response pattern, in which the Server sends a synchronous acknowledgement of the request and then later an asychronous Response.
But that's actually usually implemented as a Request/Reply and Fire&Forget, or two Request/Replies.
Request/Reply is a very interesting pattern in a Pub/Sub network (at least I find the notion of a ReplyTo Topic to be an interesting one).
_________________
I am *not* the model of the modern major general.
Last edited by jefflowrey on Fri Nov 17, 2006 11:34 am; edited 1 time in total |
|
| Back to top |
|
|
| hdjur |
| Posted: Fri Nov 17, 2006 11:33 am Post subject: |
|
|
Centurion
Joined: 16 Sep 2004
Posts: 116
Location: Zagreb
|
|
| Back to top |
|
|
| hdjur |
| Posted: Sun Nov 19, 2006 1:17 am Post subject: |
|
|
Centurion
Joined: 16 Sep 2004
Posts: 116
Location: Zagreb
|
| Talking about best practice and design patterns, in the example above I can avoid backup queue if I choose to have one message flow for handling request, waiting for reply, and handling reply, but I assume it would be a bad choice? Is it better to create two separate message flows, one for handling request, and the other for handling reply, to avoid possible bottlenecks in a message flow? Requesting and replying applications work in synchronous mode. |
|
| Back to top |
|
|
|
|
