W3C home > Mailing lists > Public > www-ws-desc@w3.org > May 2002

Re: Issue: should WSDL allow overloaded methods?

From: Jeff Mischkinsky <jeff.mischkinsky@oracle.com>
Date: Wed, 22 May 2002 17:38:43 -0700
Message-Id: <>
To: "Russell Butek" <butek@us.ibm.com>, "Jean-Jacques Moreau" <moreau@crf.canon.fr>
Cc: Joyce Yang <joyce.yang@oracle.com>, www-ws-desc@w3c.org
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 
    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.


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
>"Jean-Jacques Moreau" <moreau@crf.canon.fr>@w3.org on 05/22/2002 04:19:12
>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?
>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 Wednesday, 22 May 2002 20:39:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:23 UTC