axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Greif" <jgr...@alumni.princeton.edu>
Subject Re: Fw: Specifying simple serializers in dynamic invocations with WSIF
Date Thu, 12 Sep 2002 19:09:17 GMT
Thanks very much.  This is exactly what I ended up doing, after quite a bit
of thrashing around the source.

Jeff

----- Original Message -----
From: "Owen D Burroughs" <OWENB@uk.ibm.com>
To: <axis-dev@xml.apache.org>
Sent: Thursday, September 12, 2002 8:18 AM
Subject: Re: Fw: Specifying simple serializers in dynamic invocations with
WSIF


>
> Jeff,
>
> WSIF does not directly carry out serializing/deserializing, this is
handled
> by whatever provider is in use. The provider will typically use the API it
> is a wrapper for. For example the Apache SOAP provider will by default use
> the BeanSerializer from Apache SOAP.
>
> The core WSIF API is independent of any specific provider. As such it does
> not provide any mechanism for registering your custom
> serializers/deserializers. If however you want to provide your own
> serializers/deserializers for the Apache SOAP provider to use then you
can.
> If you know that you are using the Apache SOAP provider, you can get a
> reference to the SOAPMappingRegistry object used in the invocation of the
> service. This can be done by casting your instance of WSIFPort to
> WSIFPort_ApacheSOAP and then calling the public getSOAPMappingRegistry
> method on it. Once you have a reference to the SOAPMappingRegistry you can
> register your serializer/deserializer in the same way you would if using
> the Apache SOAP API directly. So if you want to subclass
> XMLParameterSerializer that should be fine.
>
> Hope this helps,
>
> Owen
>
> Owen Burroughs
> owenb@apache.org
>
>
>
>
>                       "Jeff Greif"
>                       <jgreif@alumni.pri        To:
<axis-dev@xml.apache.org>
>                       nceton.edu>               cc:
>                                                 Subject:  Fw: Specifying
simple serializers in dynamic invocations with WSIF
>                       11/09/2002 00:22
>                       Please respond to
>                       axis-dev
>
>
>
>
>
> 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" <jgreif@alumni.princeton.edu>
> To: "Axis Users" <axis-user@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.
>
>
>
>
>
>


Mime
View raw message