axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jesse D. Sightler" <jsight...@eximtechnologies.com>
Subject RE: ? on WSDL spec
Date Thu, 01 Aug 2002 21:06:16 GMT
Hi Glen,

> There's a lot more to this problem than just trying to support language environments
without overloading.

There always is. ;)

> public void myMethod(int i, String s)
> public void myMethod(int i)
> Since SOAP allows nulls to be specified by omission, there is no way to determine if
the call desired is myMethod(5) or myMethod(5, null).

I don't think that this is exactly true.  OO languages do the same thing
all the time, and they tend to support the semantic by just assuming
that all calls should just go to the closest match.

Ie, if I have methods
public void myMethod(int i);
public void myMethod(long i);

The call myMethod(5) is likely to go to the one taking an int
parameter.  Yes, it COULD go to either method, but the int is the
closest match.

Similarly, a web-service call leaving a field blank would just go to
myMethod(int i) because that is the closest match.


On Thu, 2002-08-01 at 16:55, Glen Daniels wrote:
> 
> Hi folks!
> 
> There's a lot more to this problem than just trying to support language environments
without overloading.
> 
> Consider this: how do you dispatch to an overloaded method?  I send xml which looks like
this:
> 
> <soap:Body>
>   <myMethod>
>     <i xsi:type="xsd:int">5</i>
>   </myMethod>
> </soap:Body>
> 
> And I have these two methods:
> 
> public void myMethod(int i, String s)
> public void myMethod(int i)
> 
> Since SOAP allows nulls to be specified by omission, there is no way to determine if
the call desired is myMethod(5) or myMethod(5, null).
> 
> Forgetting about nulls, the problem still exists even for this situation:
> 
> public void myMethod(int i)
> public void myMethod(String i)
> 
> Now we get the same XML as above, but without the xsi:type attribute.  Which method do
we call?
> 
> .NET deals with this via the SOAPAction header.  That's one solution, but it doesn't
work with every binding.  Considering that the wire representation is mostly going to be created
by tools anyway, why not just make the QName of the method unique and then dispatch on that?
 This solves a lot of problems in what seems to me to be a perfectly elegant fashion.  Your
WSDL generator simply invents whatever mapping it feels like to associate a unique QName with
each method you're exposing as a web service operation.
> 
> What you lose here is the "overloaded" semantic crossing the wire.  So if I use the new
WSDL, instead of building a remote stub which looks like the above, I might get something
that looks like:
> 
> public interface MyStubInterface {
>    public void myMethod1(int i);
>    public void myMethod2(String i);
> }
> 
> ...is that such a horrible price to pay?
> 
> --Glen
> 
> 
> > -----Original Message-----
> > From: Stuart Thomson [mailto:stuart@swtsoftware.com]
> > Sent: Thursday, August 01, 2002 4:40 PM
> > To: axis-user@xml.apache.org
> > Subject: Re: ? on WSDL spec
> > 
> > 
> > "Jesse D. Sightler" wrote:
> > > 
> > > 
> > > It's true that method/function overloading isn't REQUIRED for
> > > significant functionality (even including OO), but it's 
> > very commonly
> > > used.
> >  
> > Indeed, I've been using overloading without thinking about it 
> > for a long
> > time now. As I moved from C++ to Java I found I used it even more to
> > compensate
> > for the lack of default parameters. As a developer of 
> > libraries you must
> > try to 
> > make thing as convenient as possible for your users.
> > 
> > My main problem with losing this capability is that a lot of code can
> > now not be
> > automatically deployed as a web service without defining some mapping.
> > You may be
> > Sorely Out of Luck and find that your tool/environment does 
> > not permit a
> > mapping.
> > 
> > I would aeriuously like to know which languages, currently used for
> > webservice 
> > development, do not allow overloading. What percentage of web services
> > use these 
> > languages. Could not the users of inferior languages define 
> > the required
> > mapping ?
> > 
-- 
=======================================
Jess Sightler
Programmer
Exim Technologies
131 Falls Street
Greenville SC 29601
Phone: 864-679-4651
=======================================



Mime
View raw message