Fw: Specifying simple serializers in dynamic invocations with WSIF

[Jeff Greif <jg...@alumni.princeton.edu>]

There seems to be more discussion of wsif on this list than on axis-users,
so I'm trying again here.  Please pardon me if this is a breach of
etiquette.
Jeff
----- Original Message -----
From: "Jeff Greif" <jg...@alumni.princeton.edu>
To: "Axis Users" <ax...@xml.apache.org>
Sent: Monday, September 09, 2002 1:04 PM
Subject: Specifying simple serializers in dynamic invocations with WSIF


> I'm trying to produce a generic invoker of WSDL-described services and
> operations.  WSIF looks like an elegant way to do this.  The clients of
this
> component are trafficking in XML schema instances, and using XPath to
> manipulate them, rather than native Java classes.  (They work entirely off
> declarative information in XML specifying what web service to call and
what
> kinds of things to pass to it when they need to talk to the web service
> world.)
>
> Thus my generic invoker could take parameters for and return values from
the
> invoked operations which are thinly wrapped versions of these (e.g., an
> object specifying a type that must be present in the WSDL for the service,
> and a org.w3c.dom.Element holding the value, which might be an instance of
a
> complex type) if they are not instances of simple types.  So I could have
> something like
>
> public class ComplexTypeWrapper {
>     public ComplexTypeWrapper(QName typename, Element data);
>     public QName getTypeName();   // XML Type
>     public Element getData();
>     ...
> }
>
> This is a little like a Bean, except that its type is an XML type rather
> than a Java class.
>
> I'm assuming that I would be able to create a WSIFService as is done in
the
> DynamicInvoker example, and then do for each input and output part which
is
> not a simple type,
>   ComplexTypeWrapper x = ...;
>   service.mapType(x.getTypeName(), ComplexTypeWrapper.class);
>
> Such an object has simple serialization/deserialization for SOAP --
> basically, to serialize the object, optionally check the type against the
> required type, and if it matches, optionally check the value to see if it
> validates against the type (or let the invoked service object if it
doesn't)
> , and if so, emit the Element, and similarly, to deserialize, construct a
> ComplexTypeWrapper using the typename and the Element corresponding to the
> content of the part.  What I haven't figured out yet is where in the WSIF
> framework is the standard place to hook in this
> serialization/deserialization scheme, and where to put the
> serialization/deserialization code.  It appears that if I were just using
> straight SOAP, I might make a subclass of the
> org.apache.soap.encoding.literalxml.XMLParameterSerializer, but is this
the
> Right Way (TM) for WSIF?  I'd appreciate a hint about these things.
>
> Jeff
>
P.S. I've since managed to handle complex response parts in stubless dynamic
invocation (where all of those are deserialized to the wrapper object
described above), but have not yet figured out how to set up the
serialization for input complex types.