RE: Protocol Bindings

> -----Original Message-----
> From: Henrik Frystyk Nielsen [mailto:henrikn@microsoft.com]
> Sent: 05 July 2001 18:57
> To: Williams, Stuart
> Cc: xml-dist-app@w3.org
> Subject: RE: Protocol Bindings
> 
> 
> 
> >I think I and a number of others strongly believe that the 
> >purpose of a protocol binding IS to describe how to make use 
> >of a particular underlying protocol to transfer XMLP/SOAP 
> >messages. You seem to be stating that that is not the case.
> 
> What you state here is different from what you stated in the previous
> mail. Either the "purpose of an XML Protocol Binding is to provide rules
> for the transfer of XML Protocol messages over some specific underlying
> protocol" or "the purpose of a protocol binding IS to describe how to
> make use of a particular underlying protocol to transfer XMLP/SOAP
> messages."

Personally I think that both formulations say the same thing. If the second
communicates my intend more clearly to you, that's great.

> In the former description the binding provides the rules for the
> transfer, in the latter the binding describes how SOAP can use the
> underlying protocol's rules for transfer. I agree partially with the
> latter, I disagree with the former. What I pointed out in addition is
> that transfer rules can either be provided by the underlying protocol or
> they can be provided by some SOAP extension.

Could you elaborate further on both of these?

> It is important to keep in mind that SOAP core does not define any
> routing pattern or any message exchange pattern other than a one-way
> message and we should be very careful to separate what SOAP actually
> provides and requires of the underlying protocol from the features and
> services that applications using SOAP may deploy and use in addition to
> core SOAP.

I'm not sure why you repeatedly bring routing into a discussion on protocol
bindings. I can certainly see that MEP's and the delivery semantics of
underlying protocols have a bearing on bindings.

> >Your response seems to suggest that you expect the rule for 
> >transferring SOAP/XMLP messages to be intrinisic to an 
> >underlyling protocol already or defined within the domain of 
> >some SOAP/XMLP extension.
> 
> Given the core SOAP protocol as being effectively the envelope then I
> think that is the case. Can you provide a scenario where a SOAP binding
> would change the HTTP message exchange pattern for example? 

I have a feeling that we have our wire's crossed here... I can't see a
scenario in which a SOAP binding would change the protocol rules for HTTP,
indeed that is precisely what I think you think I am suggesting and it is
precisely *not* what I'm suggesting.

I can see that there are a number of ways in which a SOAP/HTTP binding could
make use of the services of the HTTP protocol: for example a truely one-way
means to use HTTP to transfer a SOAP message would be to use just the POST
request to carry a SOAP message and for the HTTP POST response to always be
empty (other than a status code). This would be a different way of using
HTTP, but it would not change HTTP or the message pattern intrinsic to HTTP.

BTW: I'm not suggesting this is how HTTP should be used to transfer SOAP
messages, I think HTTP offers very few design choices wrt to it's use to
transfer SOAP message. 

Another way in which HTTP could be used/could have been used to do say
request/multi-response would be to allow multiple SOAP messages to be
transferred in an HTTP POST response (possibly as arising as a direct
consequence of the SOAP message transferred in the corresponding HTTP POST
request). This again would 'alter' the SOAP MEP being supported, but would
in no way change the HTTP pattern.

> >The way I see it is that an underlying protocol *provides* some 
> >communication service(s). The rules of procedure of that underlying 
> >protocol define the mechanisms by which it *provides* those 
> >communication services. 
> 
> Actually, this doesn't really change the fact that SOAP core by itself
> defines no routing mechanism or message exchange patterns. I would be
> cautious applying too much of a layered view - especially as SOAP can be
> used in combination with a variety of underlying protocols that
> traditionally are seen as belonging to different layers.

Hey... I'm an unashamed layerist :-). If there's another style of model than
a traditional layered module please show me what it is, I'd like to be
educated.

> I much prefer the categorization proposed by Mark [1]
> 
> Henrik
> 
> [1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Jul/0015.html


Regards

Stuart

Received on Friday, 6 July 2001 06:28:00 UTC