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

On Thursday, January 23, 2003, at 01:00 PM, Miles Sabin wrote:

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

*Exactly* the reverse.  I have something much less specific than Joe 
Random Protocol, or HyperText Transfer Protocol in mind.

Let me see if it works if I use requirements language:

Designers of Message Exchange Patterns MUST expose properties sufficient 
to allow hooks from protocols using multiple network paradigms 
(synchronous, asynchronous, etc.) or MUST explicitly state that the 
pattern is only suitable for use with a particular network paradigm.

The specifics of timeouts are just a rathole.  We could chase those 
rodents all day, for a month, to no useful purpose.

The point of the original message is that *context* *matters*.  In 
attempting to hook up a protocol that does not have the same 
connection-oriented semantics as HTTP to the existing SOAP 
Request-Response MEP, I find that the state machine definition is 
incomplete.  It does not expose properties that I need to manipulate in 
the exchange.  This is because it *assumes* connection oriented protocols.
   The implicit state changes can only happen one way, so there's no point 
in even mentioning the properties.

Designers more aware of their preconceptions might at least note that 
"this is a request-response pattern for synchronous protocols only."  That'
s not that much help to me; I *still* have to go and write the full 
description and state machine for request-response that isn't synchronous,
  but at least it doesn't seize the naming high ground, making the 
assertion, via its name, that it is suitable for request-response in all 
circumstances.

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

I am asserting that any given MEP must account for multiple network 
paradigms, and not implicitly tie the definition to a particular paradigm 
by failing to expose properties.

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

That this one particular tiny issue deserves special treatment.

I think that perhaps by giving an example, I haven't encouraged thinking 
about the ideas and consequences behind the example, but merely encouraged 
over-focus on the details of the example.  *sigh*  I designated it Joe 
Random Protocol because I did *not* particularly want to argue the details 
of an imaginary protocol.

A great deal of current work contains built-in assumptions, one of which 
is that SOAP runs over HTTP.  The built-in assumptions make it very hard 
for that not to be true, because anyone attempting to do anything with 
other protocols is forced to do an enormous amount of largely-redundant 
work, when the assumptions of HTTP don't fit the case.

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

Umm, right.  Request-response doesn't expose termination conditions as 
properties that can be hooked and called out in MEP specializations per 
protocol.  It only works for HTTP.

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

I'm describing the limitations of the current MEP definition, and some of 
the consequences.  I want some of these limitations to be acknowledged (or 
maybe even addressed), so that the consequences don't have to be so 
painful.

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

I can't agree.  It isn't under the control of the folks doing the protocol 
binding, and probably not under the control of the service administrator.  
In short, it can't be described, because it's part of the network 
environment.  Unlike the properties that I listed in my example, there's 
no reasonable way to add them to a state machine description.

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

Well, yes.  Like current services are quite tightly coupled to HTTP.  
Having spent quite a lot of time trying to deploy some other things, I 
really just want to be able to *unbind* from HTTP, so that I can point at 
something *else* instead.  It's a real challenge, because HTTP 
characteristics are baked in at points where folks haven't really thought 
about it.  At the point of deployment, the services ought to be able to 
take advantage of the protocol characteristics.  Or, in other words, I'm 
talking about being able to expose properties that are going to be 
addressed in the binding tree, not in the portType tree (although it's 
likely that a single attribute (transport="uri") may define the semantics 
for a large number of properties, as now happens implicitly).

Amy!
(grumpy from the snow)

Received on Thursday, 23 January 2003 13:24:55 UTC