Re: Other message patterns

Is it useful and good to hide that complexity? It seems to me that
there are a lot of assumptions about both the transport binding and
the higher application built into 'request/response', and that the
function of an abstract model should be to tease these out.

I don't dispute that request/response is useful to model, or that the
AM should provide a means of modeling this extremely common pattern
of messages. I do wonder at making it a first-class construct;
indeed, the AM models request/response as 'XP_Data', relegating a
unidirectional message to 'XP_UnitData'. 

OTOH, removing XP_Data means providing some way to express the
correlation of messages, either through a module or implicitly in the
transport binding. This would allow the definition of
request/response for applications that need it (e.g., RPC) by
building on top of unidirectional messaging. Such correlation could
be provided by the transport or by a Module, and could also be used
for message exchange patterns other than request/response. IMHO this
is a much more appropriately abstract and modular solution for an
abstract model.

Providing this kind of solution would require rewriting substantial
parts of the AM; easy for me to go on about, since I don't have to do
it (I will try, but I know Stuart's working to a deadline). 

Unless someone comes up with a replacement, I'd propose that the AM
be reorganised to clearly delineate between 'Core' XML Protocol
message concepts and those useful in a request/response situation; by
this, I mean separating them both structurally with major sections
and with prose.

One of our core requirements, straight from the charter, is:

   The envelope and the serialization mechanisms developed by the
   Working Group may not preclude any programming model nor assume
   any particular mode of communication between peers.

My main concern is that readers of the Abstract Model will see that
XML Protocol provides two kinds of services - one-way lossy messaging
and request/response - and not realise the other modes of
communication possible. The request/response features of the AM are
very useful to RPC and Web Services, but shouldn't colour the core
protocol's model.

Cheers,




On Mon, Mar 12, 2001 at 02:34:42PM -0500, Ray Denenberg wrote:
> Jean-Jacques Moreau wrote:
> 
> > "Williams, Stuart" wrote:
> >
> > > I happen to believe that it (request/response) is and should be
> > > primitive in our case [...]
> >
> > I agree.
> 
> If we're weighing in on this, I agree too.
> 
> Earlier, the discussion of this seemed to focus on the question
> "can we model 'request/response' in terms of a single (one-way)
> primitive?" (i.e. prove it). I think that's the wrong question,
> because I think the answer is clearly, we can. I think the relevant
> question is "at what cost?" , in complexity, that is. The
> request/response pair allow you to model a single abstract
> state-machine (multiple concurrent RPC transactions are implemented
> as multiple instances of the single state machine). With a single
> primitive, you simply can't model this as a single state machine,
> and you have to expose the pairing of requests with responses. At
> best, the conservation of complexity principle applies here.
> 
> --Ray
> 
> 
> --
> Ray Denenberg
> Library of Congress
> rden@loc.gov
> 202-707-5795
> 

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

Received on Monday, 12 March 2001 15:34:13 UTC