Re: HTTP binding for WSDL 1.2

On Thu, May 29, 2003 at 03:54:03PM -0400, Philippe Le Hegaret wrote:
> agreed, but I'd better keep the concept of interface than enclosing an
> operation into one application protocol. When I look at the various
> application protocols used in instant messaging, I'm quite happy to have
> softwares that define a common interface to access them.

See below.

> > > Wouldn't change
> > > anything and the URI constructed will still be
> > > http://www.example.com/bulbs?buldId=42
> > 
> > Yes, the URI would be the same, but there are other considerations.
> > 
> > Currently, there's an implicit understanding in the use of WSDL, that
> > a client wanting to use a service with a WSDL description has to
> > understand what the wsdl:operation means in order to use it, as that
> > is what it is being asked to happen.  If the wsdl:operation is "state",
> > but a client doesn't need to understand what that means, and instead
> > only needs to understand what HTTP GET means, then that makes
> > wsdl:operation superfluous.  This is the point of issue 64, and I
> > attempted to address that with an earlier proposal (see below).
> 
> I doubt that a WSDL processor would agree to accomplish an HTTP GET
> operation just because it happens to be an HTTP GET. WSDL doesn't
> contain a lot on the meaning of an operation in any case. At most, you
> can conclude (or hope) that doing the operation twice won't affect
> anything. Knowing that state is a GET won't tell you what to do with the
> result of the operation.

Hmm, I think we're disconnected.  But I don't think it matters much,
since I think the main issue is discussed below, and we're in synch
about it.

> > http://lists.w3.org/Archives/Public/www-ws-desc/2003Jan/0103
> 
> Thanks for the pointer!
> 
> I fell to see the value of the distinction between application and
> transport in your proposal. HTTP verbs are always bound to their
> semantics defined in RFC 2616. What would be the difference of using 
> the binding/@type attribute with "application" and "transport" when HTTP
> is in use?

I wrote this in the proposal;

] There are (at least) two ways of doing the core of the change I'm
] presenting here.  One way would be to remove the need for an operation
] element in the case where "type" had value "application", which would
] permit the methods/"verbs" of the application protocol to be exposed as
] the operation.  The other way would be to define the methods as
] operations in the binding.

Your binding comes close to the second suggestion, except, as we
just discussed, it merely "associates" the methods with the
operation; it doesn't equate them, as I would strongly prefer (i.e.
before I'd agree to close the issue 8-).

In your first paragraph above, you suggest that being able to abstract
application protocol interfaces is desirable.  I agree, but would
caution that this is extraordinarily difficult; there are security
issues, amoung others, to consider.  Besides, I think HTTP's uniform
interface already makes a fine abstraction for other application
interfaces.  But that's another topic best left for another time. 8-)

> As you said, application protocols are not transport protocols and the
> current HTTP binding proposal doesn't give you the right to misuse HTTP
> as defined in the RFC.  A WSDL operation must always comply with the
> constraints of the application protocol method. When an application uses
> HTTP POST for an GET-like operation, it looses the idempotent property
> of the HTTP GET method but doesn't infringe the rules of HTTP POST
> itself (as far as I know). imho, we should provide guidelines on
> when/how to use HTTP GET/POST, and SOAP over HTTP GET/POST.

That's great, but I think the easiest way to enforce that is to remove
the notion of the operation being different than the verb in the 'type=
"application"' case.  Developers who use WSDL are used to the operation
defining the contract.  If you say "operation=state, verb=GET", and the
effective operation is GET and not "state", then I expect that will be
very confusing to them.  I think it's far easier and less prone to error
to do either of the two things I suggested in my original proposal.

And also note that they can still use 'type="transport"' to get the
classic behaviour of treating operations and verb as different beasts.

I'm trying to think of a middle ground, but can't.  But I'm open to
suggestions.

Thanks.

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis
  Actively seeking contract work or employment

Received on Thursday, 29 May 2003 16:37:02 UTC