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:23:19 -0700
Message-ID: <FNEFKGCOPGCFLMCBIIIBIECDCCAA.jsnell@lemoorenet.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <002d01c0040a$0a038200$2c060e09@LANKABOOK>

In the MS Tools, the developer uses a GUI utility, the SDL Wizard to
automatically extract the method signatures and type information from the
typelib of the COM object being published.  When the proxy object executes a
method call, the internal processor uses the SDL document as a reference as
to the data types used.  Only the base automation data types are supported,
so the mappings are very easy to perform, if the schema says
xsi:type='xsd:string' then it maps to the BSTR data type, etc.  The proxy
component uses a custom implementation of the IDispatch interface.  When the
IDispatch::Invoke method is called, each of the parameters are passed in as
VARIANTS.  The subtype of the VARIANT (equal to any of the standard
automation datatypes) is checked against the value referenced in the schema
declared in the SDL.  If they match, they're good to go, etc.  Both the
client and the server use the same SDL file.

What is interesting on the server side, however, is that the data types are
not checked at all in the ASP-based listener.  Since all data types in ASP
are Variants, and since the actual function call to the published object
occurs within ASP code, the data type checking is left up to the underlying
COM Dispatch call to the object.  It's not a very clean approach, and
definitely causes some problems if the wrong data types are passed in, but
it works very well none the less.

So basically, the client side makes no assumptions as to data types.  It
uses the SDL explicitly to do its work.  The server however, makes a lot of
assumptions -- just execute the function and see if it works! ;-)

- James

-----Original Message-----
From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com]
Sent: Friday, August 11, 2000 8:04 PM
To: soap-dev@xml.apache.org
Subject: Re: xml-soap and xsi:type requirements


> Is there some way to improve this by using reflection?
>
> I am *really* impressed by the absolutely seemless nature of the MS ASP+
> implementation.

There's no magic in the world .. they either use the SDL file or they
use assumptions. I believe its the prior ..

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.

Sanjiva.