APAR status
Closed as program error.
Error description
Background:
WSDL
A WSDL request-response operation can be modeled with multiple
fault
messages:
<wsdl:message name="qname">
<wsdl:part name="fault" type="xsd:myXsdType"/>
</wsdl:message>
<wsdl:operation name="nmtoken"parameterOrder="nmtokens">
<wsdl:input name="nmtoken"? message="qname"/>
<wsdl:output name="nmtoken"? message="qname"/>
<wsdl:fault name="nmtoken" message="qname"/>*
</wsdl:operation>
SOAP
The operation may be bound to a SOAP binding:
<wsdl:operation ... >
<soap:operation ... >?
<wsdl:input> ... </wsdl:input>
<wsdl:output> ... </wsdl:output>
<wsdl:fault>*
<soap:fault name="nmtoken" use="literal|encoded"
encodingStyle="uri-list"? namespace="uri"?>
</wsdl:fault>
</wsdl:operation>
For the SOAP binding, the fault messages must have a single
part. This is the only restriction defined in the WSDL 1.1
specification (which includes SOAP).
WSIF and the WSIF SOAP Provider
If a SOAP fault is returned, then the SOAP Provider must map the
returned SOAP message back to the correct WSDL fault name and
fault message qname, and WSIF must return this information to
the WSIF client.
The SOAP provider should expose the qname in:
<wsdl:fault name="nmtoken" message="qname">*
This should be done by providing the javax.wsdl.Message
definition of the appropriate wsdl message on the call
WSIFMessage.getMessageDefinition().
The SOAP provider should expose the name in:
<wsdl:fault name="nmtoken" message="qname"/>*
This should be done by setting the name of the WSIFMessage used
as the fault message, so it can be retrieved on the call
WSIFMessage.getName().
The SOAP provider should expose the part in the fault.
This will be achieved by adding an object part to the WSIF fault
message. The name will be the part name of the wsdl fault
message (e.g. "fault" for xsd:myXsdType), the object will be an
instance of the exception thrown in the client (e.g. a
xsd:myXsdType object).
Additionally, if a fault occurs on the server for which there is
no wsdl:fault defined, the WSIF SOAP provider should throw a
WSIFException from the executeRequestResponseOperation method.
To be backwardly compatible, this will only happen is the WSIF
context property SIFConstants.CONTEXT_THROW_UNCHECKED_SOAP_FAULT
is set to a Boolean with value of true
Local fix
WSIF clients can examine the contents of the fault message
directly and attempt to parse the WebServicesFault object which
is returned
Problem summary
****************************************************************
* USERS AFFECTED: Users of WebSphere Application Server who *
* use WSIF to invoke SOAP services which *
* return user-defined exceptions. WebSphere *
* Process Choreographer is among such users. *
****************************************************************
* PROBLEM DESCRIPTION: The WSIF SOAP provider did not have *
* provision for processing SOAP faults *
* to identify the WSDL fault which *
* occured. WSIF will now attempt to *
* match a SOAP fault to a WSDL fault *
* message. WSIF will also put the *
* Exception object which maps to the *
* XML type in the SOAP fault into the *
* WSIF fault message. *
****************************************************************
* RECOMMENDATION: *
****************************************************************
When a SOAP web service is invoked which returns a user
defined exception in a SOAP fault, WSIF will put a named
Object part into the WSIF fault message provided on the
executeRequestResponseOperation() method call. If the user
exception is defined in the service WSDL, WSIF will not update
the fault message's Message definition with the fault which
occured. WSIF will also not not update the fault message name
with the name of the fault which occured. This behaviour is
different to an EJB web service.
Therefore the user cannot rely on WSIF to always map a fault
in a web service to the relevant wsdl fault message
irrespective of the underlying web service protocol.
Problem conclusion
It is recommended that customers encountering this problem
should install WebSphere Application Server V5.1.0 with
cumulative fix 2, WebSphere Application Server V5.0.2 with
cumulative fix 5.
Temporary fix Comments
APAR information |
APAR number |
PQ84902 |
Reported component name |
WAS ENTERPRISE |
Reported component ID |
5630A3700 |
Reported release |
00W |
Status |
CLOSED PER |
PE |
NoPE |
HIPER |
NoHIPER |
Special Attention |
NoSpecatt |
Submitted date |
2004-02-18 |
Closed date |
2004-03-04 |
Last modified date |
2004-03-04 |
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Modules/Macros
Publications Referenced
|
Fix information |
Fixed component name |
WAS BASE 5.0 |
Fixed component ID |
5630A3600 |
Applicable component levels |
R003 PSY |
UP |
R00A PSY |
UP |
R00H PSY |
UP |
R00I PSY |
UP |
R00P PSY |
UP |
R00S PSY |
UP |
R00W PSY |
UP |
R103 PSY |
UP |
R10A PSY |
UP |
R10H PSY |
UP |
R10I PSY |
UP |
R10P PSY |
UP |
R10S PSY |
UP |
R10W PSY |
UP |
|