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
