Re: [provision] RequestType should require requestID.

[Gary P Cole <Gary.P.Cole@Sun.COM>]

Well, I may be explaining this poorly, but the PSTC's resolution in the 
most recent Face-to-Face was that any requestID from the original 
request should also identify the asynchronously-executing operation. 
- if the original request specifies requestID, then the response must 
specify that same requestID.
- if the original request omits requestID, then the response must 
specify a requestID that the provider generates.
Either way, a requestor should specify the requestID from the original 
response as the value of the 'asyncRequestID' argument in a 
statusRequest (or a cancelRequest).

1) If the requestor specifies a requestID in the request, then the 
requestor KNOWS the requestID value to supply to the status or cancel 
operation (even if the requestor does not receive the response).

2) If the requestor specifies a requestID in the request, then we don't 
have to restrict the requestor to one request at a time.  Theoretically, 
one could send a bunch of requests, receive a bunch of responses, and 
match them up using requestID.  A provider should be able to achieve 
better throughput by queuing requests (and dispatching multiple 
threads).  A requestor might be able to achieve better throughput if the 
protocol weren't quite so synchronous.

3) What's bad about requiring a requestID?  How big of a burden is this?

Jeff Larson wrote:

> Gary P Cole wrote:
>
>> I forgot to mention another important reason to require requestID: 
>> the "Hal Hole".  If the provider executes a requested operation 
>> asynchronously (either because the requestor said so or because the 
>> requestor let the provider decide so), then the provider must return 
>> a requestID that the requestor can use to cancel or to check the 
>> status of the operation.
>
>
> Yes, why is this a problem?
>
>> If the original request contains a requestID, then the requestor 
>> knows the requestID (even if the requestor for some reason does not 
>> receive the provider's response).  If the original request lacks a 
>> requestID and the requestor for some reason does not receive the 
>> provider's response, then the requestor must use the 'statusAll' 
>> operation (i.e., 'status' with no argument) to recover.  This hurts.
>
>
> Why would the requester "for some reason not receive the provider's 
> response"?
> SPML is essentially a synchronous protocol, you always get a response 
> back, though
> the response may tell you that the request is being executed 
> asynchronously.
> This issue applies to all synchronous protocols, I don't see why SPML
> is any more likely to have a problem.  In can imagine 3 cases:
>
>    - the requester decides to blow off the response
>        That's the requester's problem, if they didn't wait for a response
>        and they didn't specify a requestId, they get what they deserve.
>
>    - the provider takes too long and the connection drops
>        That's a bad provider.  I don't think it's unreasonable to expect
>         that the provider respond before a router somewhere drops the
>         connection (typically minutes).  If they can't then they 
> should be
>         converting it to an async request and returning a request id 
> immediately.
>
>     - the connection is unstable
>          That's the requester's problem.  Networks are usually 
> stable.  If a requester
>          knows that they're using one that isn't they need to specify 
> a requestId
>          (in addition to lots of recovery logic).  The requester has 
> to know this.
>
>> I think it would be much simpler (for the requestor, for the 
>> provider, and for anyone reading the specification) to require 
>> requestID in each request.
>
>
> I don't see it making anything simpler.  The complex part is the 
> recovery logic
> in the application.  If you're in an environment where connections 
> drop randomly,
> then you're going design the application in a certain way, how you 
> specify request
> ids is the least of your worries.
>
> Jeff