- From: Sanjiva Weerawarana <sanjiva@watson.ibm.com>
- Date: Wed, 8 Jan 2003 09:26:46 +0600
- To: <edwink@collaxa.com>
- Cc: <www-ws-arch@w3.org>
Hi Edwin, > Does this also apply if the exception is related to the fact that the > service is not available or the version of the interface has changed or > any other exception that is not explicitely advertized by the remote > service as a business fault? That's a good question. The question really is about what one should or will model in WSDL. In the Java world, for example, a programmer is required to document ALL exceptions a method can throw and then the caller knows what can happen. For remote stuff there's a required RemoteException. WSDL is silent on what should be described. Clearly, its not meaningful for a service author to describe what may go wrong while clients try to get to it .. things like proxy auth failure for example or host not found because the client-side is screwed up. The BPEL process OTOH has to deal with those as an invocation can fail with an error that has nothing to do with the other side at all as you noticed. I believe the BPEL spec currently does not say anything about how these kinds of faults are to be delivered to the process; so its basically "implementation defined." That's clearly non-interoperable and hence would need to be fixed. A possible solution would be to add another standard fault like "something-broke-while-doing-remote-stuff" fault and then say all runtime problems like the stuff mentioned earlier must be notified to the process using this fault. Then an interested process author can handle that exception and do stuff if that's what they want to do. Bye, Sanjiva.
Received on Tuesday, 7 January 2003 22:30:47 UTC