Re: Issue: should WSDL allow overloaded methods?

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.

Received on Wednesday, 22 May 2002 08:33:09 UTC