Re: Other message patterns

What kind of error messages are being envisioned? I would think that
transport-level errors (i.e., the transport failed to deliver, or
failed to find a valid endpoint) must be relayed back to the sender
by transport-specific means; some will not provide them, but
application developers will need to take this into account when they
choose their transports.

Application-level errors (XML parsing errors or something higher)
might need to go back to the sender, but the application/service
designer may want to collect them at the receiver, or send them
somewhere else, or discard them. 

Isn't this just another facet of correlation; when a reciever
needs to send an exception back to the sender, the application needs
to allow this through thier choice of transport binding and/or
message correlation mechanism?


On Mon, Mar 05, 2001 at 12:12:41PM -0600, Dick Brooks wrote:
> 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.
> >

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

Received on Wednesday, 7 March 2001 21:53:30 UTC