1- Not a pb IMHO. I think this deser/ser implementation has
already been documented somewhere on the axis list.
2+3- Rigth. This approach leaves the burden to build the
proper XML on the user hands. But users wanting to still use
WSIF in the old way could use the axis bean ser/deser before/after
calling into WSIF. It's a step back, but it presents a pure
XML interface to all services, or, more precisely to all
providers.
4- Once again, this is left on users hands. A separate toolkit
(XmlBean) can be used to handle the mapping. WSIF
would then focus on providing a XSD/WSDL interface to all kind
of services, and not a Java/WSDL one.
/jog
> -----Original Message-----
> From: Jeff Greif [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 06, 2005 11:22 AM
> To: [email protected]
> Subject: Re: Complex types: do the reverse ?
>
>
> Yes, up to practical issues, this is a reasonable way to
> proceed. The
> practical issues include:
> 1. Even if you are trafficking in DOMs, the WSIF provider (such as
> Axis) may require you to specify trivial
> serializer/deserializer pairs.
> 2. This approach is best suited for doc/lit web services
> where all the
> parameters are complex and the XML contains no special
> encoded forms.
> In this case, what I described in previous emails boils down
> approximately to trafficking in DOMs.
> 3. For rpc/encoded web services, particularly those that use
> soap-encoded arrays and structures, the XML must be specially
> interpreted/manipulated to produce the object structure that was
> intended. (For example, sparse arrays may be encoded.)
> 4. When web service parameters are XSD simple types, such as
> integers,
> dateTimes, etc., some serialization/deserialization must be
> provided to
> convert between xml and java. Note also that derived simple
> types, such
> as limited-range integers must also be recognized and processed
> appropriately.
>
> Jeff
>
> Jacques-Olivier Goussard wrote:
>
> >Hi all
> >With all the discussions around complex types support
> >in WSIF, I was wondering if really WSIF approach to it
> >was the one that it should take.
> >If really WSIF aims at representing all sorts of services
> >through the WSDL description, then it appears to me
> >that all types should be instances of the XSD types.
> >In this approach, a SOAP-based service would simply
> >take and return XML DOMs (or other representation) - thus
> >addressing the complex type issue in the most flexible
> >way. A java-based service would internaly populate the
> >needed beans from it's knowledge of the API and the XSD.
> >So no type mapping would be necessary in the java-binding
> >WSDL description.
> >And the client side would not need any knowledge of
> >the underlying implementation - currently a java-binding user
> >must know if the method takes a int[] or Integer[] for
> >example, breaking the design IMHO.
> >It's a much easier approach, because Java to XML binding
> >is a much simpler problem than XML to java - but that's a 90
> >degres change :)
> > /jog
> >
> >
> >
> >
>
>
>
>
>
>
