W3C home > Mailing lists > Public > xml-dist-app@w3.org > March 2001

RE: Causality/Correlation

From: Williams, Stuart <skw@hplb.hpl.hp.com>
Date: Fri, 30 Mar 2001 09:38:39 +0100
Message-ID: <5E13A1874524D411A876006008CD059F192378@0-mail-1.hpl.hp.com>
To: "'marwan sabbouh'" <ms@mitre.org>
Cc: xml-dist-app@w3.org
Hi Marwan,

> -----Original Message-----
> From: marwan sabbouh [mailto:ms@mitre.org]
> Sent: 30 March 2001 00:04
> To: Williams, Stuart
> Cc: xml-dist-app@w3.org
> Subject: Re: Causality/Correlation
> Hi Stuart
> Thanks for discussing the issue.  My comments are below.
> <snip>
> Point is it isn't right now and SOAP/HTTP delivers 
> that functionality now - which is why it entered the model in 
> the first
> place.
> </snip>
> let us be more precise.  is it Soap that delivers the functionality or
> is it http? (http)

When you are sitting on top of XMLP it shouldn't matter to you whether it is
SOAP or HTTP or SMTP or BEEP that delivers the functionality you. All that
should matter is that you are presented with an abstraction (at the top of
XMLP) that exposes the functionality. The service model is about that
abstraction, its not about the underlying mechanism.

> <snip>
> *IF* you are going to go for one-way 
> messaging as an abstraction of *WHAT* you do (the service that you
> provide)
> that's what you have to stick with. You send a message in one side and
> (with
> reasonable probablity) it comes out the other end. It may leap-frog
> eariler
> messages, it may get lost. That's pretty much all you should have to
> know
> </snip>
> I am sorry but I do not agree with the above.  I think if u model it as
> a one-way message, the message can still be delivered reliably, and in
> order.  The underlying transport protocol could ensure that.  In this
> fashion, from an XMLP perspective, there is only one message. 
> However, the transport protocol would exchange multiple messages on 
> the wire to make that happen.

Even if a transport mechanism delivers messages in order down one hop
between XMLP intermediaries that does not give you guarantees that them
messages reach the ultimate recipient in order or at all. We have no
constraints that prevent them being lost or mis-ordered at intermediaries
and we currently have no end-to-end mechanisms (other things an application
might put in the message because it has no strong guarantees) that recover
from message loss or re-ordering.

There are some interesting questions (which should probably go do another
thread) about the relationship between the delivery semantics at the
ultimate recipient and at intermediaries. 

1) Do all messages between the same original sender and ultimate recipient
take the same path through intermediaries?
2) Is the delivery semantic at intermediaries the same as at the ultimate
recipient - eg. reliable and in order?

> My preference is for one way only.  But I can live with the 
> decision of the group.
> thanks again
> Marwan

I too will go with the flow.

Best regards and thanks,

Received on Friday, 30 March 2001 03:38:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:12 UTC