W3C home > Mailing lists > Public > xml-dist-app@w3.org > July 2002

RE: FW: LC Comments: Web Method Feature

From: Williams, Stuart <skw@hplb.hpl.hp.com>
Date: Wed, 3 Jul 2002 16:23:00 +0100
Message-ID: <5E13A1874524D411A876006008CD059F04A06EF6@0-mail-1.hpl.hp.com>
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 GMT

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