Resolution Accelerator – Exception Handling for SOA

The adoption of Service Oriented Architecture (SOA) causes some profound changes in application development. Initially, the idea that we build composite applications by orchestrating a variety of services sounds as if it is just a better way to implement modular programming. However, breaking down application suites into simple services means that we can lose some of the functionality of the suite, such as audit logs, and exception handling.

If we look more closely at exception handling we should see the problem. If an application suite recognised an exception, such as a missing input value, or the stock position being different to the expected, then the suite could deal with the exception, bringing all the relevant data together, passing it to the relevant module of the suite and the exception will be handled.

Individual services are different. If SOA is to be effective, the services have to be small and self contained, they have to have very well defined interfaces and messages they respond to and they cannot assume very much about their environment. They should not know what invoked them, and they definitely should not assume anything about the functionality of the invoker. If services are not built like this they will be very difficult to test, very sensitive to changes in the environment and will not provide the flexibility, adaptability and productivity that is claimed for SOA.

So, if a service discovers a problem, it cannot fix it, it can only raise an exception by sending a response to the invoker. The response must be a message or document(s) that identifies the exception and provides all the relevant information that the service has collected. The problem with that approach is that the invoker is also just a service and is also in no position to resolve the issue.

Luckily SOA both creates the problem and provides the mechanism to resolve it in a more elegant manner than the suites. The solution is to have services for resolving exceptions. The beauty of this approach is that the services can be general purpose services that are configured to deal with specific exceptions. The benefits of this approach are multiple:

• Logging of exceptions and their resolutions can be done in a consistent fashion thereby improving the auditing, monitoring and control of exceptions. This logging is essential to ensure business compliance, as ad-hoc fixing of exceptions is a real opening for unauthorised dubious changes to occur.
• Changes to the way specific exceptions are handled can be implemented quickly. This can significantly improve the productivity of the business by reducing the number of errors that have to be resolved by human intervention.
• Exceptions can be handled in a variety of different ways:
• • from just passing the message to a human for resolution.
  • through acceleration,where the system suggests possible resolutions.
  • through automation, where the system fixes the problem without the need for human intervention.
  • through elimination, where the system can catch the error at input before the service raises an exception.
  • All of these under the control of a generalised service.
• As exceptions are monitored and the resolution life-cycle is understood the method used can be moved through the above types. This can be done exception type by exception type, so allowing the low hanging fruit with the biggest benefits to be tackled first, without compromising the processing of the unusual errors.
• Institutionalization of Best Practices – what used to be ‘tribal knowledge’ of how to deal with an exception now becomes available as a ‘service’ that can be easily modified and adapted. Such well documented practices are an essential prerequisite to meeting compliance regulations.

The beauty of SOA is that it enables solutions like this to be developed and provided independently as services, thus providing all the benefits at a fraction of the cost of trying to build a bespoke exception handler.

The first vendor that I have come across that has done just this is Vitria, with Resolution Accelerator (RA). RA has been built using the experience of several of Vitria’s clients who needed generalised exception handling and built it on top of Vitria’s BPM offering. From this experience, Vitria has extracted all the standard services, development artefacts, and administrative tools required to quickly and effectively implement exception resolution in an SOA environment. RA is built on top of Vitria’s BPM but as it is a service it will run alongside and support any SOA environment using any other ESB or BPM products.

In the SOA environment, external exception management is the only solution, but if we think of suites as very coarse grained services then RA can still help to resolve errors that occur between the different suites.

I believe that Resolution Accelerator provides a service that is essential to the successful widespread adoption of SOA and should be considered very seriously by anyone moving into this area.