W3C home > Mailing lists > Public > www-ws-arch@w3.org > January 2003

Re: Semantic Web needed for RESTful Web services? (RE: Binding)

From: Sanjiva Weerawarana <sanjiva@watson.ibm.com>
Date: Wed, 8 Jan 2003 09:26:46 +0600
Message-ID: <02fb01c2b6c5$f5fe2000$6f00a8c0@lankabook2>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:12 GMT