RE: [AMG]: Causality: A possible remedy to our one-way, request/response debate.

Thanks Stuart for writing this up!

>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.

The interesting thing here to note is that whenever we discuss the term
request and response in SOAP, it is in combination with the HTTP binding
or with the RPC convention. However, if we look at section 2 then it
says:

	SOAP messages are fundamentally one-way transmissions
	from a sender to a receiver, but as illustrated above,
	SOAP messages are often combined to implement patterns
	such as request/response.

How can we explain this? If we look at the SOAP envelope itself then
there is nothing that provides a mechanism for doing message
correlation, indication what is a request and what is a response, or how
responses may be returned in response to a request. There is the notion
of a SOAP fault but SOAP doesn't require that it be exchanged in a
request/response exchange pattern nor that it has to be exchanged at
all.

If we look at the RPC convention and the HTTP binding then the SOAP RPC
convention is independent from the HTTP binding and the two again are
independent from the description of the SOAP envelope. That is, it is
possible to use SOAP without doing RPC and doing RPC without using HTTP
as the underlying protocol etc. Section 7 expresses this as:

	Using SOAP for RPC is orthogonal to the SOAP protocol
	binding (see section 6). In the case of using HTTP as
	the protocol binding, an RPC call maps naturally to
	an HTTP request and an RPC response maps to an HTTP
	response. However, using SOAP for RPC is not limited
	to the HTTP protocol binding.

Although both the RPC convention and the HTTP protocol binding of the
SOAP specs talk about "requests" and "responses" there is a benefit in
keeping the two notions orthogonal. For one thing it allows us to
differentiate the HTTP protocol binding's use of request/response from
the RPC convention's use of request/response. Among other things this is
useful because HTTP is not an RPC protocol. HTTP defines what a request
is and what a response is and regardless of what you stick into an HTTP
request, it is still an HTTP request and the same is true for HTTP
responses. 

The main purpose of the SOAP protocol binding model is that it doesn't
prevent anybody from making bindings to a variety of underlying
protocols. In practice, this design goal was addressed by having SOAP
impose very few requirements on the underlying protocol -- effectively
the only requirement is that it can transfer a complete SOAP message. In
general, the protocol binding will also impose restrictions on SOAP
based on the features that the underlying protocol defines. These
restrictions are often more strict than the other way round. Therefore
the task of writing a protocol binding may be more a question of
determining the restrictions that the underlying protocol imposes on
SOAP than vice versa. A few examples of the questions that one has to
ask while writing a protocol binding are of the style

* Does the underlying protocol impose a message exchange pattern? 
* Does it impose restrictions in dealing with faults? 
* Does it impose restrictions on the size of a SOAP message? 

In the particular case of SOAP, HTTP "colors" the SOAP envelope with the
HTTP semantics including with the notion of a request and response.

The interesting thing is that the RPC convention imposes similar types
of constraints on the SOAP envelope - it talks about where to stick the
method call parameters and what the headers can be used for in the case
of RPC. In many ways, this is very close to a protocol binding but where
the HTTP protocol binding binds to an actual protocol (HTTP), the RPC
convention binds to an abstract "RPC protocol".

This is actually not new in that we in the MIME multipart binding also
binds to something that is not really a protocol (MIME). We also have
the notion of "nested" protocol bindings in that MIME multipart can be
used in combination with HTTP etc. Similarly the RPC "binding" can be
used over HTTP in which case the request/response maps directly to the
HTTP request/response. However, if we use the RPC "binding" over SMTP
then we have to compensate in order to get a request/response model and
we can do that by making a module that provides this functionality.

One way to look at this would therefore be to say the following:

1) A SOAP message is fundamentally a one-way message

2) A protocol binding enforces constraints on the SOAP envelope
including possible message exchange patterns and potentially what can be
in a message

3) The RPC convention is a protocol binding that describes a "binding"
to an abstract RPC protocol that defines the mechanisms needed for doing
RPC

4) Just as any other protocol binding, the RPC binding can be nested
with other protocol bindings. An example of a protocol binding that the
RPC binding can be nested with is the HTTP binding.

5) Not all protocol bindings provide the services needed by the RPC
binding. The HTTP binding happens to have a request/response model that
the RPC binding can use but this might not the case for an SMTP binding.

6) If these services are not met by the nested protocol binding, the RPC
binding can define a module that defines the necessary mechanism for
dealing with the services provided by the RPC binding. It can also
define it as part of the underlying protocol but I am not sure that
people typically will do that because it makes it much harder to change
bindings.

>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?]

Yes, but they are not inherently associated with a "response" as such.

>In .send, Casuality.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.

I think we are getting close - I like the notion that the AM can support
multiple causality models but doesn't define any. The interesting thing
is that once you talk about causality, it could be that I have to send
you 5 messages before you send me one - that is we have sender:receiver
relationships that include

	1:1
	1:m
	n:1
	m:n

And of course, there may be many "unrelated" messages flowing in
between. As a mechanism, is it possible to support these patterns if all
we have is a message correlation mechanism that the RPC guys are talking
about wanting as a module/block?

>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.

But now we get into QoS and reliability and it seems to me that if we
can show that you can build multiple message exchange patterns out of
the basic model then you can also build QoS.

>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.

To me this is because HTTP defines a request and a response and SOAP
can't change that at the model level. I know that many people play
tricks with HTTP but that is a different matter that we don't have to
include in our model.

>[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

Thanks!

Henrik

Received on Friday, 23 March 2001 21:12:27 UTC