RE: Other message patterns

Hi Mark,

> -----Original Message-----
> From: Mark Nottingham [mailto:mnot@akamai.com]
> Sent: 12 March 2001 20:34
> To: Ray Denenberg
> Cc: xml-dist-app@w3.org
> Subject: Re: Other message patterns
> 
> Is it useful and good to hide that complexity?

I think so... I've also noticed a propensity to stick 'S' on the front of
acronyms lately where S = Simple :-).

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

Would you care to enumerate "a lot of assumptions"? Even just a few that are
more obvious big ones?

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

Good... that is indeed what it does!

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

I'm not sure I'd regard it as 'relegation' which seems a bit value laden.

One-way is there as a first-class construct too - there is no sense of one
being superior to the other.


> OTOH, removing XP_Data means providing some way to express the
> correlation of messages, either through a module or implicitly in the
> transport binding. 

Any suggestions as to how you would express that in an abstract model - the
notion that one message is causally dependent upon an earlier message - how
would you show or describe that in an abstraction of WHAT XML protocol does
- not a description of HOW it does it.

> This would allow the definition of
> request/response for applications that need it (e.g., RPC) by
> building on top of unidirectional messaging.

That's a HOW thing, not a WHAT thing. 

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

So... I'm building an application on top of XMLP... what am I to rely on
XMLP doing for me? Can I rely on it to correlate responses with request for
me. Say an application sends these two messages...

Message 1:
	<env>
	  <body>
	    <sqrtrequest>
	      <p1>25</p1>
	    </sqrtrequest>
	  </body>
	</env>

Message 2:
	<env>
	  <body>
	    <sqrtrequest>
	      <p1>16</p1>
	    </sqrtrequest>
	  </body>
	</env>

and later receives these two messages:

Message 3:
	<env>
	  <body>
	    <sqrtresponse>
	      <p1>4</p1>
	    </sqrtrequest>
	  </body>
	</env>

Message 4:
	<env>
	  <body>
	    <sqrtresponse>
	      <p1>5</p1>
	    </sqrtrequest>
	  </body>
	</env>

With just on-way messaging there is no way of knowing whether messages 3 & 4
are in anyway a consequence of messages 1 or 2 and if so, which of 3 & 4 is
dependent on 1 or 2.

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

My current view is that I personally would like to leave section 3 largely
as is. There are folks who would like to see it changed. I think what I need
are concrete proposals for changes or alternate presentations that the AMG
subgroup in the first instance can make choices about.

Unless I have concrete proposals for changes that can be used as a means to
develop concensus... we might be a little 'stuck'.

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

So... this describes the shape of a proposal you might make. I think that
you need to do the work of drafting the reorganisation that you propose... I
can't do that for you... present it to the group and  participate in the
discussion.

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

And what would the reader be expected to assume from model that presented
just one-way lossy messaging?

> 
> Cheers,
> 

Regards

Stuart
<snip/>

Received on Wednesday, 14 March 2001 05:42:46 UTC