Databases Reference
In-Depth Information
When a
soap:Fault
is generated, the
faultcode
will contain the fault
name (
tns:invalidCreditCard
in the previous example), and the
detail
element will contain the content of the fault message.
Defining faults in asynchronous services
Asynchronous services don't explicitly support the concept of faults. This is because
the result of an asynchronous service is returned in a separate
callback
operation.
So to signal a fault, the service will need to define additional callbacks, typically
one extra callback per fault. If we take our credit card example and rewrite is
as an asynchronous service, we get the corresponding WSDL:
<portTypename="CardServices"
<operationname="verifyCreditCard">
<inputmessage="tns:verifyCreditCard"/>
</operation>
</portType>
<portTypename="CardServicesCallback"
<operationname="creditCardVerified">
<inputmessage="tns:creditCardVerified"/>
</operation>
<operation name="invalidCreditCard">
<input message="tns:invalidCreditCard" />
</operation>
</portType>
Here we can see that we've defined a second
callback
operation (highlighted in
the previous code). This corresponds to the fault we defined in the synchronous
operation. If we examine this, we can see that we've used the fault name as the
operation name in the callback. Although we have two different messages, in reality
they are identical, we have just used different names as we want to stick to our
naming conventions.
It is still possible for the invocation of an asynchronous service to return a fault. This
can occur when the system is unable to successfully deliver the invocation message
to the asynchronous service, for example, when the network connection is down.
We would treat this type of fault as a system fault as opposed to a business fault.
