Re: Some notes on the Request-Response MEP, prompted by asynchronicity

On Thursday, January 23, 2003, at 11:04 AM, Miles Sabin wrote:
>
> Amelia A. Lewis wrote,
>> 3. Ouch.  I don't think that a protocol binding can specify this.
>> Looks like we need to ask those nice people at wsdesc how one can
>> represent a message timeout per-operation (or between any two
>> messages in an operation? ).  Maybe a service could set a default?
>> But it isn't reasonable for the JRP binding to establish timing; it's
>> going to be at least
>> service-dependent, and prolly operation-dependent.
>>
>> 4. As in 3.  It sort of needs to be in the WSDL, doesn't it, so that
>> the client can know when to give up.
>
> I'm not sure I understand why this is any worse than "Depends on the
> stack. As long as the socket stays open." from the HTTP case.

The difference is that one must be specified.  Somewhere.

> Suppose wsdesc added a message timeout: would you expect that to be used

Good heavens, what a silly idea.  wsdesc certainly *should* consider that 
in the abstract MEPs, termination conditions should be made explicit.

At that point, protocol bindings for which it is reasonable to do so can 
specify behavior with regards to termination.  Protocol bindings for which 
it is unreasonable can say "specify it in the WSDL."

> to specify HTTP client/server/proxy connection timeouts? How would you
> estimate the timeout value at any given time? Could you be sure that
> even a conservative estimate stays valid (consider: an admin tweaks a
> the connection timeout of a third-party proxy)?

I'm sorry, time for me not to understand.

I have a service.  The service is going to process three requests.  I'm 
using JRP.  Two requests are simple; they're going to get some data and 
return it.  As a service designer familiar with JRP, I know that delivery 
is pretty quick, as a rule, so I put the timeout in, say, minutes, which 
correlates more or less with TCP timeouts as applied to 
connection-oriented protocols.

The third operation calls for some back-end processing (enabling a delay 
between request and response is one of the good reasons for choosing an 
asynchronous protocol).  It takes variable time, but never more than, say,
  an hour.  I want it to time out in maybe two hours, to be safe.

Can I be sure that this is enough?  Well, of course not.  Is *that* a good 
reason for me not to be able to supply any information at all?  And why 
should I care at all about proxies?

In short, "it's answered for HTTP" doesn't seem to me to be a terribly 
good answer, if, as I believe, web services should be able to run over 
some other protocol, at some point.

Amy!

Received on Thursday, 23 January 2003 11:45:48 UTC