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

Re: [AMG]: Causality: A possible remedy to our one-way, request/r esponse debate.

From: Glen Daniels <gdaniels@allaire.com>
Date: Fri, 23 Mar 2001 19:17:05 -0500
Message-ID: <034a01c0b3f7$c28405a0$0b00a8c0@gamebox>
To: "Williams, Stuart" <skw@hplb.hpl.hp.com>, "Henrik Frystyk Nielsen \(E-mail\)" <frystyk@microsoft.com>
Cc: <xml-dist-app@w3.org>

I like this a lot, and I'm glad to see you grok the zen of the monistic (as
opposed to monastic :)) one-way operation.

Two comments:

1) I think your notion is right on, but why not just call it "correlation"?
"Causality" doesn't seem as clear to me, and it implies, I think, a bit more
about the relationship of the messages than "correlation" does.  (I can't
think of a particular non-causal example of this type of correlation,
though, I just like the term better.)

2) The "sequence" idea might be something you want to tease out into a
separate concept - it's certainly useful in the multi-response scenario, but
wouldn't it be equally useful for a series of related messages being sent
from a client to a server, say?


----- Original Message -----
From: "Williams, Stuart" <skw@hplb.hpl.hp.com>
To: "Henrik Frystyk Nielsen (E-mail)" <frystyk@microsoft.com>
Cc: <xml-dist-app@w3.org>
Sent: Friday, March 23, 2001 4:33 PM
Subject: FW: [AMG]: Causality: A possible remedy to our one-way, request/r
esponse debate.

> Henrik,
> I have had some further thoughts centred on our discussion of the "one-way
> only" v "one-way plus request/response" issue which I think might lead to
> resolution of the issues. The thoughts below are also probably closely
> related to the [i44] thread on correlation and transaction IDs [3] - which
> have not been paying close enough attention to.
> Anyway, let me know what you think and whether you too think this is a
> (pun intended) can resolve or respective issues.
> Best regards
> Stuart Williams
> --
> Thoughts on one-way v one-way+request/response
> ----------------------------------------------
> Q. What would we loose if we removed the XMLP_DATA operation from the
> abstract service model?
> A. Causality.
> Q. Can we introduce causality into a one-way messaging primitive?
> A. Yes... (at least I think so).
> So that's the very short version!
> To elaborate a little further, in request/response, causality is very much
> part of the semantics of the operation. The response message is causally
> dependent on the request. No request, no response. No response without a
> request. In SOAP 1.1 over HTTP the causality inherent in the http POST
> request and response is exploited to provide correlation at least when
> is being used for RPC, if not more generally.
> So how might we introduce causality into the UNITDATA operation (which
> currently defines the following 3 primitives):
> XMLP_UnitData.send( To, [ImmediateDestination], [OrigPath],
> [{Headers}], [{Bodies}], [{Attachments}], [BindingContext]);
> XMLP_UnitData.receive( To, From, [OrigPath], [ActualPath],
> [{Faults}], [{Headers}], [{Bodies}], [{Attachments}], [BindingContext]]);
> XMLP_UnitData.status( Status, [{Faults}], [BindingContext]);
> I'm going to dispense with the OrigPath/ActualPath parameters for now just
> to avoid stepping into that problem. I'm also going to collapse Faults,
> Headers, Bodies and Attachments into a single parameter Message that has
> fields Message.Faults, Message.Headers, Message.Bodies and
> Message.Attachments. Then I'm going to introduce a Causality parameter
> has at least Causality.MessageRef and could have Causality.Sequence (which
> I'll mention a bit later on). In summary:
> XMLP_UnitData.send( To, [ImmediateDestination], Message,
> [Causality], [BindingContext]);
> XMLP_UnitData.receive( To, From, Messsage, [Causality]
> [BindingContext]]);
> XMLP_UnitData.status( Status, [{Faults}], [Causality]
> [BindingContext]);
> [Need to think some more about abstraction of Faults, are they actually a
> particular sort of Message?]
> In .send, Causality.MessageRef is a local (local, abstract) reference to a
> previously received message that gives rise to the message being sent. In
> .receive the Causality.MessageRef is a (local, abstract) reference to a
> previously sent message the processing of which the received message is a
> direct consequence.
> The *mechanism* by which causality is determined is *NOT* specified in the
> AM. It may be through the exploitation of features in the underlying
> protocol eg. the request/response nature of HTTP; It may be through
> mechanism introduced either by the XMLP processor to operate across
> possible underlying protocols eg. the inclusion of a header entry like
> <c:Causality c:msgID="myMsg1234" c:CasualMsg="yourMsg5278" c:Msgseq="1"/>;
> It may be something that a binding for a particular underlying protocol
> introduces within the domain of the underlying protocols own header
> extension mechanism.
> What is this Causality.Sequence thing? It's just think a little ahead to
> your multicast question and to the request/multi-response question. The
> sequence is to index (order) causal responses from the same responding
> source. It deals with potential misordering, it distinguishes duplicates
> it spots holes in the sequence.
> Personally, I believe that this gives us a more primitive and flexible
> service interface that enables one-way messaging and retains the causality
> inherent in request/response.
> A couple of SOAP questions:
> Your presentation [1] indicates that the HTTP POST response can be empty
> (slide 31) - although the last major bullet says: "SOAP response doesn't
> require SOAP request."
> Is it the case with the SOAP/HTTP bindings that any SOAP message carried
> the POST response MUST be causally dependent on the SOAP message carried
> the corresponding HTTP POST request? The introductory paragraph in section
> 6. [2] of the strongly imply this and *do* talk in terms of "SOAP request"
> and "SOAP response" outside of the RPC conventions.
> [1] http://www.w3.org/2000/xp/Group/Admin/minutes-oct1100/soap-xp-wg.ppt
> [2] http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383526
> [3] http://lists.w3.org/Archives/Public/xml-dist-app/2001Mar/0115.html
Received on Friday, 23 March 2001 19:17:42 UTC

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