Troubleshooting
Problem
Java™ classes are not generated for many of the Schema types declared optional or unsupported by Chapter 18 of the JAX-RPC 1.0/1.1 specification. Instead, these types are mapped to parameters or attributes of type javax.xml.soap.SOAPElement. When you try to test this web service using the samples created, you get JSP errors stating that SOAPElement cannot be instantiated. This is the case for both WebSphere® Studio Application Developer (WSAD) version 5.1.2 with WebSphere Application Server (WAS) version 5.0.2+ or 5.1.1+ and for Rational® Application Developer (RAD) version 6 with WAS version 5.0.2+ or 6.0.
Cause
The JAX-RPC 1.0 and 1.1 specifications define standard mappings to Java for a subset of Schema types. Mappings of all other types are, whether stated explicitly or otherwise, considered optional, and will be mapped to javax.xml.soap.SOAPElement. Examples include xsd:any, xsd:choice, xsd:sequence with maxOccurs greater than one, and nested content models (such as elements with anonymous types). The WebSphere Application Server, WebSphere Studio and Rational Developer products implement the JAX-RPC specifications.
Resolving The Problem
Various workarounds are available, depending in part on the particular Schema types involved:
- An alternative to <xsd:choice> is to instead use an <xsd:sequence> each of whose elements has minOccurs="0" maxOccurs="1". This is less strict than choice, in that mutual exclusion of the elements is lost; however, any instance document that would comply with the choice complies with the sequence.
- A nested content model (such as an element of an anonymous type) is not supported. Declaring and using a named complexType should get around the issue.
- Where a mixture of well-mapped Java types and SOAPElement(s) in the code generated from WSDL and Schema is not tolerable, Rational Application Developer version 6 and WebSphere Application Server version 6 provide a "No data binding" option that disables the JAX-RPC mappings entirely and produces business methods on Java service skeletons and service endpoint interfaces whose signatures consist entirely of SOAPElement(s). This option sets the stage for adapting the business methods to use an alternate, self-consistent and far richer Java programming model for Schemas such as SDO or JAXB.
- xsd:any and SOAPElement are discussed later
- See the Related URL Item: Java Collection types ....
See the WAS v6 (JAX-RPC 1.1) IBM WebSphere Developer Technical Journal article: Developing and deploying custom data binders for WebSphere Application Server (see Related URLs). In particular, see the Appendix: Schema types not supported by JAX-RPC 1.1. The article's primary focus is on custom binders for the javax.xml.soap.SOAPElement (more on this later in the technote).
Background on "optional" JAX-RPC mappings and WAS Web Services support
JAX-RPC defines support for types such as <xsd:choice> as Optional. By declaring <xsd:choice> optional, JAX-RPC is simply inviting implementers of the specification to choose their own mappings, but is doing nothing to insure that implementers converge on a standard and J2EE-portable mapping.
In practice, "optional" pretty much equals "not supported". Unless JAX-RPC defines a mapping, vendors will choose their own, and J2EE portability will be broken. As a general rule, WAS Web Services will not embark on the slippery slope of defining proprietary mappings from Schema to Java. It could get users into more difficulties down the road with respect to migration and standards compliance than they now encounter with using SOAPElement. There would be an inevitable collision with standard mappings available, or emerging in JAX-RPC 2.0, JAX-B 2.0 and SDO v2. Be forewarned, any mapping implementation of optional elements in JAX-RPC by any J2EE server vendor would not be portable.
If you do use the optional xsd tags, you will get a WSWS3029W message from WAS v5.x or WAS v6.x:
WSWS3029W: Warning: The xml construct named {0} cannot be mapped to a java type. The construct will be mapped to javax.xml.soap.SOAPElement.
It is understood that lack of support for <xsd:choice> and other portions of schema excluded by JAX-RPC, has caused difficulties in creating web services. WAS version 6.x and RAD version 6.x have and are taking measured steps towards resolving this:
- The first step in version 6 was to adopt to JAX-RPC 1.1 and, in compliance with it, to generate SOAPElement(s) for elements in Schema of types that are either not supported or declared optional by JAX-RPC.
- The second step is to show how to use RAD version 6 with a little hand-written code to bind SDOs to SOAPElement(s) in JAX-RPC SEI(s). A future article is to be written on the subject using a simple pattern. See the Custom Data Binding articles under Related Information and other articles in developerWorks as they become available.
- A tentative goal for a future WAS/RAD version is to deliver first class integration of SDOs into Java Web service interfaces.
WSAD/RAD/WAS Web services and SOAPElement mapping:
The JAX-RPC 1.0 and 1.1 specification state:
6.4.1 Java Mapping of Literal Representation
. . .
If there is no standard Java mapping for an XML schema type, a message part with literal representation is considered and mapped as a document fragment. The XML to Java mapping uses the interface javax.xml.soap.SOAPElement to represent a literal message part in the Java mapping of a wsdl:operation element.
. . .
What is new in JAX-RPC 1.1 in Section 6.4.1 is this data binding excerpt:
In order to make it possible to use other data binding frameworks (e.g. JAXB) in conjunction with JAX-RPC, it must be possible to selectively turn the standard JAXRPC type mapping off on a per-part basis and revert to the default mapping, namely SOAPElement. JAX-RPC tools are required to provide a facility to specify metadata for this purpose.
For example, in the case of both specifications, XML Schema type(s) xsd:any or an xsd:anyAttribute will each map to javax.xml.soap.SOAPElement. Instances of these types (de)serialize correctly through WAS v6 in RAD v6. The same might not be true of WAS v5.x (5.0.2.+ or 5.1.1+) in WSAD v5.1.x or RAD v6:
- WAS v5 complies with JAX-RPC 1.0 which dictates SOAPElement mappings for these items: explicitly for xsd:anyAttribute and implicitly for xsd:any.
- However, SOAPElement (de)serialization was less robust in WAS v5. This was mainly in the context of the RAD v6/WAS v6 no data binding option for replacing the standard JAX-RPC mappings by SOAPElement(s), as opposed to the mapping of unsupported/optional/nonstandard types to SOAPElement. More on this shortly.
WAS version 5.x is JAX-RPC 1.0 compliant. Only a subset of types have Java mappings (not including choice, attributeGroup(s), anyAttribute, and so forth). When encountering these types,Chapter 6.4.1 states they should be mapped to SOAPElement, so you have some assemblance of getting the information.
In the case of WAS version 6.0:
- It is JAX-RPC 1.1 compliant. Similar to JAX-RPC 1.0, it does not define natural java mappings for some XML Schema types and Chapter 6.4.1 states they should be mapped to SOAPElement, in this case, as defined by Soap Attachments API for Java (SAAJ) v1.2 in which SOAPElement extends DOM Element.
- JAX-RPC 1.1 has slightly better mappings than JAX-RPC 1.0 (as in attribute, ref, list, simple type restrictions, some of the simple intrinsic types have changed from "optional" in 1.0 to "required" in 1.1). See Table 18-1 of the 1.0 and 1.1 specifications.
- The "No data binding" option in WAS v6 and RAD v6 is more robust than its counterpart in WAS v5 and WSAD v5. To clarify, it is the data binding excerpt from JAX-RPC 1.1 chapter 6.4.1 that is new compared to JAX-RPC 1.0.
- In a SAAJ v1.2 compatible implementation, the SOAPElement-DOM Element conversion is no longer needed because SAAJ v1.2 requires SOAPElement to extend DOM Element directly.
- Support of SOAPElement is extended to allow others to deserialize/serialize the data themselves with other technology stacks (to allow other ones to be used at the application level). How this then gets exposed in the tools for other mappings with other serialization/deserialization runtimes is a discussion for some future release.
- You can map unsupported XML Schema types to custom Java types or legacy data types using the Custom Binding capability and its corresponding CustomBinder interface. This is an IBM extension and is not part of JAX-RPC 1.x.
- RAD version 6 does have improved Web Services tooling, and supports JAX-RPC 1.1 in the context of a web service targeting a WAS version 6 server. The WAS v6.x WSDL2Java -no DataBinding option, is available in RAD v6 under Windows > Preferences > Web Services > Code Generation > IBM WebSphere runtime : Disable data binding and use SOAPElement checkbox.
Related Information
[{"Product":{"code":"SSRTLW","label":"Rational Application Developer for WebSphere Software"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Component":"Web Services Development","Platform":[{"code":"PF016","label":"Linux"},{"code":"PF033","label":"Windows"}],"Version":"6.0;6.0.0.1","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}},{"Product":{"code":"SSBRLP","label":"WebSphere Studio Application Developer"},"Business Unit":{"code":"BU050","label":"BU NOT IDENTIFIED"},"Component":"Web Service","Platform":[{"code":"PF016","label":"Linux"},{"code":"PF033","label":"Windows"}],"Version":"5.1.2","Edition":"","Line of Business":{"code":"","label":""}},{"Product":{"code":"SSYK2S","label":"Rational Software Architect Designer"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Component":"Web Services Development","Platform":[{"code":"PF033","label":"Windows"},{"code":"PF016","label":"Linux"}],"Version":"6.0;6.0.0.1","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]
Historical Number
11730 L6Q 000
Was this topic helpful?
Document Information
Modified date:
10 September 2020
UID
swg21207642