| Author |
Message
|
| smdavies99 |
 Posted: Thu Jun 21, 2012 6:41 am Post subject: |
 |
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| lancelotlinc wrote: |
| Smart move. |
Sigh...
In certain circumstances yes this might be the solution but not always.
_________________
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 |
|
 |
| mqjeff |
| Posted: Thu Jun 21, 2012 7:12 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| ktg wrote: |
| The webservices being called are again message flows which in turn put request message on MQ queue. |
that's not what I asked. I didn't ask what you were doing downstream of your flows, I asked what was upstream.
Who is calling your flows that are theoretically using Asynchronous soap downstream?
And, again, I strongly suggest you consider SOAP/JMS instead of SOAP/HTTP. |
|
| Back to top |
|
|
| ktg |
| Posted: Fri Jun 22, 2012 3:46 am Post subject: |
|
|
Centurion
Joined: 09 Jan 2006
Posts: 138
Location: India
|
| Quote: |
Who is calling your flows that are theoretically using Asynchronous soap downstream?
|
IVR and Ebanking applications are calling our webservice.
| Quote: |
| I strongly suggest you consider SOAP/JMS instead of SOAP/HTTP. |
We don't have control over that. Client is migrating existing webservice which has been implemented using tomcat webserver to use message broker. The entry point should not be changed as it results in change in the application which in turn call our flows/webservice. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Jun 22, 2012 4:02 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| ktg wrote: |
| Quote: |
Who is calling your flows that are theoretically using Asynchronous soap downstream?
|
IVR and Ebanking applications are calling our webservice. |
So there is a human being at the other side of the IVR and ebanking applications, sitting and staring at a screen waiting for a response... ?
And your architects want to make them wait? |
|
| Back to top |
|
|
| ktg |
| Posted: Fri Jun 22, 2012 4:16 am Post subject: |
|
|
Centurion
Joined: 09 Jan 2006
Posts: 138
Location: India
|
| Quote: |
| And your architects want to make them wait? |
You are correct. I will rise this question. Thank you for making me to realize this point 
-Kalpana |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Mon Jun 25, 2012 11:55 pm Post subject: Re: asynchronous or synchronous request node |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| ktg wrote: |
| When it is worth to use SOAP asynchronous node - what should be the minimum response time for the SOAP request being sent? |
minimum response time = request threads / request rate
If all of the request threads are blocked waiting for responses, requests are still coming in, and increasing the thread count doesn't help, then consider asynchronous request/response flows.
| mqjeff wrote: |
| So there is a human being at the other side of the IVR and ebanking applications, sitting and staring at a screen waiting for a response... ? And your architects want to make them wait? |
How would asynchronous web service calls increase client wait time, compared to synchronous calls? |
|
| Back to top |
|
|
| Esa |
| Posted: Tue Jun 26, 2012 12:02 am Post subject: Re: asynchronous or synchronous request node |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| rekarm01 wrote: |
How would asynchronous web service calls increase client wait time, compared to synchronous calls? |
The won't time out if the endpoint is down, for example.
[Edit]Sorry, yes they will. Just days left to my vacation and it seems I have already put my brain to rest.[/Edit] |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jun 26, 2012 2:16 am Post subject: Re: asynchronous or synchronous request node |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| rekarm01 wrote: |
| mqjeff wrote: |
| So there is a human being at the other side of the IVR and ebanking applications, sitting and staring at a screen waiting for a response... ? And your architects want to make them wait? |
How would asynchronous web service calls increase client wait time, compared to synchronous calls? |
In this manner.
A synchronous call presents a little spinny widget that says "Keep waiting", and so the human keeps waiting.
An asynchronous call presents a response that says "Your request was received. Check back later to find out the response." And so the human goes to get another cuppa, and checks email, and chats with their neighbor, and several hours later remembers to go check the response. |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Mon Jul 02, 2012 12:49 am Post subject: Re: asynchronous or synchronous request node |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| mqjeff wrote: |
A synchronous call presents a little spinny widget that says "Keep waiting", and so the human keeps waiting.
An asynchronous call presents a response that says "Your request was received. Check back later to find out the response." And so the human goes to get another cuppa, and checks email, and chats with their neighbor, and several hours later remembers to go check the response. |
That doesn't really explain why an asynchronous call should increase the client wait time. If the message flow takes x seconds to process the request, y seconds to send a request and get a response from the backend web service, and z seconds to process the response, then for each transaction:- the message flow with the SOAPRequest node will tie up a thread for x+y+z seconds
- the message flow with the SOAPAsyncRequest node will tie up a thread for x seconds
- the message flow with the SOAPAsyncResponse node will tie up a thread for z seconds
In either case, the client wait time is at least x+y+z seconds. It could be more then that if a message flow has to wait for a thread to process a request or response, but that only seems more likely for the synchronous case. Where is the extra time spent in the asynchronous case? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Jul 02, 2012 4:35 am Post subject: Re: asynchronous or synchronous request node |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| rekarm01 wrote: |
| That doesn't really explain why an asynchronous call should increase the client wait time. |
I didn't say it would.
I said it would increase the amount of time that a human being waited.
The big point here is that if you have an existing synchronous request process, with a real live human being on the other side, you need a strong reason to move it to being asynchronous.
Or you need to make sure that the UI that the human being is seeing and interacting with does not present the request as asynchronous.
If you want to make it asynchronous because you want to be able to spin off lots of threads that then fill in different parts of the page, that's fine. If you want to make it asynchronous because you want to present the user with a page that says "Request submitted, please come back later" where previously they were receiving real data, then that is not fine. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jul 03, 2012 11:43 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
A different spin on the same argument I made above.
Consider |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Fri Jul 06, 2012 11:10 am Post subject: Re: asynchronous or synchronous request node |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
The OP asked about using the SOAPAsyncRequest node. This does not require changing the upstream client code or UI, and does not require changing the downstream web service implementation. This does require downstream support for WS-Addressing, but is otherwise completely transparent to the surrounding components.
The purpose of the asynchronous SOAP nodes is to increase throughput and decrease response time, when calling high-latency web services; this should decrease human wait time, for more humans. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Sun Jul 08, 2012 6:32 am Post subject: Re: asynchronous or synchronous request node |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| rekarm01 wrote: |
| The OP asked about using the SOAPAsyncRequest node. This does not require changing the upstream client code or UI, and does not require changing the downstream web service implementation. This does require downstream support for WS-Addressing, but is otherwise completely transparent to the surrounding components. |
Theory is not the same as practice.
Theory says "everything works without significant change".
Practice says "Pay attention to the fine details, and make sure that the existing contract between the front end and all intermediate systems remains intact".
It's very easy to do so something like switch a SOAPRequest to a SoapASyncRequest and move the processing to a new flow started from ASyncSoapResponse.
It's very easy for that simple change to be made using default values that then break the contract with the upstream UI. Particularly during unexpected high load on the weekend during a maintenance window.
| rekarm01 wrote: |
| The purpose of the asynchronous SOAP nodes is to increase throughput and decrease response time, when calling high-latency web services; this should decrease human wait time, for more humans. |
Design is not the same thing as implementation.
"Should" is not the same as "Does". I'm saying make sure. That's my point!
 |
|
| Back to top |
|
|
| huwgb |
| Posted: Thu Jan 23, 2014 9:23 pm Post subject: |
|
|
Novice
Joined: 07 May 2013
Posts: 21
|
I know this is bumping an old topic. But is it still the case that SOAPASyncResponse nodes can not receive responses over HTTPS as mentioned earlier in this thread?
Currently on WMB 8.0 FP1 (going to FP3 in a few months hopefully)
edit:
NM, I just verified it still appears to be the case with mqsireportproperties
If anyone has anything more to add on this oddity, please let me know. |
|
| Back to top |
|
|
|
|
