| Author |
Message
|
| Esa |
 Posted: Wed May 23, 2012 10:58 pm Post subject: SOAPInput and one-way operation |
 |
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
How to make SOAPInput return http ack 202 for a one-way operation?
I have created a mock service that serves an one-way operation. Broker version 6.1. It always returns 505 HTTP version not supported. I'm calling the service from another flow on the same broker. I have tried to change the calling end to use HTTP version 1.0 instead the default 1.1, but it does not help.
I would also like to know if SOAPInput sends the ack for one-way operations immediately after having received the call or only after it has committed the flow thread. I cannot test this because my server flow does not want to co-operate. |
|
| Back to top |
|
 |
| smdavies99 |
| Posted: Wed May 23, 2012 11:13 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Isn't this a case for an ASYNC SOAP service?
_________________
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 |
|
|
| Esa |
| Posted: Thu May 24, 2012 1:13 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| smdavies99 wrote: |
| Isn't this a case for an ASYNC SOAP service? |
Well, one-way calls are kind of asynchronous because they do not expect to get any reply. But there should be no reason to use WS-addressing with one-way calls, unless I have misunderstood something. |
|
| Back to top |
|
|
| mgk |
| Posted: Thu May 24, 2012 1:27 am Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
Hi.
| Quote: |
| I would also like to know if SOAPInput sends the ack for one-way operations immediately after having received the call |
Yes, if the WSDL indicates a one-way message then the Ack is sent immediately, before the message is sent down the flow. This can be different in Gateway mode, but that's after v 6.1..
| Quote: |
| It always returns 505 HTTP version not supported |
Are you sure the error is correct? I might have expected a Method not supported if you were sending GET, but not version unless you are sending a custom HTTP version... Can you capture the msg on the wire?
Kind Regards,
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
| Back to top |
|
|
| Esa |
| Posted: Thu May 24, 2012 5:38 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
thanks, mgk
putting TCPMon in between helped me to solve the problem. I had a SOAPReply in the flow, which caused an exception. When I corrcted it and redeployed, the original error vanished as well. No idea why. |
|
| Back to top |
|
|
| Esa |
| Posted: Thu May 24, 2012 5:53 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| mgk wrote: |
Yes, if the WSDL indicates a one-way message then the Ack is sent immediately, before the message is sent down the flow. This can be different in Gateway mode, but that's after v 6.1..
|
It does not seem to be so. If the endpoint service called by the flow is down, I get the ack in SOAPUI only after the SOAPRequest in the flow has timed out.
And that makes sense, because especially in the case of a one-way operation the flow should be able to send an http error code to the client, shouldn't it?
The question is how to do it when the flow starts with a SOAPInput node. Perhaps by propagating a Root with an HTTPReply header but no body to a SOAPReply?
SOAPInput node seems to send a 202 ack even if there has been an exception in the flow. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu May 24, 2012 6:00 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Esa wrote: |
| mgk wrote: |
Yes, if the WSDL indicates a one-way message then the Ack is sent immediately, before the message is sent down the flow. This can be different in Gateway mode, but that's after v 6.1..
|
It does not seem to be so. If the endpoint service called by the flow is down, I get the ack in SOAPUI only after the SOAPRequest in the flow has timed out. |
Then either the WSDL does not indicate a one-way operation, the SOAPUI client isn't calling it as a one-way operation, or something is broken.
| Esa wrote: |
| And that makes sense, because especially in the case of a one-way operation the flow should be able to send an http error code to the client, shouldn't it? |
In the case of a one-way operation, the ACK should be sent as soon as the service has reasonably received the request. All http error codes that might be sent due to issues processing the request will be returned in an async response, if one is asked for. Otherwise, again, it's "fire-and-forget".
| Esa wrote: |
The question is how to do it when the flow starts with a SOAPInput node. Perhaps by propagating a Root with an HTTPReply header but no body to a SOAPReply?
SOAPInput node seems to send a 202 ack even if there has been an exception in the flow. |
Again, that's the correct behavior. The ACk says "I've *received* the request". If you need to ensure that the request is processed then it's not a one-way operation. It's a request/reply, potentially with an async reply rather than a sync reply. |
|
| Back to top |
|
|
| mgk |
| Posted: Thu May 24, 2012 7:08 am Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
Also, check your fixpac level is current. I vaguely recall one-way problems in early 6.1 fixpacs...
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
| Back to top |
|
|
| Esa |
| Posted: Fri May 25, 2012 12:39 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
Well, fixpacks or not, it seems one-way is problematic by default, unless you are distributing simple short-lived event messages that are allowed to get lost.
It seems we are moving towards request-reply after all, to be able to implement more fine-grained centralized logging and delayed retry also in cases other than the endpoint servers just being down. |
|
| Back to top |
|
|
|
|
