Hi,
I've been thinking about this too, maybe a mapping of the form
element QName --> expected schema type
could be stored by WSIF and made available to providers (in addition to the standard type mapping) in order to facilitate deserialization of elements without type information. Then (in a SOAP provider) when a message comes in, the provider will know how to deserialize the element appropriately.
This is just one solution. Also, I don't think this is of immediate importance since the Axis provider can handle such messages just fine as things stand. But you're right that from a WSIF API standpoint the provider has somewhat incomplete information and has to do more work when dealing with such messages, since the information abt. the element's schema type is in the WSDL, WSIF should make it available in the core API somewhere.
Nirmal.
| "Jeff Greif" <[EMAIL PROTECTED]>
02/22/2003 03:11 PM
|
To: <[EMAIL PROTECTED]> cc: Subject: missing xsi:type in responses |
This refers to WSIF 1.2 (I cannot upgrade to 2.0 for another week or two).
In an Axis client, in order to deal with missing xsi:type information on the return value of the response, you set the return type and class on the org.apache.axis.client.Call object.
In a WSIF client like the DynamicInvoker (mine handles complex types as well), there does not seem to be an obvious way to handle the lack of xsi:type information except by provider-specific techniques such as the one above for axis (but I have not been able to make this specific thing work). If the xsi:type is missing, both the ApacheSOAP and ApacheAxis providers get an exception trying to deserialize the response, even if a type mapping has been registered appropriately for the part -- presumably there is no way to look up that mapping without the type.
Yet, the element contained in the returned part may have a namespace attached, and if so, in a correctly sent response, the schema corresponding to that namespace will have already been made available to the client through the wsdl and its imports, and presumably the xml type can often be determined for that element. (All bets are off when the server returns something incorrect, or a fault message that has not been specified in the wsdl.)
If there is some way for a provider to handle the missing xsi:type contingency, perhaps the WSIF API could provide a method for specifying the expected return type and class, and providers could do implement it appropriately.
Jeff
