xml-soap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wouter Cloetens" <wcloe...@raleigh.ibm.com>
Subject RE: xml-soap and xsi:type requirements
Date Sat, 12 Aug 2000 10:11:41 GMT
That strikes me as silly. The schema thing doesn't actually handle that then? 
Once again, the name "object" in "SOAP" proves to be a misnomer - I can't 
think of a single OO language where the practice of defining multiple 
methods with the same name (are you guys sure "overloading" is the correct 
name for that?) but different parameter sets isn't possible.

The solution you propose, generating a unique alias for every method 
signature, is exactly what C++ does with its name mangling, so it doesn't 
strike me like such a bad solution. I would let the person deploying the 
service enter that alias manually in the deployment descriptor though, since 
this name has to be published and stable for the benefit of the clients.

Anybody know how Java's RMI and Corba solve this? I'm sure they _can_ 
handle this situation...

bfn, Wouter

On Sat, 12 Aug 2000 11:13:41 -0700, James Snell wrote:

>The MS SOAP Proxy object just can't handle overloaded functions, period.
>All functions have to be uniquely named.  One possible solution (not the
>best possible solution ;-) ..) is to create function aliases in the
>deployment descriptor -- one unique alias for each overloaded function.  It
>would be a pain in the butt, I know, but it would solve the problem -- as
>far as the MS SOAP tools know, each function is a separate and distinct.
>The server would know which version of the function is being called by the
>alias used.  Just a thought -- albiet probably not a very great thought ;-)
>- James
>-----Original Message-----
>From: Aleksander Slominski [mailto:aslom@cs.indiana.edu]
>Sent: Friday, August 11, 2000 11:14 PM
>To: soap-dev@xml.apache.org
>Subject: Re: xml-soap and xsi:type requirements
>Sanjiva Weerawarana wrote:
>> We can do the same if there was a NASSL description of the service -
>> the automatically generated serializer/deserializer doesn't bother
>> to look at any xsi:type attributes to know what to do .. it just
>> knows  because it knew the rules followed during code generation.
>> That's gotta be how theirs work.
>> Here we're talking about a compromise situation where we don't assume
>> a full specification is available but allow some leeway to the user.
>i also think that there is no way that even with XML schema that the server
>will be able to dispatch calls to overloaded methods unless there are
>attributes specifying parameter types. considering this the question is how
>enhance Apache SOAP to support MS SOAP requests.
>i have experimented with processing MS SOAP requests and it seems that
>addition to SOAPMappingRegistry will allow to handle such requests:
>     SOAPMappingRegistry {
>        void registerMethodSignature(QName methodName, Method 
>     boolean force);
>     }
>such registered method signature may be used to reconstruct signature of 
>method passed in MS SOAP request. the only limitation is of course that it
>still will not deal with overloaded methods except that it may throw
>if user tries to registerMethodSignature() of already registered 
>this method allows also to map method names between XML schema and 
>method name, for example through call:
>     Class cls = obj.getClass();
>     Method javaMethod = cls.getDeclaredMethod("getInfo, Class[]
>     parameterTypes);
>     smr.registerMethodSignature(new QName("urn:object","GetInfo"),
>     javaMethod, true);
>we have mapping of "GetInfo" into "getInfo" method.
>such function should allow to register all method signatures from 
>descriptor and will be necessary to support handling of MS SOAP calls
>mappings can definitely be expressed as a part of the deployment
>Aleksander Slominski, Lindley Hall 130, IU, 
>Don't let what you cannot do interfere with what you can do. ---John Wooden

My opinions are irrelevant. They will be assimilated by my employer.

View raw message