Facilitating the spread of knowledge and innovation in professional software development



Choose your language

InfoQ Homepage News Article: Implementing Exceptions in SOA

Article: Implementing Exceptions in SOA

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.

Rate this Article


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.

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

Community comments

  • Commercial Exception Handler

    by Eric Roch,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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

  • SOAP Fault vs. Specialized Payload

    by Christof Laenzlinger,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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

  • Re: Should definitely be asynchronous

    by William Louth,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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

    "Java EE tuning, testing, tracing and monitoring with JXInsight"

  • But how to handle exceptions now?

    by Bernd Ruecker,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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

  • Re: But how to handle exceptions now?

    by Eric Roch,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Here is an example using utility services

  • Re: But how to handle exceptions now?

    by Eric Roch,

    Your message is awaiting moderation. Thank you for participating in the discussion.

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

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

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


Is your profile up-to-date? Please take a moment to review and update.

Note: If updating/changing your email, a validation request will be sent

Company name:
Company role:
Company size:
You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.