RE: [AMG] Other message patterns

Stuart,

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

I don't believe it's realistic to define a one-way message without defining
some means to
indicate exceptions during the one-way communication. Even Ethernet, which
is
largely one way, has the ability to throw an exception (collision detected)
during a
one-way broadcast. I believe the AMG must accommodate "reverse direction"
exception reporting
associated with a one-way message.



Dick Brooks
Group 8760
110 12th Street North
Birmingham, AL 35203
dick@8760.com
205-250-8053
Fax: 205-250-8057
http://www.8760.com/

InsideAgent - Empowering e-commerce solutions

> -----Original Message-----
> From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org]On
> Behalf Of Williams, Stuart
> Sent: Monday, March 05, 2001 10:16 AM
> To: 'Randy Waldrop'; xml-dist-app@w3.org
> Subject: 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 13:17:59 UTC