There have been several postings regarding the serialization of derived
types or array types that are not specifically mentioned in the service
interface. The solution put forward has been to add these types in an
<additionalTypes> element.
This doesn't seem quite comprehensive, though. For a start, it seems that
although the schema definition for config.xml allows it, any
<additionalTypes> elements are ignored if the config.xml file uses
<wsdl> rather than service. But it's just as likely that additional types
will be needed if the service is described in WSDL, isn't it? Is this
restriction intended?
Secondly, to work around the lack of <additionalTypes> in this case, some
postings have suggested using wscompile with a <service> element instead,
so that the <additionalTypes> can be added. But this would entail creating
a Java service endpoint definition from the original WSDL. I have two
concerns about this:
1. There is no requirement for WSDL -> Java -> WSDL to produce the same
WSDL at the end as appeared at the beginning. My experience with this
is that some of the names change (at very least) and therefore the
code that eventually gets generated might not work with the service
described by the original WSDL. In other words, by converting from
WSDL to a Java interface, you lose information.
2. A Java interface cannot replace a WSDL file in all circumstances. If
the service contains operations that are document/literal, for example,
you can still create a method in the Java interface definition for it,
but when you then feed this class to wscompile, it generates a model
that will result in rpc/encoded ties being built.
Is there a real solution to the problem of adding additional types to
services described in WSDL that covers all cases?
Kim Topley
Keyboard Edge Limited