Re: Issue: should WSDL allow overloaded methods?

Hi, Jeff,

Your example of unsigned integer vs integer is a reasonable one, but it's
misleading.  Most overloaded operations, in practice, are more divergent
than that, and if we only have resolution difficulties with things like
integer vs unsigned integer, and not the vast majority of them, then this
is a resolution issue I'd be willing to deal with.  If WSDL did not support
overloaded operations, then we'd have resolution difficulties with EVERY
overloaded operation.

But there's more!  We must worry about BOTH directions.  WSDL -> some
language, AND some language -> WSDL.  Take the J2EE world.  J2EE is a big
world.  Since it's Java, overloaded operations already exist there.  If we
want to use SOAP as the communications mechanism between J2EE systems, then
we must translate Java to WSDL.  Without overloaded operations in WSDL,
we'll have to mangle EVERY overloaded operation and we will have resolution
difficulties.

You worry about dispatching overloaded operations on the server side.  We
already have that problem in Java RMI and it deals with it.  Forcing the
dispatcher to add, on top of what it already does, unmangling of operation
names, just makes it more complex.

I just want y'all to be aware that, if WSDL does not support overloaded
operations, that doesn't mean the problem goes away.  You just delay
dealing with it.  And instead of dealing with it ONCE, it is dealt with in
every language mapping in a potentially messier manner.

Russell Butek
butek@us.ibm.com


Jeff Mischkinsky <jeff.mischkinsky@oracle.com> on 05/22/2002 07:38:43 PM

To:    Russell Butek/Austin/IBM@IBMUS, "Jean-Jacques Moreau"
       <moreau@crf.canon.fr>
cc:    Joyce Yang <joyce.yang@oracle.com>, www-ws-desc@w3c.org
Subject:    Re: Issue: should WSDL allow overloaded methods?



Hi Russ,
    It seems to me that the best way to proceed may depend upon where one
starts from. Starting with a WSDL that allows overloading means that there
will be a mangling problem when mapping to languages that do not allow
overloading.
    Even if one accepts that argument that "modern" languages, and the only
ones that we need to be concerned about, support overloading,  there still
may be a problem. The mapping will only be "natural" if the type systems
between WSDL and the target languages are similar "enough" that the
languages will allow the reuse of a method name for all possible
overloadings in both directions.
    For example let's say that in an overloaded WSDL there is a difference
between unsigned and signed integers, so that i can have 2 foo(), one with
an unsigned integer, the other with a signed integer. What will happen in a
language which doesn't allow a foo(unsigned integer) and foo(integer)?

   Another issue that arises is the efficiency/possibility of doing
dispatch on the server side. If WSDL allows overloading, then the dispatch
mechanism will have to determine which "real" method to call based upon the
actual parameter types in the request. (Dispatch based upon name won't be
good enough.) Resolving the ambiguity may be quite complex and time
consuming.

   cheers,
    jeff

At 05:32 AM 5/22/02, Russell Butek wrote:
>I'm sorry I haven't been keeping closer tabs on this issue, but I would
>like to discourage this thread.  Many languages support overloaded
>operations.  If you disallow it in WSDL, all you're doing is moving the
>burden of dealing with overloaded operations from the WSDL spec to mapping
>specs.  And all this accomplishes in the long run is cryptic mappings,
more
>chances for name clashes, and more difficulty resolving names in the
>runtime.  How, for instance, would the following Java be mapped to WSDL?
>
>MyObject create(String context, String name);
>MyObject create(URL name);
>MyObject create(OtherObject obj);
>URL createURL();
>OtherObject createOtherObject();
>
>Most likely, mappings will have to come up with mangled names like:
>
><operation name="createStringString".../>
><operation name="createURL".../>
><operation name="createURL".../> <!-- which of these should be mangled
>further? -->
><operation name="createOtherObject".../>
><operation name="createOtherObject".../> <!-- which of these should be
>mangled further? -->
>
>Yes, a language mapping could probably solve these issues better than I
did
>in this quick note, but if WSDL itself allowed overloaded operations, then
>the language mapping wouldn't even have to deal with the issues, we'd
>generate cleaner WSDL and we wouldn't have to worry about name clashes and
>resolution difficulties in the tools and runtime.
>
>I don't know the issues at hand, and perhaps they're significant, but I
>would like everyone to weigh those issues against future issues that
>banning overloaded operations would raise.
>
>Russell Butek
>butek@us.ibm.com
>
>
>"Jean-Jacques Moreau" <moreau@crf.canon.fr>@w3.org on 05/22/2002 04:19:12
>AM
>
>Sent by:    www-ws-desc-request@w3.org
>
>
>To:    Joyce Yang <joyce.yang@oracle.com>
>cc:    www-ws-desc@w3c.org
>Subject:    Re: Issue: should WSDL allow overloaded methods?
>
>
>
>+1
>
>Joyce Yang wrote:
>
> > Proposal: clearly disallow methods overloading in WSDL 1.2.
> > Methods overloading should exist in the concrete implementation
> > of the service, but not in the service description.

--
Jeff Mischkinsky                    jeff.mischkinsky@oracle.com
Consulting Member Technical Staff   +1(650)506-1975 (voice)
Oracle Corporation                  +1(650)506-7225 (fax)
400 Oracle Parkway, M/S 4OP960
Redwood Shores, CA 94065 USA

Received on Thursday, 23 May 2002 08:35:26 UTC