IntroductionI 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.
LayeringOne 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 TypesLet 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:
- Return an error within the output message
- Generate a soap fault
- Generate a business event that something happend
ConclusionHope this gives you some stuff to think about when designing your service contract.
Other suggestions are welcome !