SOA Exception Management

Our SOA Exception Management Framework provides a structured approach to specifying exception conditions and dealing with them at run-time. In this report we look at some techniques that may be used

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.

Consequently, the obligation is on both Service Provider and Consumer to independently manage exceptions. It is not the Service Provider’s responsibility to resolve errors in the Service Consumer’s requests. The Service Provider may simply reject invalid requests and do little else. It is up to the Service Consumer to handle such exceptions, log them, notify any interested parties, analyze the cause, and finally take any remedial action if required.

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.

Even where the participants are not in the same organization, they will still need to agree on the exception handing protocols. Though the detail of this should be part of each Service Specification, ideally there should be some generalized framework in place for exception management so that ‘sets’ of related Service Specifications at least behave in the same way. For example, all Services in a Business Domain. This report therefore sets out to describe such a framework.