RE: comments on 30/3/2001 AM draft

Hi again Chris,

What time zone are you on! ;-> I'm out of here today at 5pm local.

> -----Original Message-----
> From: christopher ferris [mailto:chris.ferris@east.sun.com]
> Sent: 03 April 2001 13:34
> To: 'xml-dist-app@w3.org'
> Subject: 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.

Yes... this one had been nagging around a little. I think that in a practial
API (as opposed to an abstract model) you indicate which messages you
anticpated responses for and you would indicate when you had 'lost' interest
in causal responses (either because you knew that you had them all - or
because you had given up waiting). I think this is mostly a practical
consideration... but I'd be interested in your thoughts.

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

Personnally, I too would like to see much better resolution of this strand
of the discussion (modules, handlers, targetting, message routing and
message processing). 

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

Do you have any possible avenues of exploration to suggest? I would be very
willing to engage in further discussion of this topic. As I've said
previously, I've resolved my own feeling of awkwardness on this down to what
I called Causality... but if you have some other angles to suggest I'd be
happy those some thought too.

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

"...This..." the indirect reference... could be "yes... this is angels on
pinhead stuff!" :-); could be "yes, I agree abstracting request/response
from pure one-way doesn't does seem problematic without introducing further
syntactic constructs"; could be "yes... further syntactic support is exactly
the right way to be going..." ;

Don't mean to be picky, I have the sense that we might be agreeing loudly!

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

Thanks.

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

Best regards,

Stuart

Received on Tuesday, 3 April 2001 11:13:01 UTC