| Author |
Message
|
| prabuk |
 Posted: Thu Feb 26, 2004 2:19 pm Post subject: Synchronus Messaging using MQ in Java |
 |
|
Novice
Joined: 14 Mar 2003
Posts: 19
Location: JerseyCity, NJ
|
We would like to use the API to do a synchronus messaging. App A1 puts request message to Queue Q1, and waits for the response message as a response to the put call itself!! Is there a function like this where you put the message in synch mode with wait time, response queue name so that you could take back the response. I searched but I couldn't find any staright forward implementation.
If the app has to handle the synch logic, then I guess app will have to write the message to Q1 and wait for the response back in Q2. What is the best way to know if the response what we get is the response for what I sent just now. Ofcourse we can have a field in the message with an ID, I want to know if there is any feature as part of the MQMD.
Thanks for your help |
|
| Back to top |
|
 |
| vennela |
| Posted: Thu Feb 26, 2004 3:31 pm Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
You can use CorrelationId for this. Look at this response of bduncan on how your application should be designed.
Request Reply App model |
|
| Back to top |
|
|
| prabuk |
| Posted: Fri Feb 27, 2004 8:27 am Post subject: Synchronus Messaging using MQ in Java |
|
|
Novice
Joined: 14 Mar 2003
Posts: 19
Location: JerseyCity, NJ
|
Thanks Venela
I understand conceptually how a req-reply model works in MQ that,
Requesting app (client),
1. Sets msgid and not correl id
2. Sets reply-to-q for the response
Server app,
1. Reads the mssage, takes and preserves the msgid and reply-to-q params. Then it does what ever it has to do with the request.
2. Constructs a reply msg with Correl id as the request msg's msg-id
3. Sends the message to the reply-to-q
Now my question are,
1. Is there a direct java API call which hides all these implementations (My client wants to use the ready-to-use stuff if IBM provides it already), and gives a solution like, once you consturct a req msg with msgid (by default it does anyways) and reply-to-q parameters and then the question is - Is there put call that puts the message on the req qeue and returns the reply message as a return value to the same call. Is it too much to ask!!!
2. Another complexity is that we send messages to the MainFrame Server app to process and send response. Hence we write message to a remote queue which points to a local queue on MF side, which MF server app reads and sends the response back to the reply-to-q, which is a remote queue on their side which points to the local queue on client side. How does the reply-to-q mechansim handled on queue-manager to queue-manager scenario (that is client app write to QM1 and Server app is in QM2 and both are linked with remote queueing mechanism).
Thanks for your help and Appologise for a long post... |
|
| Back to top |
|
|
| EddieA |
| Posted: Fri Feb 27, 2004 10:32 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
Check out the JMS method QueueRequestor. Is that what you're after. Be aware that this creates a temporary queue for each request, so it may not be suitable for high volumes.
Or build your own 'wrapper' that does all the work and publish that.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| prabuk |
| Posted: Fri Feb 27, 2004 1:09 pm Post subject: |
|
|
Novice
Joined: 14 Mar 2003
Posts: 19
Location: JerseyCity, NJ
|
Nop We want to use standard java API, either AMI or MQI, is there anything else other than JMS implementations. I want documentation for AMI library (API reference and Java Doc).
Thanks for your help |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Mar 10, 2004 12:11 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
This is fairly simple programming. Seems hardly worth worrying about finding an external API wrapper just to perform a MQPUT and MQGET with WAIT. AMI seems to be going out of fashion anyway.
Here are some more points to remember.
Code EXPIRY on the request and reply messages, use non-persistent messages, usually use NO_SYNCPOINT in a synchronous mode.
Code WAIT (eg the same value as the expiry interval such as 60 seconds) on the MQGET. Specify CONVERT for cross-plaform compatibilty. |
|
| Back to top |
|
|
| bower5932 |
| Posted: Wed Mar 10, 2004 6:20 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
For what it is worth, the following shows up on the AMI SupportPac page:
| Quote: |
IMPORTANT NOTE
After June 2003, IBM has no plans to enhance the AMI with any new functions or platforms. IBM will however continue to support the AMI as described in the Technical Support section below.
|
I have to agree with earlier appends. It sounds like what you want to do is rather straight forward. I'm not sure that I would wrapper it, or if I wanted to, I'd do it myself rather than look for something. |
|
| Back to top |
|
|
|
|
