Tuesday, 30 June 2009

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.

Service Implementation Architecture and Automation Unit Specification

The Service Implementation Architecture and Automation Units Specifications provide the transition from the logical Business Service Architecture and Service Specifications to the implementation of Services in software. In our latest report we will look at how Automation Units are identified, modeled and specified, and advise on how they are documented in the Service Implementation Architecture.

This report presents Automation Units as a relatively flexible concept that can be used to represent a variety of different implementation approaches. The degree of documentation may vary by type or by the nature of the provisioner/implementer relationship. We would expect organizations to define policies that more tightly scope the permitted Automation Unit types in their organization and the associated documentation they require. From a process perspective, the Service Implementation Architecture is a deliverable from the Service Oriented Architecture and Design discipline, and the Automation Unit Specification is a deliverable from Service Provisioning. Together with the Service Specification, these will be key inputs to the Service Implementation activity.


See Service Implementation Architecture and Automation Unit Specification