Re: WSIF handling of arrays

Hi again,

This is probably bad form to reply to one's own message, but i have a  
sort of related general "philosophical" question about WSIF.  To  
debug my problem, I've been looking more closely at the dynamic  
invocation sample codes that come with the WSIF distribution.  One  
thing is striking to me: while the operation and arguments in these  
examples are indeed fully dynamic, it seems that the *types* of the  
arguments are not at all static.  For example, looking at the  
localjava example once more, indeed the interface fairly easily  
allows for discovery and dynamic dispatch of web service operations,  
but the underlying types that are needed -- Address and Phone in this  
example -- are stubs; this limits somewhat the types of dynamic  
invocation that one could imagine, no?

In principle, i would say that one could easily conceive scenarios in  
which the user would want to extract the information about types from  
the WSDL definition supplied by the web service at the instant when  
the service is being called.  This is related to my original problem  
in that a solution to the "dynamic storage type" problem would solve  
both.  Does anyone have any experience using WSIF in this context?   
Do i need to use something like JROM (which appears to be dead?) or  
DOM, and if so, are there any good tutorials out there describing  
this process?

Thanks,

-alan

On Apr 3, 2006, at 12:57, Alan Su wrote:

> Hi,
>
> I'm trying to use WSIF 2.0 to dynamically access a web service  
> essentially generated via the Globus toolkit.  In particular, the  
> web service operation I want to access has an input message that is  
> defined to have a single part; this is the appropriate exerpt from  
> the corresponding WSDL document:
>
>   <message name="plot_2DInputMessage">
>     <part element="tns:plot_2D" name="parameters"/>
>   </message>
>
> where the plot_2D element is defined here:
>
>   <xsd:element name="plot_2D">
>     <xsd:complexType>
>       <xsd:sequence>
>         <xsd:element maxOccurs="1" minOccurs="1" name="lsids">
>           <xsd:complexType>
>             <xsd:complexContent>
>               <xsd:restriction base="soapenc:Array">
>                 <xsd:attribute ref="soapenc:arrayType"  
> wsdl:arrayType="ns0:LsidType[]"/>
>               </xsd:restriction>
>             </xsd:complexContent>
>           </xsd:complexType>
>         </xsd:element>
>       </xsd:sequence>
>     </xsd:complexType>
>   </xsd:element>
>
> in turn LsidType, the base type of the array in the input message  
> is defined fairly simply:
>
>   <xs:complexType name="LsidType">
>     <xs:annotation>
>       <xs:documentation>A life sciences identifier</xs:documentation>
>     </xs:annotation>
>     <xs:sequence>
>       <xs:element name="value" type="xs:string">
>         <xs:annotation>
>           <xs:documentation>A life sciences identifier</ 
> xs:documentation>
>         </xs:annotation>
>       </xs:element>
>     </xs:sequence>
>   </xs:complexType>
>
> Yes, needlessly complicated, perhaps (i.e., creating a complex type  
> to wrap a string), but that is what i have to work with.  so, i use  
> WSDL2Java to generate the necessary stub files, which gives me what  
> i suppose i need to access this service programmatically: a bean  
> class LsidType with a custom deserializer, and a stub class  
> _plot_2D that accepts an array of LsidType objects via a setLsids  
> method.  This looks promising to me...(I also have the stub and  
> base classes for the output message, but i'm omitting them because  
> i don't think they're part of the problem.)
>
> So using the localjava sample from the WSIF distribution as a mold, I
>
>  - instantiate a WSIFServiceFactory and then a WSIFService for the  
> service described in the WSDL document;
>  - call the WSIFService.mapType() method on each of the base types  
> then the enclosing message types (is all this necessary?) for both  
> the input and output messages of the targeted operation;
>  - instantiate WSIFPort and WSIFOperation objects for the operation  
> that uses the input message described above;
>  - create a hard-coded array of the LsidType objects from values  
> that I've verified should work (via a program that uses the non- 
> dynamic stub approach);
>  - put that array in a WSIFMessage object created via the  
> WSIFOperation.createInputMessage() method; and
>  - attempt to invoke the operation via the  
> WSIFOperation.executeRequestResponseOperation() method.
>
> this call raises a org.apache.wsif.WSIFException:
>
>   org.apache.wsif.WSIFException: exception on AXIS invoke:  
> java.lang.ArrayStoreException; nested exception is:
>         java.lang.ArrayStoreException
>
> Can anyone spot an obvious error in how i'm using WSIF to  
> accomplish this?  Does anyone have any ideas what might cause this  
> behavior?  i'm wondering if the schema (esp. the use of an array of  
> what is technically a complex type) might be the root cause of this  
> problem.  if so, i would greatly appreciate a pointer to a  
> reference that describes the constraints of the XML schemas that  
> may be used with WSIF.  in case it helps, i printed out the stack  
> trace on this exception and included it as an attachment at the  
> bottom of this message.  anyway, i'm starting to believe that I  
> need to bite the bullet and manage the message construction at a  
> lower level (using the AXIS Call interface?) to make this  
> work...but I'm still hoping that I'm wrong and that someone will  
> show me where i've gone astray in using WSIF!
>
> Thanks in advance for any ideas, clues, or suggestions on alternate  
> approaches,
>
> -alan
>
>
> <stacktrace.txt>