- From: Williams, Stuart <skw@hplb.hpl.hp.com>
- Date: Wed, 3 Jul 2002 16:23:00 +0100
- To: "'Mark Baker'" <distobj@acm.org>
- Cc: "'xml-dist-app@w3.org'" <xml-dist-app@w3.org>
Hi ya Mark, Just zipping to the end first... > They're orthogonal until an underlying protocol is bound, which > introduces implementation details that may impact the ability of a MEP > to be supported. Hence "a priori orthogonal". I think that this is the crux of where we disagree. IMO the position you hold undermines the whole point of the framework. A binding spec describes *how* to make use of the underlying protocol to honor the semantics of the features (inc. MEPs) that the binding specification requires implementations of that binding to support. If the binding specification or implementation introduces further constraints that aren't part of the relevant feature/MEP definition then it is implementing a different (undefined) feature from the one that it is claiming to implement (IMO). Clearly, you can fix this by modifying the relevant feature/MEP definitions to match the binding behaviour (I think this is your preference but not mine). Or you and fix the binding definition to honor the feature/MEP definitions (this is my preference, but I think not yours). Continuing below... > -----Original Message----- > From: Mark Baker [mailto:distobj@acm.org] > Sent: 03 July 2002 15:03 > To: Williams, Stuart > Cc: 'xml-dist-app@w3.org' > Subject: Re: FW: LC Comments: Web Method Feature > > > Hey, > > On Wed, Jul 03, 2002 at 09:42:44AM +0100, Williams, Stuart wrote: > > Clearly our opinions differ... > > > > If the user of a binding (a SOAP processor) has access to a binding within > > it's local environment and that binding claims to support a given MEP that > > the binding user understand then IMO it should be able to make use of that > > MEP successfully without regard for other features supported by the binding > > that the binding user either does not understand or chooses not to use. > > Mostly, yes, but modulo the restrictions on the MEP implicit in the > implementation of the underlying protocol. On this we disagree... the job of the binding (IMO) is to specify how to make use of the underlying protocol to provided the features/MEPs in accordance with the relevant feature/MEP specifications. Constraints on combined use should be evident in the feature/MEP specifications (indeed the spec says MUST [1]). > For example, the > Request-Response MEP doesn't make much sense for HTTP 1.1 GET or DELETE, > because neither can transfer a SOAP envelope on a request. At least on that we agree ;-) > > IMO, as currently written in the HTTP binding, the user of the SOAP-Response > > and Request-Response MEPs need to understand and use the Web Method feature > > in order to successfully use these MEPs. IMO this is a mistake and breaks > > the intent of the framework. Neither MEP specification indicates a critical > > dependency on use of the Web Method feature, which is correct IMO. > > Good point. I disagree with you, but I think that we should say > something about the dependancy. The Web Method feature does say something of its affect on the two MEPs, but the MEPs are (rightly IMO) spec'd without reference to the Web Method feature. Binding users that understand either MEP and not the Web Method feature should still be able to make effective use of the binding because (rightly IMO) the expectation is there that they can make successfully use the MEPs they understand without *having to* understand other features that the binding supports. Your bias is I believe is to fix the feature spec, mine is to fix the binding spec (btw, dispite the volume of mail and degree of passion hear, it is not very broken :-)). > > The Web Method feature allows for binding users that understand it to make > > use of it... that's fine... It happens that support for the Web Method > > Feature is mandated for the HTTP binding in Part 2 and binding users that > > wish to use it are free to do so. Equally, binding users that do not > > understand it or choose not to use it should also be free to do so. > > > > As for 'a priori' othogonal (although I'm not sure what you intend to > > communicate with the 'a priori' prefix)... > > See below. > > > Should I be able to use PUT,POST > > or DELETE in conjunction with the SOAP-Response MEP (and if so, how is a > > responding SOAP node to determine that the SOAP-Response MEP is in > > operation)? > > I'd say that you should be able to use it with all those methods. > > I'm not sure why the responding node would need to know which MEP was in > use though, at least when bound to an application protocol. Two answers, one philosophical, one practical(ish): 1) If MEPs are an important concept and a pair of nodes are involved in the operation of a message exchange, both should be able to determine correctly what MEP is being used for the message exchange. It is a piece of information that should be transferred either explicitly or implicitly by the operation of the binding. 2) In the case of say a TBD one-way send/push MEP which transfers a single SOAP message from initiator (sender) to a recipient, its kind of hand for the binding to know that no SOAP response is expected from upstairs and it can complete the message exchange without waiting for a response message (because none will be forthcoming). > In that > case, the MEPs exist to describe the combination of the implicit MEP- > impacting features of the protocol, plus how its abstracted for the > developer. You might like to expand on this ("implicit MEP-impacting features") some more. I have a feeling that if you bottom out on that you will find yourself wanting to define features and MEPs that are a little (and I do mean a little, not a lot) different from the ones we have actually specified. eg. is expect that it might head toward an HTTP-SOAP-Request-Response MEP and an FTP-SOAP-Request-Response-MEP etc. with each MEP sprouting features that are more specific to the underlying protocol being bound, but that are individually much less reusable in other binding specifications. > For example, neither HTTP, nor an HTTP server, needs to know > that the SOAP-Response MEP is in use in order to be able to respond to a > GET with a SOAP envelope. SOAP-Response is just an abstraction used to > permit clean separation of responsibilities at the sending node. > > >Should I be able to use GET in conjunction with the > > Request-Response MEP (and if so, how is a responding SOAP node to determine > > that the Request-Response MEP is in operation)? > > Not in conjunction with HTTP 1.1, since GET can't transfer a SOAP > message. Again, agreement... > But perhaps some future HTTP-like protocol with its own GET > could do that. But... why would such a protocol ever need to do that to implement the same semantics as HTTP GET... I mean... if we start putting things in the body of the request aren't we identifying resources by means other than URI ;-) > > And if there are > > restrictions on Web Method usage in combination with particular MEPs how > > then are they "orthogonal"? > > They're orthogonal until an underlying protocol is bound, which > introduces implementation details that may impact the ability of a MEP > to be supported. Hence "a priori orthogonal". Back where we started... see above. > MB > -- > Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) > Ottawa, Ontario, CANADA. distobj@acm.org > http://www.markbaker.ca http://www.idokorro.com > Regards Stuart -- [1] http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#bindfw In cases where multiple features are supported by a binding specification the specifications for those features MUST provide any information necessary for their successful use in combination; this binding framework does not provide any explicit mechanism for ensuring such compatibility of multiple features.
Received on Wednesday, 3 July 2002 11:23:29 UTC