xml-soap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Snell" <jsn...@lemoorenet.com>
Subject RE: xml-soap and xsi:type requirements
Date Sat, 12 Aug 2000 18:13:41 GMT
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 javaMethod,
     boolean force);

such registered method signature may be used to reconstruct signature of the
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 methodName.
this method allows also to map method names between XML schema and actual
method name, for example through call:

     Class cls = obj.getClass();
     Method javaMethod = cls.getDeclaredMethod("getInfo, Class[]
     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 deployment
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, http://www.cs.indiana.edu/~aslom
Don't let what you cannot do interfere with what you can do. ---John Wooden

View raw message