Yes -- but you must remember that SOAP isn't a distributed object system. It's a message passing system. The SOAP server is supposed to figure out what to do with an incoming message by examining the QName of the child element of the SOAP Body (the signature). But that signature doesn't differentiate between overloaded methods. If the QName maps to multiple object methods, then Axis must dig deeper into the message to figure out how to process it, but it doesn't know how to dig deeper into the message until it knows what method it's supposed to invoke. It's just bad.
And there's no telling what might happen if you try to access the service from a non-Axis client. You have the following choices: - define a different operation for each set of possible parameters - define one operation which contains choice elements (bad for interop) - define one operation using the message style, and your application programmatically dispatches the appropriate methods (much more work for you) The first option is definitely the winner. One suggestion: submit a feature request that would allow you to define mappings between multiple WSDL operations to overloaded method signatures. That way you wouldn't need to change your application, but you could expose unique operation names. Anne On 6/13/05, Andy Kriger <[EMAIL PROTECTED]> wrote: > What is the suggested strategy for dealing with methods where > overloading makes sense? > > I know that you recommend working from the WSDL to the code, but the > Axis code generation makes working from code to WSDL easy enough to > avoid that step, therefore I ask these questions without so much > familiarity with what WSDL affords in terms of parameter defintions. > As I see it, either you have a lot of similarly named methods exposing > each overload variant or you have one method that takes all of the > parameters possible. Not sure how removing overloading is a win for > the developer if those are our options. > > On 6/13/05, Anne Thomas Manes <[EMAIL PROTECTED]> wrote: > > The SOAP 1.1 and WSDL 1.1 specifications allow method overloading. I > > just looked through the SOAP 1.2 specification, and it also appears to > > allow method overloading. WSDL 2.0 disallows method overloading. The > > WS-I Basic Profile also disallows method overloading. > > > > Axis 1.2 should support method overloading. If it doesn't it's a bug. > > But you shouldn't do it. > > > > Anne > > > > On 6/13/05, Brian Gladish <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > Our Web Service has a number of "execute" methods which were being invoked > > > properly on 1.1, but which seem to cause Axis confusion on 1.2. The > > > specific case now is that a method in Java which has the signature > > > execute(String, String) is being confused with execute(String, byte[]) > > > (the > > > latter is being called on the server when the former is invoked on the > > > client). In addition, the byte[] parameter is being passed in as null > > > even > > > though the string passed as the second argument on the client call is not > > > null and not empty. > > > > > > > > > > > > WSDL for execute(String, String) (this is the method I expect to be > > > invoked): > > > > > > > > > > > > <wsdl:message name="executeRequest3"> > > > > > > <wsdl:part name="sessionId" type="xsd:string"/> > > > > > > <wsdl:part name="xQuery" type="xsd:string"/> > > > > > > </wsdl:message> > > > > > > > > > > > > > > > > > > WSDL for execute(String, byte[]) (the method actually invoked): > > > > > > > > > > > > <wsdl:message name="executeRequest"> > > > > > > <wsdl:part name="xQuery" type="xsd:string"/> > > > > > > <wsdl:part name="data" type="xsd:base64Binary"/> > > > > > > </wsdl:message> > > > > > > > > > > > > Is this a (new) bug that appeared in Axis 1.2 or is Axis 1.2 acting > > > correctly and the problem was that 1.1 should not have supported this > > > overloading? > > > > > > > > > > > > Brian J. Gladish > > > > > > Senior Software Engineer > > > > > > Raining Data Corporation (http://www.rainingdata.com) > > > > > > (949) 260-5140 > > > > > > > > >
