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

Henrik Frystyk Nielsen wrote:
[...]
> 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.

This is much better put than my attempt:
  http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2001Mar/0139.html

I'm particularly interested in the case where a protocol may have
multiple 'shapes', such as BEEP. I imagine we may have to define
multiple bindings for BEEP to cover this, but if I read it correctly,
this is the intent in any case, as BEEP is a protocol framework, not
a protocol.

In any case, it's important to separate XMLP MEP and transport MEP.


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

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

-- 
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA USA)

Received on Saturday, 24 March 2001 00:15:47 UTC