RE: FW: LC Comments: Web Method Feature

> -----Original Message-----
> From: []
> Sent: 03 July 2002 16:54
> To: Williams, Stuart
> Cc: 'Mark Baker'; '';
> Subject: RE: FW: LC Comments: Web Method Feature
> Stuart Williams writes:
> >> 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).
> As you know, I think the design is fine as it stands.  The reason we 
> disagree seems to be this:  you seem to feel that the application visible 
> functions provided by a binding should be limited exactly the union of the

> features (including MEPs) implemented, with no further constraints of 
> conventions allowed.  I disagree. 
> I believe that any features should be used as documented.  The current 
> HTTP binding does this.  All uses of req/resp are legal per the spec for 
> that MEP, and the same for SOAP Response.

At present as specified one can successfully use either MEP with any HTTP
method and there is nothing in the binding specification that constraints
this and only discouraging words in the Web Method feature about the use of
anything other than GET with SOAP-Response and POST (and perhaps PUT) with

At present no behaviour is specified for the HTTP binding if the Web Method
feature is not used at all.

> Likewise the Webmethod feature 
> is used correctly.   Furthermore, I note that the two MEPs both use 
> reqres: for their properties, which signals to me an intent that a degree 
> of polymorphism is intended in the interface to the two.   In other words,

> applications need not always be aware of which one they are using.  I 
> believe this was intentional.

Must admit that I noticed this and found it mildly awkward (but not enough
to offend)... it suggests to me that the reused properties are perhaps more
globally useful and that their naming should perhaps be 'rooted' in context:
rather than in the name of the exchange pattern.

I think in part that what was intentional was a degree of economy in the
pages used to describe the binding and features.

I think as in general, if MEPs are an important concept, all participants in
a exchange should be able to determing correctly what MEP is in use.

> Most importantly, tou indicate that the additional constraints imposed by 
> the binding (I.e. the binding chooses to reject particular combinations of

> Web Method and MEP) are a "different (undefined) feature."  They are 
> arguably not a feature, but they are surely defined in the specification 
> for the HTTP binding.

There are no combinations of method and MEP that our binding, as defined,

> So where we differ is:  I believe that it's OK for 
> a binding to have its own semantics and interfaces in addition to those 
> provided by the features implemented.

That would be fine... but I would abstract them as binding specific features
and describe then as such within the context of a binding specification.

> For example, I would have no 
> problem if the http binding required some properties named http:xxx and 
> acted on those properties.

That more tricky. Essentially you are introducing a notion of
"mustUnderstand" features which I do not believe we have had. Ie. in order
to *use* this binding you "mustUnderstand" some particular features that it

At present the HTTP binding states:

"An implementation of the SOAP HTTP Binding MUST support the following
feature:" (see 6.4 Web Method
Specification Feature)"

I take that to be a statement about the *provision* of the feature (which is
fine), not about its *use*.

> I agree that the explanation in the HTTP binding would benefit from some 
> editorial clarification.  I strongly disagree that the Webmethod should be

> inferred from an MEP.

My proposal [1] does not say that (at least not as emphatically as you
appear to suggest). 

At the initiator it proposes that:

  If the Web Method feature is *used* it takes precidence. 
  If the Web Method feature is *not* used the an MEP dependent default HTTP
method is used, GET for SOAP-Response, POST for Request-Response.

For the responding node I have made no proposal. Philosopically I think it
is wrong that it is not possible for the recipient to accurately determine
the MEP is use, although (GET | HEAD | DELETE) => SOAP-Response and (PUT |
POST) => Request-Response seem reasonable and pragmatically I could live
with that.

> I think it is reasonable to infer the MEP from the 
> method.

This feels like two sides of the same coin in some sort of constraint/logic
programming language.

> This follows from the nature of what each of these conveys.  In 
> general, there are lots of methods that could be used with a given MEP. 

But not all bindings support the concept of Web Method and the MEP features
have semantics that are defined independent of the use of Web Method. If the
use of a binding chooses not to use Web Method... the MEP if supported by
the binding should (IMO) function as adverstised.

> For example, if we decide to support PUT (and it is essentially allowed 
> but discouraged) then that would almost surely join POST as a user of 
> request/response.

I agree... and what I propose does not prohibit that.

> On the other hand, I see no strong reason to use 
> multiple MEPs for a given method.  

:-) and whether MEP or Method has primacy will depend upon where you want to
be on the chamelon / messaging / tunnelling axis.

> GET is naturally a Response only,  and 
> I suspect DELETE is as well.  PUT and POST seem to be request/response. 

I don't think we disagree on that... although I would like to think that we
could count on SOAP-Reponse to be safe which likely excludes it use for

> Thank you!
> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142

Best regards


Received on Wednesday, 3 July 2002 13:19:14 UTC