| Author |
Message
|
| ayanc |
 Posted: Tue Apr 08, 2008 4:49 am Post subject: Web Service Design: Providing Acknowledgement |
 |
|
Voyager
Joined: 15 Nov 2004
Posts: 88
|
Hi,
I am trying to implement a typical "broker mediates a web service" scenario. My current flow design is as follows:
HTTPInput -> Compute -> HTTPRequest -> Compute -> HTTPReply
Now client wishes to have an acknowledgement that the broker has received the request message (an ack after HTTPInput).
I am finding it difficult to design the flow to meet this requirement. If I use an HTTPReply earlier in the flow then the transaction is closed and subsequent replies sent shall be discarded.
I was looking at HTTP 100 Continue status code and tried it out but could not get it to work. The second reply was being discarded and the client was getting timed out.
Any ideas on how I may implement this feature would be very helpful. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Tue Apr 08, 2008 4:55 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You need to use Broker v6.1 and Asynchronous HTTP.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| marcin.kasinski |
| Posted: Tue Apr 08, 2008 5:13 am Post subject: |
|
|
Sentinel
Joined: 21 Dec 2004
Posts: 850
Location: Poland / Warsaw
|
| jefflowrey wrote: |
| You need to use Broker v6.1 and Asynchronous HTTP. |
Can you elaborate it?
Isn't HTTP client request (not broker request) synchronous ?
_________________
Marcin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Apr 08, 2008 5:21 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
|
| Back to top |
|
|
| marcin.kasinski |
| Posted: Tue Apr 08, 2008 5:22 am Post subject: Re: Web Service Design: Providing Acknowledgement |
|
|
Sentinel
Joined: 21 Dec 2004
Posts: 850
Location: Poland / Warsaw
|
| ayanc wrote: |
...
Now client wishes to have an acknowledgement that the broker has received the request message (an ack after HTTPInput).
...
|
What is additional value of this acknowledgement ?
_________________
Marcin |
|
| Back to top |
|
|
| ayanc |
| Posted: Tue Apr 08, 2008 5:42 am Post subject: |
|
|
Voyager
Joined: 15 Nov 2004
Posts: 88
|
Hi All,
Thanks for your prompt response. It is good to hear that we have the WS-Addressing capabilities in 6.1 However currently upgrading to 6.1 is not an option available with us. 
We had tried to explain our client that the response would anyway be available provided we have the correct timeout values configured in the source application and our broker HTTPRequest node. The entire flow is synchronous and if there is a delay in the response from the second application broker (HTTPRequest) would anyway timeout and a suitable reply can be sent back.
As far as the value of the acknowledgement is concerned ... It is something that I personally dont feel would add much value.
However client doesn't wish to wait for the response from the second application. It wants to have an acknowledgment from the broker beforehand.
Another suggestion is to use an HTTPRequest node in place of an HTTPReply node which will actually send the response but as a request. However it is not a good design per say.
I was thinking on these lines:
1. Send an HTTPReply with a specific HTTP Status code (100?) so that the client application may accept it as an acknowledgment. The status code could be such that the connection is kept open from both ends.
2 The client waits for the actual response.
3. Send the normal response through a second HTTPReply node.
A custom status code perhaps??? However I have no idea how the broker would understand that the intention is to continue to send the response to the client instead of closing the connection / completing the transaction.
I believe there could be some changes required from the client application as well to deal with this scenario. However the whole aspect of implementing it is not yet clear to me and hence I am not in a position to direct their team. |
|
| Back to top |
|
|
| mgk |
| Posted: Tue Apr 08, 2008 8:34 am Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
An HTTPReply node can only send ONE reply.
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 |
|
|
| ayanc |
| Posted: Tue Apr 08, 2008 8:43 am Post subject: |
|
|
Voyager
Joined: 15 Nov 2004
Posts: 88
|
So effectively I dont have any other option than using HTTPRequest node as a response sender.
It seems there is no other work around as of now.  |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Apr 08, 2008 8:48 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Push back on the client.
Ask them how they intend to have their HTTP requester receive more than one reply to the same HTTP operation (which is illegal in the HTTP standard...)
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| ayanc |
| Posted: Tue Apr 08, 2008 8:50 am Post subject: |
|
|
Voyager
Joined: 15 Nov 2004
Posts: 88
|
They have an answer to that. They are passing a separate transaction ID which is unique in every request. They wish to correlate using that ID. This ID is being sent back during the response message.
|
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Apr 08, 2008 8:55 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| ayanc wrote: |
They have an answer to that. They are passing a separate transaction ID which is unique in every request. They wish to correlate using that ID.
|
That's an answer to a different question.
My question is this: How do they expect to get more than one HTTP document in response to a single HTTP request?
HTTP does not allow this. HTTP says "One http document for a request, one http document for a reply".
HTTP says that the request is completed when *the* reply comes back.
There is no standard HTTP library that will allow you to wait for more than one reply - because it's illegal in the protocol.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| ayanc |
| Posted: Tue Apr 08, 2008 9:05 am Post subject: |
|
|
Voyager
Joined: 15 Nov 2004
Posts: 88
|
I completely agree. This is the exact reason why we tried to explain that it is not a good idea.
However ... they want some kind of confirmation that broker has received a request (something like a MQ Report option) before actually getting the response. They dont care about the content of the acknowledgment.
That is the reason why I was looking at HTTP status code 100. Although it is used for a different purpose altogether, but as per HTTP standard the client waits for the actual response.
In addition I was looking at this site:
http://dev2dev.bea.com/webservices/WS-Acknowledgement-0_9.html
This seems very similar to the capabilities addressed in 6.1 |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Apr 08, 2008 9:19 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Which is not an approved standard...
And WS-Addressing does this, anyway, I believe.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| mgk |
| Posted: Tue Apr 08, 2008 5:49 pm Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
WSAddressing can send an "ack" if you are using the SOAPNodes in 6.1, and send the actual reply back to a different HTTP location if that helps...
_________________
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 |
|
|
|
|
