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

Amelia A. Lewis wrote,
> On Thursday, January 23, 2003, at 11:04 AM, Miles Sabin wrote:
> > 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.

Hmm ... it sounds like you have something more specific that Joe Random 
Protocol in mind. Sure, if JRP is defined in such a way that specified 
timeouts play an essential role in any use of the protocol, then they 
have to be specified. Somewhere.

But I read your mail as asserting that this would be needed for any 
conceivable asynchronous protocol (hence Joe Random), and that's not 
true. 

> > Suppose wsdesc added a message timeout: would you expect that to be
> > used
>
> Good heavens, what a silly idea.

Err ... what's a silly idea? I think I must be missing something.

> wsdesc certainly *should* consider that in the abstract MEPs,
> termination conditions should be made explicit.

Oh, no argument here.

But that's not what I thought you meant. I assumed that given your 
questions,

> 3. How long do I have to respond?
> 4. As a client, how long should I wait before I decide that I'm not
> going to *get* an answer?

and your answer for HTTP,

> 3. Depends on the stack.  As long as the socket stays open.
> 4. Until the socket closes; depends on the stack.

that these were supposed to be helpful answers to those questions, 
rather than just a statement of termination conditions. They certainly 
are termination conditions for HTTP, but they can't be used to reliably 
derive any useful information for either the sender or the receiver 
(eg. allowing a server to run a query at low priority because it knows 
it has 10mins rather than 5secs).

> 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? 

Now I'm completely lost. Aren't you describing service- rather than 
protocol-specific constraints?

> And why should I care at all about proxies?

I mentioned proxies in relation to HTTP. As deployed, HTTP proxies 
impose many unspecified and arbitrarily configurable constraints on 
connections (idle timeouts, request/response entity size limits etc.). 
If JRP, whatever it is, supports intermediaries with similar 
characteristics, then their possible behaviour would have to be 
factored into any statement of termination conditions.

> 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.

I think I'd agree if I was sure what I was agreeing to. There are 
termination conditions for HTTP, yes, but they're not much more 
specific that "you'll know when it happens". If other protocols can 
specify termination conditions more usefully, then I guess they should 
be allowed to ... tho' clearly any service which exploits the 
information which those conditions convey will end up fairly tightly 
coupled to that particular protocol.

Cheers,


Miles

Received on Thursday, 23 January 2003 13:01:03 UTC