Responding to the binding simplification

It appears that my original message on this topic has been eaten by our
switch in mailers this past month.  Sorry.

I would summarize the proposal as having these elements:

1) remove the @interface attribute from binding

2) provide default binding information for otherwise undefined
operations

3) permit inlining of binding inside port

I am opposed to #1, because I believe that it pushes errors from
validation time to runtime, which is not a favor to clients.  I am
*strongly* opposed to #2, because it makes it impossible to say "this
binding does not support this interface".  I support #3, and would
propose that we also permit inlining of interface inside binding, as
well.

When interface is removed from binding, it becomes necessary to
interpret what the absence of an operation means.  When the interface
attribute exists, a missing operation can be detected at validation
time.  Client code will probably not call an operation in a binding if
the operation is missing; the possibility of a runtime error is reduced
(client awareness of an issue) and validation time error is possible
(the description author and service provider can fix the description or
the code; they get warned).

When the interface attribute does not exist on the binding, it is much
more difficult to determine whether all operations are properly defined
at validation time.  It is much more difficult to determine, on the
client side, whether an operation is missing from a binding description.
 It is much more likely that a flawed WSDL will be produced, and that
client code will call it in error.  This can all be guarded against with
good discipline and use of tools, but the need for such palliatives
tends to indicate that removal of this attribute introduces ambiguity
and decreases ease of interoperation.

If a default binding is proposed, when the interface attribute is
retained on the binding element, the disaster produced is not too bad,
although it isn't pleasant at all.  In this case, introduction of the
default binding means that an author who wants to produce a partial
binding (not strictly permitted, but not forbidden either) for an
interface will discover that it is always "completed."  If the rest of
the operations happen to be bound to the HTTP get pattern, it doesn't
matter; any left undefined end up SOAP, document/literal.

This becomes drastically worse, to the point of introducing major, and
possibly undetectable problems, if interface is removed from binding. 
In that case, the mere existence of the binding element implies that it
implements *any interface imported into scope, using the SOAP
document/literal binding*.  Reusing published WSDL via import becomes
extremely dangerous.  Any client use of one-way operations will fail,
without fault (they're defined that way).  The very existence of one-way
operations becomes dangerous, because it becomes less possible to
determine whether someone meant to implement them or not.

I would *approve* a proposal for reducing the verbosity of WSDL via
defaulting, *if* the proposal suggested that the author must explicitly
set the defaults, somehow.  This would allow an author creating a
binding for HTTP as much convenience as those using SOAP doc/literal. 
It would also avoid all the problems of accidentally-defined operations
(operations defined by default, and without the author's intention). 
It's clear that one goal of the existing proposal is to reduce
verbosity; I would suggest that something on the order of a
defaultBinding attribute (on wsdl:binding) would answer most objections.
 However, I would point out that in combination with dropping the
interface attribute from binding, it still becomes possible to
"accidentally" define an operation that isn't intended.

Finally, as to the inlining of binding inside service/port: I think this
is a nice idea; I think we should permit it, as purest highly-refined
and processed syntax sugar.  I would suggest that we should also permit
inlining of interface inside binding (and the combination, so that it is
possible to write a wsdl as: <definitions> <types> </types> <service>
<port> <binding> <interface> </interface> </binding> </port </service>
</definitions>) (that assumes removal of message as well, of course). 
This seems to me to be a useful shortcut, and one that can help people
get to speed on WSDL.  Of course, it also means that anything inlined
is, implicitly, not reusable.  But that may well be the intention (in
which case it is slightly more than syntax sugar: it allows things to be
"hidden" from reuse).

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

Received on Thursday, 10 July 2003 13:05:09 UTC