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

Stuart:

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?

--Glen

----- 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
a
> resolution of the issues. The thoughts below are also probably closely
> related to the [i44] thread on correlation and transaction IDs [3] - which
I
> have not been paying close enough attention to.
>
> Anyway, let me know what you think and whether you too think this is a
path
> (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
SOAP
> 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
sub
> fields Message.Faults, Message.Headers, Message.Bodies and
> Message.Attachments. Then I'm going to introduce a Causality parameter
that
> 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
multiple
> 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
and
> 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
in
> the POST response MUST be causally dependent on the SOAP message carried
in
> 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