[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]