RE: comments on 30/3/2001 AM draft

Hi Chris, Jean-Jacques,

> -----Original Message-----
> From: christopher ferris [mailto:chris.ferris@east.sun.com]
> Sent: 03 April 2001 11:59
> To: Jean-Jacques Moreau
> Cc: 'xml-dist-app@w3.org'
> Subject: Re: comments on 30/3/2001 AM draft

<snip/>

> > > 3) In section 3.1.3, the assertion that the Correlation parameter
references
> > > a message previously forwarded seems to eliminate the possibility that
> > > a message might be related to another that takes an alternate path
between
> > > source and destination. e.g.
> > >         a->b->c and c->d->a   [...]
> > 
> > Unless the MessageRef parameter is initially set by the originator? (and
intermediaries use
> > (originator, MessageRef) to correlate messages).
> > 
> > Alternatively, the path may be set to:
> >         a->b->d->c and c->d->b->a
> > with d being transparent on the way forward, b on the way back.
> 
> Yes, but my point was that MessageRef is a "local reference" or "handle"
> as Stuart has stated in previous postings. My question is then, where/how
does the
> intermediary get this from if the message has never passed this way
before?
                                    ^^^^^^^
I doesn't... which I think was my answer to your earlier posting. Is this a
gotcha? That may depend on your point-of-view.

The original AM modelled the services of XMLP as a one-way operation and a
request/response operation. In some quarters there was stong rejection that
request/response should be part of the model. Every time I thought about the
simple removal of request/response from the model I could not bring myself
to do it because of a nagging doubt that to do so would remove something
else that mattered. That's what led to [1] and what followed.

Perhaps the problem is the relabeling of Causality as Correlation which I
did in response to the early feedback I got on [1]. In your earlier message
Chris, you refer to Correlation in the context of longer running
conversations and I think I agree that that has different intent from what I
originally named Causality

I think one of the things we are dealing with here is the difference between
abstraction and layering. I certainly believe that you can build
(engineer/layer) request/response ontop of pure one-way messaging - but I
think you have to introduce some syntactic elements to support that. What I
don't think you can do is generate a request/response abstraction from a
pure one-way abstraction.  However, I do think that you can abstract
request/response from one-way messaging with causality - basically could
describe a stateful adaptor that converts from one-way with causality
event/primitive sequence to a request/response event/primitive sequence - I
haven't done this and probably I should.

> I suppose that one could argue that if an intermediary hadn't seen the
message
> before, then the MessageRef would be meaningless to it, but I think I
could
> make a case otherwise. Certainly, as a designer of an intermediary, I
might
> make that mistake and wind up with software that didn't function correctly
> some of the time.

Maybe we should return the term Causality which is what I called it
originally the concept. It's primary purpose is to denote a given message
having arisen as a direct consequence of the processing of another message.

> > 
> > I agree with your other comments.
> > 
> > Jean-Jacques.

Regards

Stuart

Received on Tuesday, 3 April 2001 10:12:17 UTC