RE: [AMG] Other message patterns

Hi Randy,

Thanks for your thoughts. At the recent f2f there was much discussion over
whether we should explicitly model the two-way request/response message
pattern and there are certainly folks who believe strongly that the only
thing we should model in the abstract model is the simple one-way message.
Part of the argument being that all other message patterns be synthesised
from simple one-way messaging - and we have a great proof of concept in that
ethernet, IP et. al. all provide a singular messaging primitive, the one-way
message and yet we have all manner of protocol build upon that basic
primitive.

So, there is some pressure to remove the request/response primitive from our
model, and settle for just one-way messaging as *the* primitive in our
model. To a large extent the elegance of doing this is very appealing.
However, I find it hard to model the 'natural' request/response correlating
behaviour present in SOAP 1.1/ over HTTP as two independent one-way
messages. Two independent one-way messages are not naturally correlated.
Also, short of having HTTP client and server at both ends in the HTTP
binding it is problematic for send an arbitrary message at some arbitrary
time to a node that implements just the HTTP client side of a binding - 

1) If the underlying TCP/IP connection (supporting the HTTP interaction) is
dropped between request and response, there really is no way to address the
sender of the 'request' message.

2) The rate at which 'response' messages can be sent is restricted by the
rate at which 'request' messages can be sent, indeed, over the long term the
number of messages sent from A to B is greater than or equal to the number
of messages sent from B to A (where A is an implements an HTTP client and B
implements and HTTP server).

3) Treated as two independent one-way messages there really is on
request/response correlation. That is something that either we have to
introduce an XMLP Module for, or that we 'embed' in the definition of the
RPC mechanism for XMLP (or both). This is no all bad... for example a number
of folks were also talking about correlation of messages that were being
exchanged over different bindings, eg. correlation of a response received
over SMTP with a message sent over HTTP.

I my find myself a bit of a lone voice in support of explicitly modelling
request/response, and it may be that we scale back to just one-way
messaging. The message patterns that you list can certainly be built on top
of one-way messaging or request/response and one-way. 

For me the reason to include request/response explicitly is because, at
least to me, it seems to be the fundemental pattern of the underlying
protocol we are chartered to provide a binding for. I'd also note that you
can derive one-way from request/response by simply making the response
'null/empty' just as easily as constructing request/response as two one-ways
- but you then get the correlation for free when you want it.

Regards

Stuart

> -----Original Message-----
> From: Randy Waldrop [mailto:rwaldrop@webmethods.com]
> Sent: 05 March 2001 13:19
> To: xml-dist-app@w3.org
> Subject: [AMG] Other message patterns
> 
> 
> The Abstract Model does a good job of describing the following
> messaging patterns:
> - one-way (fire-and-forget), and 
> - request/response one-for-one. 
> 
> But I don't see that it covers some of the other patterns that
> are required in our model. For example:
> - single request, a fixed nubler of responses.
> - single request, zero-to-N responses (publish/subscribe).
> 
> Am I missing something, or should the model be expanded to cover
> these patterns?
> 
>   Randy Waldrop
>   webMethods, Inc.

Received on Monday, 5 March 2001 11:17:13 UTC