SOA Exception Management

www.cbdiforum.com

SOA Best Practice

SOA Exception Management
Framework
By Lawrence Wilkes

Independent Guidance for
Service Architecture and Engineering

Introduction

 This presentation provides an overview of our SOA Exception
Management Framework
 Further detail and guidance (e.g. Specific techniques) is provided in
the CBDI Journal report and the CBDI-SAE Knowledgebase

 This report primarily considers exception management within Service-
based solutions. That is, how both Service Providers and Service
Consumers should handle exceptions that may occur in the
processing of Service requests and responses.
 That said, SOA exception management should not be distinct from
broader exception management approaches that ought to be in place
to deal with solutions that are not Service-based, and elements of the
framework presented in this report should be common to both.

 2009 Everware-CBDI Inc This material may not be copied or reused without express permission

SOA Brings New Challenges

 For example,
 The federation of participants implies that the Service Provider and
Consumer may be in different organization
 Loose coupling implies there is no shared technology or infrastructure.
Hence, there may be no common exception handing software, systems
management, or error log.
 The Service Provider and Consumer must rely on Service Contracts such
as the Service Specification to document exceptions and specify any
obligations on them when an exception occurs.
 In many cases the Service Provider and Consumer will be in the same
organization. As such it may make sense for them to for example,
 agree on a consistent approach to exception handing
 standardize exception „protocols‟. For example, exception codes and
messages
 provide common utilities or infrastructure for exception management
 Even where the participants are not in the same organization, they will still
need to agree on the exception handing protocols.


Exception Management Lifecycle - I

Phase Purpose Activities/Mechanisms
Specification Specification of Exception Precise Specification
conditions and Exception handing
Certification Ensuring Specification is met Testing against specification
Test cases for all exception conditions
Detection Detection of Exception conditions Validation of
 Schema
 Business Rules
 Pre-post conditions
Action Handle Exception Reject
Correct
Retry
Redirect
Recover
Classify (cause)
Log
This table shows a life cycle for exception management listing the key activities and mechanisms for
each phase. Apart from the production of the Service Specification which is the provider‟s
responsibility, the activities in each phase should be considered by both provider and consumer.
By agreeing to such a life cycle, both participants will better understand what activities they should
be performing when an exception occurs.

Exception Management Lifecycle - II

Phase Purpose Activities/Mechanisms Notes
Notification Feedback to participants Response message May use publish and
Fault message subscribe mechanisms
Common Event
Raise Issue
Analysis Analysis to determine Root cause analysis Is the implementation at
cause of continuing Re-validate specification fault or the specification?
Exceptions
Resolution Take corrective action to Update process
reduce future Exceptions Educate users
Data cleansing
Update software


Process

 From a process perspective it makes sense to standardize as much
as possible with:
 An Enterprise-level process, defining an enterprise-level framework
documenting how exceptions should be managed.
 A Project-level process, defining the specific exceptions expected in
their implementation and how they are handled, according to the
enterprise framework
 For all the usual reasons, it may not be possible to define a truly
enterprise-wide framework. However, a meaningful unit of scope
might still apply – e.g. business unit, business domain – or more likely
a common framework shared by a federation of service providers and
consumers.


Enterprise-level Exception Management Activities
Process Activities Responsibility of

Define Contract Define Service Specification and Automation Unit Specification – SOA Governance Lead
Types detail how exceptions are to be documented

Define Define taxonomy of exceptions SOA Quality
Exception Management
Build a exception/fault code structure
Types
Assign standard exception codes and standard response
messages

Define Event Define and Implement common exception handling infrastructure SOA Infrastructure
Handling (part Architect together with
Define and implement a common event format for notification of
of Service Service/systems
exceptions. This could be part of wider common event processing
Management) management
initiative, not just for exceptions.

Model Model Exception Management as a domain in the Business Type Service Architect
Exception Model, and identify a Service Architecture for exception
Management management.
This would support the provision of any common exception
handling services (see later)

