BT

Article: Implementing Exceptions in SOA

by Stefan Tilkov on May 30, 2007 |
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:

  • 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.
Read the full article here.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Commercial Exception Handler by Eric Roch

We built a commercial exception handler and audit logger at the company I work for Perficient. If anyone is interested in buying versus building see my contact on my blog.

Nice article, we have implemented the features listed as well as making the product highly configurable.

Eric Roch

www.ittoolbox.com/profiles/eroch

SOAP Fault vs. Specialized Payload by Christof Laenzlinger

Very nice Article! Those are the things that are usually only discussed in the very end of the projects.
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 by murali kosaraju

Nice article.

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.

Murali Kosaraju
mkosaraju.wordpress.com

Re: Should definitely be asynchronous by William Louth

For effective problem resolution in a distributed execution environment context is important. Logging the exception as a string to some message bus is extremely primitive and practically useful for operations management. A diagnostics service (and not a logging service) would add context to incoming and outgoing messages as well as create execution frames that represent important execution points within the complete request processing pipeline with each frame holding local and possibly remote context references (java objects,...). The combination of a distributed tracing (or event correlation services) and a diagnostic service that can pull runtime state of in-flight requests or dependent component/systems is what's required today.

JXInsight - A Diagnostics Solution

kind regards,

William Louth
JXInsight Product Architect
CTO, JINSPIRED

"Java EE tuning, testing, tracing and monitoring with JXInsight"
www.jinspired.com

But how to handle exceptions now? by Bernd Ruecker

Hi Boris.

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
Bernd

Re: But how to handle exceptions now? by Eric Roch

Here is an example using utility services

www.perficient.com/Solutions-and-Services/Busin...

Re: But how to handle exceptions now? by Eric Roch

I also wrote a related post on how to use and exception management framwork.

it.toolbox.com/blogs/the-soa-blog/soa-exception...

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

7 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT