xml-soap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Fell <s...@zaks.demon.co.uk>
Subject Re: xml-soap and xsi:type requirements
Date Sat, 12 Aug 2000 19:06:04 GMT
This is how the current MSDN SOAP Toolkit works, but i believe Sam was
talking about the SOAP features in ASP+ / dotnet.

Cheers
Simon

On Sat, 12 Aug 2000 11:23:19 -0700, in soap you wrote:

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


Mime
View raw message