Service Orientation: Exception handling pattern

Introduction

I am a great fan of the service orientation principles described by Thomas Erl: http://www.soaprinciples.com/
And also of its patterns: http://www.soapatterns.org/
This will not be a sucking up story about Thomas, but the need for a pattern on error handling.

Layering

One of the patterns is that of Service Layering, in which the Services can be categorized in the following layers:

The Utility Service Layer consists of Services that are of agnostic functional nature and are not functional related to a business entity or business process.
The Entity Service Layer contains Services that are related to business entities and are usually also agnostic.
The Task Service Layer is more related to Services that are specific to a particular task or process.
Usually you also have a Orchestrated Task Service layer contains Services that orchestrates Services to fulfill a business process.

My question is how to deal with errors in the separate layers?

Error Types

Let me first describe the type of errors we can have:

• Technical Errors
  Those are errors of technical nature, like database can not be reached, wrong message format. Mostly internal service errors that occur.
  
• Capability Errors
  Those are the errors due to the fact that a capability of a service can not be executed. These errors are more of a functional nature.
  
• Business Process Errors
  Those are errors that occur within the logic of a business process.
  

The next item you have to think about, is which errors you want to expose.

Expose errors?

The first option that comes to mind is that all errors remain internal, using the Abstraction Principle.
However if you think deeper then:

• Technical errors may kick off other processes that will deal with service errors, by sending mails to maintenance for example. Then technical errors are part of the service contract.
• A composite controller may handle a capability error by trying it again or using an alternative path.
  A service does (generally) does not know in which activity it participates, so the service can not decide what to do when something happens. Then the error is also part of the service contract.
  

How to expose errors?

When you decided to expose errors then you have to think about how to expose the errors.
When looking at webservice services you have several options:

1. Return an error within the output message
2. Generate a soap fault
3. Generate a business event that something happend

I am more in favorite of the last two, because the first option always blurs your goodweather logic and this way the maintenance of your code can be more complex.

Conclusion

Hope this gives you some stuff to think about when designing your service contract.
Other suggestions are welcome !