Re: Issue 169: Propose http method in the operation interface to simplify http binding.

On Tue, 29 Jun 2004 13:08:56 -0700
David Orchard <dorchard@bea.com> wrote:
> > From: Amelia A Lewis [mailto:alewis@tibco.com]
> > Sent: Tuesday, June 29, 2004 12:51 PM
> > On Tue, 29 Jun 2004 12:40:48 -0700
> > David Orchard <dorchard@bea.com> wrote:
> > > The changes to WSDL are:
> > > 1. WSDL interface operations contain optional webMethod attribute.  
> > > This is an HTTP operation name. 
> > 
> > Strongly -1.  We have worked hard to separate keep the 
> > abstract interface
> > abstract.  HTTP methods are binding-specific, not interface-level
> > abstractions.
> 
> An application designer that is using HTTP as a transfer protocol, such
> as Atom, knows that the interface in the "abstract" is generic.  I would
> be fine with calling it "ConstrainedMethod" or "RESTMethod" or somesuch,
> but the simplest seemed to be http.  Again, the separation of abstract
> from protocol is a leaky abstraction in many cases.  Having an optional
> attribute supports the right level of leakiness, rather than denying the
> leak exists.  

I don't agree, and I'm not convinced by the argument that "leaks exist,
let's poke another hole."

> And that anybody that is thinking of
> "Restricted Operations" at interface design time isn't thinking
> abstractly enough.  Is there another interpretation?

That sounds approximately like what I think I'm saying, filtered through a
different worldview.  I think.

> What did you think of my argument that this allows simpler bindings,
> especially the binding sans operation that I showed?

I think it's syntactic sugar, HTTP-specific, that places a burden on every
other binding.

> > By "per-binding," I mean that each binding specifies this; it 
> > isn't in the
> > WSDL namespace.  This is because HTTP semantics are not necessarily
> > mappable to the semantics of other protocol bindings.
> > 
> 
> I think I slightly quibble with the use of "namespace" here.  To test my
> understand of your words, I'll try to say what I think you said.  
> 
> Every binding to a protocol MUST specify the interpretation of the
> location if a location is specified.  In binding to HTTP, the
> interpretation is straightfoward.  Other bindings may have other
> interpretations, such as "fault/error", or "ignored" or "interpreted as
> HTTP binding". 
> 
> Is that roughly right?

No, it's completely wrong.  It implies that I do want these things to be
in the WSDL namespace.

I want the http binding of location to work as you suggest, and to live in
the HTTP namespace (except that I think that you're talking about the path
component only, aren't you? not 'location' in the 'uniform resource'
sense).  *If* a binding finds these abstractions useful, then they can do
the same thing.  If they *don't*, then they don't have to.  By default, if
you say nothing about a particular functionality in a binding, it should
be clear what that means.  Say nothing about a functionality that HTTP
showcases in your jabber binding, and it means that functionality isn't
replicated.  The above suggestion introduces ambiguity: if the authors of
a binding fail to distance themselves from an inappropriate mechanism,
then someone reading the binding can interpret it as "like HTTP" (however
inappropriate that is) or "ignored" (which would otherwise be the
default).

Amy!
-- 
Amelia A. Lewis
Senior Architect
TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Tuesday, 29 June 2004 16:19:33 UTC