Article: Implementing Exceptions in SOA
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.
Commercial Exception Handler
Nice article, we have implemented the features listed as well as making the product highly configurable.
SOAP Fault vs. Specialized Payload
I see clearly the 3rd advantage of using "Specialized Payload". You can use this strategy also without SOAP. However, when using SOAP I prefer using the SOAP fault for communicating application and process errors to the service consumer. This avoids the need for special exception detection code in the client since this is already provided by the SOAP stack (at least in usual Java stacks).
If using "Specialized Payload" it might be worth thinking about using a common data structure "within the payload", not "instead of the payload". This allows to always use the same parser for a normal response as for an error response. Otherwise you need to detect the error situation in a first parsing step in order to unmarshal the response correctly. Although this migth be clear, I have seen real world services that did not follow this recommendation, so it might be worth considering.
Should definitely be asynchronous
As you mentioned, applications should log the exception messages asynchronously, for performance reasons, using any of the logging API's.
A good solution for applications using the Log4j framework would be to either write a custom appender or use the existing JMS appender to post exception messages on the message bus.
The logging service can now act as a message consumer and consume messages. Of course, one has to come up with a standard exception logging message schema for all the enterprise applications.
Even better alternative for applications which could be aspectized, using AOP, is to design a logging aspect which could post messages to the message bus. As enterprises are gradually getting comfortable using more AOP based solutions, they might already have several aspect libraries and adding the exception logging aspect to their arsenal will only help them.
Re: Should definitely be asynchronous
JXInsight - A Diagnostics Solution
JXInsight Product Architect
"Java EE tuning, testing, tracing and monitoring with JXInsight"
But how to handle exceptions now?
I agree with the classification of the exceptions you propose. I agree as well that the best is to have some special payload to transport replies (either repsonses without fault or faults). I even see the use case for a centralized logging and exception handling.
But I ask myself: How can I really handle faults with that infrastructure? A real life example would be really helpful. Take business processes as an example: if I have an application or business fault, I may want to react in the business process, not independent of it. Human interaction to resolve the problem may be a human task modeled in that business process (since it may be part of the business process, how to deal with these kinds of faults), but how do I propagate the fault to the business process in the solution you propose?
Would be nice if you could shed some light on your ideas to this...
Thanks a lot and cheers
Re: But how to handle exceptions now?
Re: But how to handle exceptions now?
Mike Hartington Jul 26, 2015