Define Define and Implement Exception Detection Points (EDP) in SOA SOA Infrastructure
Exception infrastructure. For example in the Enterprise Service Bus (ESB), Architect
Handing Business Rules Engine, Service Management.
Infrastructure
Define and Implement common exception handling infrastructure

Project-Level Exception Management Activities

Process Activities Responsibility of
Service Define exceptions visible to Service Consumer. Service Specification
Specification Designer
Define detailed business exceptions in pre/post conditions
Classify according to taxonomy of exceptions and assign fault
codes, and define exception messages
AU Decomposition of business exceptions and technical exceptions by Service Specification
Specification component and platform Designer together with
Software Designer
Define additional exceptions relevant only to Service Provider
Specify what actions to be taken on detection of exception
Design Detailed technical exceptions Software Designer
Detail how Actions are taken
Determine detection mechanisms and EDP that will be used in their Software Designer
implementation together with SOA
Infrastructure Architect
Set test cases Tester
Build Finalization and detailing of technical exceptions (exception codes Software Developer
etc)
Set Notifications
Deploy rules to various EDP
Test Run test cases to check exceptions, notifications Tester

Exception Specification

 Exceptions need to be specified in either
 Service Specification: As the prime contract between Service Provider
and Consumer, the Service Specification is the main place to document
exceptions and responses that are of consequence to the Service
Consumer (type 1 below)
 Automation Unit Specification: Should also define addition exceptions
that are of concern only to the Service Consumer, as well as the type 2
response below to exceptions that are in the Service Specification.
 Exception Condition Visibility
 It may be necessary to specify two different response messages to certain
kinds of exception;
 Type 1, of relevance to the Service Consumer – e.g. “Technical Error”
 Type 2, containing further information of interest only to the Service
Provider – e.g. “Technical Error. Customer Database CustDb07 not
available”
 Exception Shielding
 guarding against the security risk exposed by exception messages that
reveal sensitive information or reveal too much about the implementation.


Certification

 The prime activity in certification is to ensure the Service and
Automation unit Specifications are met.
 Test cases will therefore need to be run for all valid and invalid
conditions.
 Test cases may be supplied as part of the specification (but not as a
substitute for). Test cases typically define the output messages
expected for each test condition. Again an example of this is provided
in “Documenting Service Behavior”.


Detection: Exception Detection Points

The mediation capabilities The Automation Unit (the Service
of an ESB may be capable Implementation) can of course do all
of message validation, Receipt Path this in its code....
checking for WS-protocol But should be focused on detecting
Exceptions, etc business exceptions
Dispatch Path
An inverse of the receipt path

Application Business
Service Mediator XML Technical Automation
or Web Rules
Endpoint (e.g. ESB) Processor Interface Unit
Server Engine

The Application The XML A Business Rules There may be further
or Web Server processor can Engine can perform type checking etc
may detect validate the more sophisticated provided by the
exceptions in schema using rule-based validation automation unit
SOAP or HTTP XSD of message container

A key part of putting any infrastructure in place to support exception management at run-time is to
determine what Exception Detection Points (EDP) are provided , and then in the design phase for a
specific service, deciding which EDPs are to be used.
This figure is purely illustrative. Implementations may not have all these EDP‟s, whilst some might have
more – such as in an XML-aware firewalls, or the gateway into the Automation Unit container. Similarly,
the actual sequence of processing may differ.

Exception Detection Points - Post Processing

Could be
applied much Real-Time
earlier in the Analytics
path

Automation Database
Analytics
Unit Management

The Automation Unit will The DBMS might Pattern-based
can of course do all this in perform additional data Exceptions
its code.... validation Exceptions that can
But should be focused on Validation against only be detected across
detecting business database schema (e.g. multiple transactions
Exceptions orphans) (may include fraud...)

There are also activities that can take place “post processing” to further detect
exceptions such as the use of analytics to search for more complex rule-
based exceptions such as fraud. Though increasingly these might be applied
in real-time, as part of the receipt/dispatch path.


Action
When an exception condition is detected, a number of actions listed in the
table should be taken. Many of these actions will be common to both the
Action Service Provider‟s and Consumer‟s response to an exception condition.
Process
 Rejection The simple case is that invalid requests or responses are rejected
 Correction or Attempt to correct request.
substitution It may be possible to derive correct data by cross referencing against other related data.
Or it may be acceptable to substitute a „best guess‟, or a lowest common denominator.

 Redirection Invalid requests are re-directed to an alternative endpoint for differentiated processing
For example, the automated process may switch to a human process rather than reject the
request. Would you rather lose a sale because of invalid data, or see if a human can deal
with it better?
Technical Exceptions may lead to seeking alternative endpoint (backup, scaling)
 Retry Technical Exceptions may lead to a simple resubmission when the system recovers
(queuing)
 Recover Exceptions may lead to the initiation of some form of recovery process – such as restoring
data to its original state. In long-running asynchronous services, this may require the use of
compensating transactions.
Classify Classify the Exception
Determine fault code
Log Log the exception

Notification

 Key questions are
 determining which parties are interested in the exception
 what level of detail they need to know about the exception, and what
caused it
 what mechanisms are used to notify them
 Determining which parties are interested may be dealt with using publish and
subscribe approach
 Notification Format
 Though the SOAP Web Service protocol provides the SOAP Fault
Element as a standard for returning fault messages to the Service
Consumer, that doesn‟t preclude organizations using something like
Common Base Events, WS-Notification, or the Web Event Format of
WSDM, to communicate exceptions to a wider range of participants
 The key consideration however, is that SOA is not always dependent on
WS-Protocols.


Advantages and Disadvantages of SOAP Faults vs
Custom SOAP Body
Option Advantage Disadvantage
All exceptions Standards-based Not flexible
returned as SOAP
Recognized by SOA Can not communicate multiple
Faults
infrastructure exceptions
Use SOAP Faults for Technical exceptions still Business exceptions will not be
technical or system understood by the SOA automatically handled by
exceptions infrastructure elements of SOA infrastructure
that may be able to process
Use a custom SOAP Custom payload allows more
business rules – though they
Body to return expressive feedback for
could be configured to do so
business exceptions business exceptions, including
multiple exceptions at once
All exceptions More expressive Non-standard
returned as custom
Not recognized by SOA
SOAP Body
infrastructure

There is conflicting advice on whether to use SOAP Faults to communicate exceptions or
whether instead to define a regular SOAP Body element that contains a custom „payload‟ that
can be more expressive than the standard SOAP Fault.


Logging

 Logging is not just a matter of recording the exception. It will typically also
require the messages that prompted the exception are also logged.
 One principle that may be followed is that of „Post before Processing‟6. That
is, all data is captured and logged, whether invalid or not. Who knows what
might be needed later? In some contexts it is better to capture invalid data
than to reject it.


Analysis

 Deeper analysis may be required to determine the root cause of
exceptions. This may require the analysis of multiple related
messages. Whilst each message has a unique ID and timestamp, this
may require some way of identifying related messages by some
common ID that is present in all the messages. This might be added
in the logging process if it is not inherent already in the message
schema used by the Service.
 With regard to „Post before Processing‟, analysis of the logged invalid
data may help to reveal for example why some data is more frequently
invalid than others, and help understand the root cause – such as
poor data collection caused by poor human interface design.


Resolution

 By resolution we mean to take corrective action to remove or reduce
future exceptions from occurring. This may require actions such as
 Update processes to improve data entry and validation
 Educate users to improve data entry
 Data cleansing where Service requests are composed from
existing data
 Update software to remove technical exceptions, trap more
business exceptions, improve validation
 See our „Data Quality for SOA‟ Report for further guidance


Links and Resources

 CBDI Wiki
 http://cbdi.wikispaces.com/SOA+Exception+Management

 CBDI Journal Report
 http://www.cbdiforum.com/secure/interact/2009-
05/soa_exception_management.php


www.cbdiforum.com

Independent Guidance for Service Architecture and Engineering

www.everware-cbdi.com


SOA Exception Management

More Related Content

Similar to SOA Exception Management

Recently uploaded

SOA Exception Management