- From: Williams, Stuart <skw@hplb.hpl.hp.com>
- Date: Fri, 6 Jul 2001 11:27:53 +0100
- To: "'Henrik Frystyk Nielsen'" <henrikn@microsoft.com>
- Cc: xml-dist-app@w3.org
> -----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