1. Current HP-SOAP does this. However, the 'WSDL-aware' feature, we 
called it 'WSDL-validation', should be optional/configurable. If 
'all' type information are NOT missing, wsdl MAY not be required 
to correctly process a request.

2. Instead of using wsdl, you could use introspection of the 
service impl class to figure out what type the param is. If this
is feasible/appropriate, then the purpose of setting WSDL-aware
is to validate request soap against the WSDL.

3. For your example:
        <echoParam>
                <param>123</param>
        </echoParam>

If the service impl overload the echoParam as following:
String echoParam( int i ) {
        return "integer";
}
String echoParam( String s ) {
        return "string";
}

And the correspond operations on wsdl is also overloaded. Then the 
type info still cannot be resolved from wsdl( and introspect. ).
I think a ambiguity exception/fault should be response in such case.


-chen



> -----Original Message-----
> From: R J Scheuerle Jr [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, February 19, 2002 1:53 PM
> To: [EMAIL PROTECTED]
> Subject: WSDL Aware Runtime
> 
> 
> I would appreciate some comments on the proposal to make the 
> runtime 'wsdl
> aware'
> 
> For example, if the following is recieved off the wire:
> 
> <echoParam>
>    <param>123</param>
> </echoParam>
> 
> There is no way to determine how to deserialize the data 
> because the type
> attribute is not specified.
> But if the runtime is 'wsdl aware' it could examine the wsdl 
> and determine
> the type of
> <param> and do the proper deserialization.
> 
> Making the runtime 'wsdl aware' would also allow axis to check xml
> instances coming over
> the wire against the format described in the wsdl.  I suspect 
> that other
> non-axis runtimes may
> already be doing this.
> 
> Making the runtime 'wsdl aware' would also eliminate the 
> extra information
> that is generated
> in the skeleton classes.
> 
> The serializers/deserializers would need to be changed to traverse the
> wsdl/xml during
> serialization/deserialization.
> 
> Has anyone given this any thought?
> 
> Rich Scheuerle
> XML & Web Services Development
> 512-838-5115  (IBM TL 678-5115)
> 

Reply via email to