- From: Williams, Stuart <skw@hplb.hpl.hp.com>
- Date: Fri, 30 Mar 2001 09:38:39 +0100
- 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, Stuart
Received on Friday, 30 March 2001 03:38:51 UTC