In an SOA, handling exception is significantly more complex than in a local deployment scenario, due to the fact that exceptions can occur in multiple places, and correlating logging information can become quite cumbersome.
In this InfoQ article, Boris Lublinsky highlights the problems with exception handling in SOA, and suggests applying SOA principles to exception handling as a solution. The architecture he proposes consists of a logging service, an exception resolution service, a notification service, an exceptions/logging portal, and service management:
In this InfoQ article, Boris Lublinsky highlights the problems with exception handling in SOA, and suggests applying SOA principles to exception handling as a solution. The architecture he proposes consists of a logging service, an exception resolution service, a notification service, an exceptions/logging portal, and service management:
- Exception resolution service processes each log message using exceptions resolution rules. These rules specify whether the message should be ignored (e.g., information messages), resolved automatically, or whether human intervention is required.
- Notification service receives notification requests and uses a set of rules to dispatch the notification (e.g., email gateway, pager gateway, enterprise management solution).
- Exceptions/Logging Portal allows people to view and browse the logged exception information.
- Service Management monitors services traffic to determine business-level exceptions and reports them to the logging service, which treats them the same way as any other exceptions in the system.