Re: comments on 30/3/2001 AM draft

Stuart,

Thanks for the comments. Some follow-up below.

Cheers,

Chris

"Williams, Stuart" wrote:
<snip/>
> 
> So I think the short answer to both your questions (if I have understood
> them) is yes - because the message reference in the Correlation parameter is
> a local reference to a message that the node in question has already seen.

Okay, then I understood correctly. However, I think that this does still
need to be made clearer. Another point that this raises is the potential
for imposing persistence requirements on an implementation. 

> 
<snip more="true"/>
> 
> I hope that that concern is captured in Issues 2 and 3 at the beginning of
> the document.

Yes, it does, but I think that a first WD should have addressed this
particular issue. The document as it stands is too ambiguous and at
times
inconsistent in its use of these terms. The same could be said of the
SOAP1.1
spec itself IMHO.

> 
<snip more="true"/>

> 
> > 11) Finally, I think that there needs to be some discussion/exploration as
> regards
> > the ability for one node to communicate to another(s) what MEP (message
> exchange pattern)
> > is to be employed. In this regard, processing of a one-way messasge may be
> very different than
> > that used for a request/response pattern (e.g. RPC) carried over a
> synchronous
> > communications protocol such as HTTP.
> 
> Earlier versions of the document did have an explicit correlated
> request/repsonse operation which personally I was not unhappy with although
> others were. This lead to the thinking (ironcally on my part) reported in
> [1] which lead to the major changes in section 3.

Yes, I was following that discussion. My own preference for one-way
messaging lead me initially to remain silent on the matter, but as I
review the AM, and based on my experiences with ebXML, I am becoming
more inclined to believe that while at one level, r/r *can* be  layered
over oneway messaging, there is something lost in translation that
makes it a bit awkward. I think that what is needed is to fully explore
what is needed to ensure thet r/r semantics can be mapped without loss.

I don't believe that this issue has yet been fully explored.

> 
> > In fact, at the abstract layer, I do think that it is worthwhile calling
> out the distinction
> > between oneway and request/response and this needs to be (somehow) able to
> be
> > communicated through the whole stack (e.g. from the sending application
> through to the
> > receiving application). While it is quite true that one can construct the
> equivalent
> > of request/response with oneway messaging, there seems to me  to be quite
> a bit of
> > information that needs to be communicated through the stack to ensure that
> the
> > pattern is correctly satisfied by the layers of software supporting the
> exchange.
> 
> This probaly is angels on a pinhead stuff, but I actually don't believe that
> you can do request/response ontop of pure one-way messaging without
> introducing (possibly standardised) 'application' specific syntactic
> elements into the message that explicitly enable such correlation - ie. you
> have to apply some semantics to the payload.

Yes! This is exactly my thinking.

> 
> Thank you again for your full and thorough review of the AM document.
> Unfortunately (depending on your POV) I'm taking some vacation, so I won't
> be able to persue much further discussion until late April.

Have a nice holiday;-)

> 
> Best regards
> 
> Stuart
> 
> [1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Mar/0216.html