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

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

From: Henrik Frystyk Nielsen <frystyk@microsoft.com>
Date: Tue, 10 Apr 2001 15:11:27 -0700
To: "'Mark Nottingham'" <mnot@akamai.com>, "XML Distributed Applications List" <xml-dist-app@w3.org>
Message-ID: <79107D208BA38C45A4E45F62673A434D0297CABC@red-msg-07.redmond.corp.microsoft.com>

Mark,

Sorry for the (huge) delay - here is the 2nd attempt - the thread is at
[1]

>> 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.
>
>Maybe it's just the terminology, but this is very confusing. I
>think I know what you mean, but it might be good to use a term 
>other than binding, or more fully explain this.

Ok, a more specific example is the SOAP MIME multipart related spec [2]
and see how that relates to the SOAP spec [3]. The SOAP MIME multipart
is effectively a protocol binding in its own right - it defines how a
SOAP message can be embedded within a MIME multipart related message and
how one can use URIs to refer to individual entity bodies within the
multipart message. 

However, MIME multipart is in itself not really a protocol - it is a
message description format and so it doesn't say where to send the
message etc. However, the MIME multipart binding can be nested to fit
within other protocols that support MIME entities. For example, one can
nest the SOAP/MIME multipart binding and the HTTP binding to get a
mechanism for exchanging the message.

The point about the RPC convention is that it has a lot in common with a
binding in that it imposes constraints on the SOAP message (what can go
in the body and in the headers) and also defines a message exchange
pattern: request/response.

However, similar to the SOAP MIME multipart binding, the RPC convention
doesn't actually provide a mechanism for exchanging messages. In order
to solve this problem, the RPC convention can be nested with the HTTP
binding or some other binding. In the case of HTTP, HTTP naturally
supports request/response. However, it doesn't support RPC as such and
therefore some of the conventions are expressed within the SOAP
envelope.

One could imagine nesting the RPC convention with other bindings like an
SMTP binding that doesn't support request/response. In order to
compensate, we could therefore define a module that took care of the
correlation between requests and responses.

As more an more modules get defined one can wonder whether SOAP
eventually won't "grow up" and simply become a complete protocol in its
own right with enough modules for handling the 80% case.

One can even imagine nesting the RPC convention within MIME multipart
within HTTP.
 
>> 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
>
>I'd go a bit further. One of the things that BEEP does is 
>separate the concept of who establishes the connection from 
>who originates exchanges; initiator/listener vs. client/server.
>
>We've been talking about message exchange patterns and the 
>flow of messages, but not how they relate to the establishment 
>of the connection to a 'service URI', although there has been 
>hand-waving about the service URI itself. Should we pick this 
>apart into a separate layer (service layer)?

Yes, I think that makes to do so. One reason for that is that we avoid
getting into the situation of having to define how to export endpoints.

Henrik

[1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Mar/0216.html
[2] http://www.w3.org/TR/SOAP-attachments
[3] http://www.w3.org/TR/SOAP/
Received on Tuesday, 10 April 2001 18:19:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:00 GMT