OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

provision message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [provision] RequestType should require requestID.


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]