Fault handling mechanism in SOAP

Question

Compare the fault handling mechanism in SOAP with that in SunRpc. In particular, state which you consider to be superior, and why.

Answer 1

In the SunRPC , as can be seen in client program, the return status of the RPC library function must be examined to determine if a return code was even received from the server. Therefore a whole additional layer of error checking and response must be added in on the client side.

If TCP is used as the transport protocol, then the client will obtain an error return if the server breaks its connection (crashes). The client has no way of knowing when the crash occurred before or after the request was executed. The TCP protocol handles the re-transmissions and time-outs.

If the UDP protocol is employed, then the client stub automatically gives timeout and retransmission (that is, the client programmer can set the value of the timeout). The RPC protocol comprises a transaction identifier, and the server stub can be instructed to keep in mind responses sent and to send a cached response again when it receives a request it has seen before. This implements an at-most-once semantics in position of default at-least-once semantics.

Whereas as when an error occurs whenever processing a SOAP message, a fault message is produced. The fault information is placed in the SOAP body, in a env:Fault element (where env is the standard SOAP envelope XML namespace . The Fault element has two mandatory sub-elements, env:Code and env:Reason, and possibly optional env:Detail and env:Node elements.

In particular, i would like SOAP fault handling mechanism to be superior as it is customizable and trapable and hence makes our WS as Robust.