Re: Other message patterns

If we abstract (bad choice of words? ;) out the subtleties of RPC
(request-response) over HTTP (request-response) into a
'request-response' primitive, it seems to me that we'll be able to
model RPC-over-HTTP, but won't be able to leverage this to
other_MEPs-over-other_transports.

I'd think a robust abstract model should be able to encompass these
applications without catering to them specifically. The HTTP binding
was chartered because it was obvious, existant and convenient; I'd
argue that it wasn't put in to predispose the XMLP world to a certain
way of thinking.


On Mon, Mar 05, 2001 at 04:16:17PM -0000, Williams, Stuart wrote:
> 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.

-- 
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA USA)

Received on Wednesday, 7 March 2001 22:08:02 UTC