Jeff,
You say that you have wsdl with:
<message name="fooResponse">
<part name="return" type="x:Foo"/>
</message>
and in the schema
<element name="foo" type="x:Foo">
I assume the schema also defines an x:Foo complexType. The service is
returning a foo element, correct? To me this suggests that the wsdl is
incorrect. I believe it should say:
<message name="fooResponse">
<part name="return" element="x:foo"/>
</message>
Then in WSIF you would map the element x:foo to whatever Java class it maps
to using the WSIFService.mapType method.
Regards,
Owen
|---------+----------------------------->
| | "Jeff Greif" |
| | <[EMAIL PROTECTED]|
| | nceton.edu> |
| | |
| | 24/02/2003 14:24 |
| | Please respond to |
| | wsif-user |
| | |
|---------+----------------------------->
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: <[EMAIL PROTECTED]>
|
| cc:
|
| Subject: Re: missing xsi:type in responses
|
|
|
|
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
Sorry to have been unclear. Suppose the wsdl says:
<message name="fooResponse">
<part name="return" type="x:Foo"/>
</message>
and in the <types> there is a schema with global (top-level)
<element name="foo" type="x:Foo">
Now, the client invokes the web service and this comes back:
...<soap-env:Body ...>
<fooResponse>
<foo><bar>...foo content ..</bar>.</foo>
</fooResponse>
<soap-env:Body ...>
rather than
...<soap-env:Body ...>
<fooResponse>
<foo xsi:type="x:Foo"><bar>..foo content ...</bar></foo>
</fooResponse>
<soap-env:Body ...>
where the element foo is in the correct namespace.
Suppose the client has registered a type mapping for xmlType x:Foo to some
java class. In WSIF 1.2, using either the ApacheAxis or ApacheSOAP
provider, there will be a deserialization error -- the type mapping will
not
be found and the system will try to use a SimpleDeserializer. If the
xsi:type attribute is present in the response, the right thing will happen.
But there is sufficient information (from the schema in the <types>, but it
may require a validating parse, or even a PSVI-decorated DOM for the parse
result) to make the right thing happen even without xsi:type. In preparing
the operation, could the WSIF provider-level code do what's necessary to
use
the available information so absence of xsi:type attributes will not cause
failure, or expose an API implemented by the providers that lets the client
code control whether that is done?
Jeff
----- Original Message -----
From: "Anthony Elder" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, February 24, 2003 4:19 AM
Subject: Re: missing xsi:type in responses
Hi Jeff,
I'm not really clear about what you are asking for, or what you mean by the
xsi:type information being missing? Why isn't the WSDL output message
definition enough? Could you try explaining again what you mean?
...ant
Anthony Elder
[EMAIL PROTECTED]
Web Services Development
IBM UK Laboratories, Hursley Park
(+44) 01962 818320, x248320, MP208.
"Jeff Greif" <[EMAIL PROTECTED]> on 22/02/2003 20:11:32
Please respond to [EMAIL PROTECTED]
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
