Composite Materials

Faults, Errors and WSDL

Dave Orchard has recently blogged at length about error/fault abstractions from SOAP (over HTTP) "leaking" into abstract WSDL service descriptions. While I won't comment on the specific issues he raises (and he raises a lot of them -- check it out!), his comments raised, in my mind, a more general issue: how do we handle errors in a distributed SOA?

The introduction of a network into any computing system raises the complexity enormously. The eight fallacies of distributed computing is a good summary of where the complexities come from. The average programmer is pretty used to composing an application out of reusable pieces of code from libraries, frameworks, etc. So when he writes

    x = foo(y);

to call a library function foo, he isn't too concerned about errors occuring. However, if foo is implemented as a call to, say, a web service, we now have to consider a variety of issues. Number one on the list of eight fallacies is "the network is reliable." So now I have to ask, what happens when the call to foo fails? Obviously, the function needs to be able to convey the fact that it failed. For bonus points, it ought to tell us something about the failure. Also, is it possible that the service provider actually received the request to perform "foo", and it was the response that got dropped? Or was the request lost? These considerations introduce a lot of new application states, possible error recover paths, etc. Complexity.

How does this complexity fit into a WSDL description of foo? Should the abstract service description (portType or WSDL 2.0 interface) describe the possible faults that the underlying binding may (perhaps must) "leak"? If the answer is "yes", then the picture is pretty grim: the details of the binding must pollute the abstract service definition, and all our efforts to separate the two are pointless.

If you are familiar with JBI, you know that the JBI expert group answered the above question with a firm "no". JBI separates service providers from communication bindings, such that a service can be bound to multiple endpoints simultaneously, and that the service remains completely decoupled from the bindings.

So how does JBI handle the errors that arise from bindings? The answer lies in the JBI MessageExchange interface, and a couple of observations:

• WSDL described Faults are "normal" parts of the message exchange pattern (MEP). There is nothing magic about such faults, and, in particular, WSDL fault messages should not be used to convey binding-specific errors. A Fault does not cause an abrupt termination of the MEP.
• Binding errors (don't call them faults -- that's just confusing) are not part of the standard WSDL MEPs. They represent an abrupt end to the MEP.

JBI's MessageExchange interface models this directly. In addition to all the normal, MEP-described states that an on-going exchange can enter, JBI adds an error state that abruptly ends the exchange. The cause of the error is detailed using a standard Java exception.

Why did we do this? Because we know that a standard WSDL description of a service is not sufficient for describing all the possible states an interaction between consumer and provider will enter when conducted through a binding that uses a network. Implementations of consumers (and providers) must provide for these extra states. A good implementation will minimize the "leakage" of binding-driven error information. JBI's approach is, in a sense, the "worst-case scenario": from almost every state of the WSDL-described MEP an abrupt transition to the terminal error state can occur. This decouples the provider and consumer, but certainly doesn't eliminate the need to deal with failures. The eight fallacies have not been repealed!

Posted at 11:00AM Apr 21, 2006 by rtenhove in Service Oriented Architecture  |