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 16:33:17 UTC