The report primarily considers exception management within Service-based solutions. That is, how both Service Providers and Service Consumers should handle exceptions that may occur in the processing of Service requests and responses.
That said, SOA exception management should not be distinct from broader exception management approaches that ought to be in place to deal with solutions that are not Service-based, and elements of the framework presented in this report should be common to both.
However, as we find ourselves routinely saying, SOA brings new challenges. For example:
- The federation of participants implies that the Service Provider and Consumer may be in different organizations.
- Loose coupling implies there is no shared technology or infrastructure. Hence, there may be no common exception handling software, systems management, or error log.
- The Service Provider and Consumer must rely on Service Contracts such as the Service Specification to document exceptions and specify any obligations on them when an exception occurs.
Equally, there is little point in the Service Provider giving detailed feedback on exceptions that represent problems behind the Service ‘façade’ as it is not the Consumer’s responsibility to do anything about it. But of course, the Provider must log and respond to such conditions.
That said, in many cases the Service Provider and Consumer will be in the same organization. As such it may make sense for them to:
- agree on a consistent approach to exception handing.
- standardize exception ‘protocols’. For example, exception codes and messages.
- provide common utilities or infrastructure for exception management.