Mailing-List: contact soap-dev-help@xml.apache.org; run by ezmlm
From: "James Snell" <jsnell@lemoorenet.com>
To: <soap-dev@xml.apache.org>
Subject: RE: xml-soap and xsi:type requirements
Date: Sat, 12 Aug 2000 11:13:41 -0700
Message-ID: <FNEFKGCOPGCFLMCBIIIBEECDCCAA.jsnell@lemoorenet.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <3994EB2E.C95C06C8@cs.indiana.edu>

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.

hi,

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
xsi:type
attributes specifying parameter types. considering this the question is how
to
enhance Apache SOAP to support MS SOAP requests.

i have experimented with processing MS SOAP requests and it seems that
simple
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
exception
if user tries to registerMethodSignature() of already registered methodName.
this method allows also to map method names between XML schema and actual
java
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 deployment
descriptor and will be necessary to support handling of MS SOAP calls
(method
mappings can definitely be expressed as a part of the deployment
descriptor).

alek
--
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