| Author |
Message
|
| PeterPotkay |
 Posted: Tue Aug 11, 2015 5:31 pm Post subject: Request Reply |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Service Requester sends a Request Message, populates the MQMD Reply To Queue, lets the QM its connected to automatically fill in the Reply To QM.
Service Provider processes the request message and sends the reply message back to the Reply To Q and Reply To QM from the request message.
Classic Request /Reply pattern.
Now consider this:
Service Requester sends a Request Message, populates the MQMD Reply To Queue with a queue name that is a Reply To Queue Alias, and leave the Reply To QM blank. The local QM’s Reply To Alias sets the MQMD Reply To Queue to the name of a local Reply queue, and the Reply To QM is set to some value that resolves to clustered QM Alias called, for example “COME.BACK.HERE”.
Service Provider processes the request message and sends the reply message back to the Reply To Q and Reply To QM from the request message. When doing the MQOPEN to a destination QM of “COME.BACK.HERE”, MQ will load balance that MQOPEN across the clustered instances of “COME.BACK.HERE”, and thus your reply messages can load balance. This eliminates the tiny window of potential failure where a requester instance sends the request, but it or the QM it was connected to dies before the reply comes back, orphaning that reply message. Of course the Service Requester is designed such that any instances of its “Reply Message Listeners” can process any reply message regardless of which instance of their app’s Requester Sender produced the message.
If the first pattern was called “Request / Reply”, what do you guys call the second? Yeah its kinda request / reply as well, but looking for a unique name.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| vsathyan |
| Posted: Tue Aug 11, 2015 7:50 pm Post subject: |
|
|
Centurion
Joined: 10 Mar 2014
Posts: 121
|
Request Local, Reply AnyWhere..  
_________________
Custom WebSphere MQ Tools Development C# & Java
WebSphere MQ Solution Architect Since 2011
WebSphere MQ Admin Since 2004 |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Aug 12, 2015 4:42 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Request / Shout Back?
Request / Listen For The Echo?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Wed Aug 12, 2015 4:44 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| Vitor wrote: |
Request / Shout Back?
Request / Listen For The Echo? |
Request/Where's my message Gone
(to borrow the title of a presentation from IBM at a T&M conference > 10 years ago)
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Aug 12, 2015 4:47 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
How about Asynchronous Request / Reply ? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Aug 12, 2015 5:31 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
IBM's course-ware describes as 'synchronous request-reply' the usual request-reply model where the requesting app waits for the reply from the responding app.
IBM's course-ware describes as 'asynchronous request-reply' the variant where the replies do not (need not) go back to the requesting app, but rather go a third app that deals with the replies.
_________________
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 |
|
|
| mqjeff |
| Posted: Wed Aug 12, 2015 5:49 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
It's basic request reply at a certain level of design - more generally at design in the first place. The app is designed to send a request and receive a reply.
The difference between what you are talking about and a basic request reply is that the same app runs in more than one instance.
If the request was done in one thread and the reply was read by a separate thread in the same app instance - this is request reply. If those threads are now in different app instances - is it not still request reply?
If you want a separate name, I might blather about horizontal scaling. Or use F.J.'s asynchronous request/reply. And try very hard to avoid having to mumble about "psuedo-synchronous".
I would view "request->provider->reply->third app" as not request reply, but merely a standard mq workflow. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Aug 14, 2015 5:33 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| mqjeff wrote: |
If the request was done in one thread and the reply was read by a separate thread in the same app instance - this is request reply. If those threads are now in different app instances - is it not still request reply?
|
It is, but I want to depict both patterns in a PowerPoint, and name each uniquely so that I can refer to either with a single name or phrase during conversations.
Still searching for the perfect names to describe these.
Maybe Simple Request / Reply versus Advanced Request / Reply? 
If a Requester can structure themselves so that the reply message is no longer dependent on the thread or instance that produced its correlating request, that's more "advanced" than the typical request / reply which is "simple" in comparison.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Aug 14, 2015 5:35 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Scalable request/reply?
Service oriented request/reply? (or sommat like) |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Aug 14, 2015 5:43 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| mqjeff wrote: |
Scalable request/reply?
Service oriented request/reply? (or sommat like) |
The simple one is scalable, as well as SOA 'compliant'. Not being argumentative, just throwing ideas and pros / cons around.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Aug 14, 2015 5:50 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Distributed request/reply?
Load balanced request/reply? |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Sun Aug 16, 2015 4:56 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
Decoupled Request / Reply
The reply msg has an affinity with the request msg, but the reply is not coupled or has a synchronous messaging relationship with the qmgr that produced the original request.
_________________
Glenn |
|
| Back to top |
|
|
| exerk |
| Posted: Mon Aug 17, 2015 12:47 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| gbaddeley wrote: |
| Decoupled Request / Reply |
Should that not be Request / Decoupled Reply ?
_________________
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: Mon Aug 17, 2015 3:32 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| exerk wrote: |
| gbaddeley wrote: |
| Decoupled Request / Reply |
Should that not be Request / Decoupled Reply ? |
Decoupled Request/Decoupled Reply.
_________________
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 |
|
|
| gbaddeley |
| Posted: Mon Aug 17, 2015 5:02 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
"Decoupled Request / Reply", meaning the request message is decoupled from the reply message. The app instance that produced the request message is not expecting the reply message.
_________________
Glenn |
|
| Back to top |
|
|
|
|
