SOA Exception Management
Upcoming SlideShare
Loading in...5
×
 

SOA Exception Management

on

  • 5,154 views

This presentation outlines the CBDI-SAE SOA Exception Management Framework that provides a structured approach to specifying exception conditions and dealing with them at run-time. It primarily ...

This presentation outlines the CBDI-SAE SOA Exception Management Framework that provides a structured approach to specifying exception conditions and dealing with them at run-time. It primarily considers exception management within Service-based solutions.

Statistics

Views

Total Views
5,154
Views on SlideShare
5,058
Embed Views
96

Actions

Likes
0
Downloads
233
Comments
1

8 Embeds 96

http://cbdi.wikispaces.com 60
http://www.slideshare.net 17
http://www.soakb.com 6
http://lwsoa.blogspot.com 5
http://everware-cbdi.com 4
http://www.cbdiforum.com 2
http://www.linkedin.com 1
http://lwsoa.blogspot.co.uk 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

SOA Exception Management SOA Exception Management Presentation Transcript

  • 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.  2009 Everware-CBDI Inc This material may not be copied or reused without express permission
  • 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.  2009 Everware-CBDI Inc This material may not be copied or reused without express permission
  • 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  2009 Everware-CBDI Inc This material may not be copied or reused without express permission
  • 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.  2009 Everware-CBDI Inc This material may not be copied or reused without express permission
  • 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  2009 Everware-CBDI Inc This material may not be copied or reused without express permission
  • 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  2009 Everware-CBDI Inc This material may not be copied or reused without express permission
  • 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.  2009 Everware-CBDI Inc This material may not be copied or reused without express permission
  • 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”.  2009 Everware-CBDI Inc This material may not be copied or reused without express permission
  • 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.  2009 Everware-CBDI Inc This material may not be copied or reused without express permission
  • 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.  2009 Everware-CBDI Inc This material may not be copied or reused without express permission
  • 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  2009 Everware-CBDI Inc This material may not be copied or reused without express permission
  • 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.  2009 Everware-CBDI Inc This material may not be copied or reused without express permission
  • 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.  2009 Everware-CBDI Inc This material may not be copied or reused without express permission
  • 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.  2009 Everware-CBDI Inc This material may not be copied or reused without express permission
  • 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.  2009 Everware-CBDI Inc This material may not be copied or reused without express permission
  • 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  2009 Everware-CBDI Inc This material may not be copied or reused without express permission
  • 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  2009 Everware-CBDI Inc This material may not be copied or reused without express permission
  • www.cbdiforum.com Independent Guidance for Service Architecture and Engineering www.everware-cbdi.com  2009 Everware-CBDI Inc This material may not be copied or reused without express permission