Re: RPCTF: issue #45

+1 to Jacek's proposal below.



Jacek Kopecky wrote:
>  Hello,
>  on the RPC task force's telcon I agreed to post a summary
> on how I would resolve the issue #45 [1].
>  Folks on soapbuilders, please respond directly to
> to minimize the crossposting.
>  First, I'd like to show how other RPC systems handle error
> states:
>  ONC RPC [2] has a predefined set of fault codes, summarizable as
> a) system error (like memory allocation failures)
> b) target not found (program, version or procedure unavailable)
> c) bad arguments (can't decode params)
> d) authentication errors
>  Please note that ONC RPC doesn't view application errors as RPC
> faults, this is understandable in the context of this over a
> decade old protocol modeled after local calls in languages
> that didn't have exception handling.
>  XML-RPC [3] has numeric fault codes whose meaning is
> implementation-dependent. There has been criticism of this
> because such an approach is bad for interoperability.
>  SOAP has four fault codes, of which two could possibly be used
> to signify RPC errors: Client and Server. SOAP allows extending
> these fault codes by adding a identifier after a dot, but for my
> opinion on this please see my mail [4].
>  My proposal for resolving the issue #45 is show below. In the
> text I use the notation {namespace}local-part for writing
> qualified names, the namespace is just an identifier that should
> be obvious, not the whole URI.
> --------- proposal begin
>  1) A {soap-env}Server fault SHOULD be generated when the server
> cannot handle the message because of some temporary condition,
> like when it is out of memory. This doesn't apply to temporary
> conditions of the application, like database being down or a
> record not present.
>  [SHOULD because the server can lack the resources to even
> generate a proper fault]
>  2) An {rpc}MethodNotPresent fault MUST be generated when the
> server cannot find the method specified.
>  3) An {rpc}BadArguments fault MUST be generated when the server
> cannot parse the arguments or when there is a mismatch between
> what the server expects and what the client has sent.
>  4) Either of the following two is true, a) is preferred:
>   a) An {rpc}Application fault is generated when the
> application has failed for some reason.
>   b) A successful response containing some application-dependent
> indication of a fault is generated.
>  [this 4a point allows for ONC-RPC-like handling of fault
> conditions]
>  In all these cases the <detail> and <faultstring> values would
> depend on the implementation or could be specified by some
> external document.
> --------- proposal end
>  This proposal is aims to cover the most common situations while
> remaining relatively simple. Comments very welcome and indeed
> requested. 8-)
>                             Jacek Kopecky
>                             Idoox
> [1]
> [2]
> [3]
> [4]

Received on Monday, 6 August 2001 11:54:38 UTC