Re: WSIF handling of arrays

Hello Alan,

Yes it would make sense to design a new kind of WSIFMessage implementation
that uses JROM instances as message parts. We have done this a long time
ago in some work but did not release it as open source. An alternative
(since JROM is not active) is to use SDO (see
http://www-128.ibm.com/developerworks/java/library/j-sdo/ for an
introduction; there are many other resources) which does what JROM could do
and more (albeit in a more heavyweight manner). SDO used as WSIF message
parts also makes sense. I don't believe this is very hard to do and would
be extremely useful for completely dynamic scenarios.

Thanks,
Nirmal.


                                                                           
             Alan Su                                                       
             <[email protected]                                             
             u>                                                         To 
                                       [email protected]             
             04/03/2006 04:58                                           cc 
             PM                                                            
                                                                   Subject 
                                       Re: WSIF handling of arrays         
             Please respond to                                             
             [email protected]                                             
                  he.org                                                   
                                                                           
                                                                           
                                                                           




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>