In any SOA enable environment (Enterprise as well as Product) Exception/ Fault and Error Handling forms one of the major areas during Architecture & Design and Governance (especially Design and Run time).
Before moving forward let us set some definitions:
1. Exception/Fault: These are the business and system conditions which can cause temporary or permanent disruption of instance of service/s. In most of cases this disruption is temporary and with some efforts (run time only though coded at design time) service instance remains alive and keep on serving the clients.
2. Error: These are the life killing system conditions which not only kills a very particular instance of service but may also affect deployment of service. There will not be any run time recovery. The best one can expect is graceful death.
In any SOA enabled environment, typical service interaction can be depicted as:
In this diagram the service under consideration is MyService which is calling right hand side service and being called by right hand side service in some business orchestration.
For Exception/Fault and Error occurrence perspective, exception/fault or error can occur in MyService, or called service or calling service.
For brevity let us call Exception/Fault and Error just Exception. If separation required in Exception/Fault and Error then Exception/Fault and Error will be mentioned explicitly.
As a good exception handling practice any exception occurring in any service should be handled in that service and should be resolved there. If resolution is not possible only then exception should propagated to calling service.
For Ontology perspective, exception can be divided into two broad categories:
1. System
2. Business
And if we go into details of each exception then an exception object (sic!) should have following attributes:
a. Exception Group: most of the applications like to group exception for the resolution and notification perspective.
b. Exception Type: Exception, Error, Warning
c. Internal Exception Code: Code to be used by service internally for logging and identification
d. External Exception Code: Code to be used by calling service
e. Detailed Description of Exception
f. Reporting time for Exception
g. Possible Corrective Action/s
h. Severity
i. Service ID
j. Instance ID: of Service
k. Business Object Name: In some cases/implementations payload and/or stack trace may not contain business object name.
l. Stack trace
m. Payload
The code for exception can follow following nomenclature
Before moving forward let us set some definitions:
1. Exception/Fault: These are the business and system conditions which can cause temporary or permanent disruption of instance of service/s. In most of cases this disruption is temporary and with some efforts (run time only though coded at design time) service instance remains alive and keep on serving the clients.
2. Error: These are the life killing system conditions which not only kills a very particular instance of service but may also affect deployment of service. There will not be any run time recovery. The best one can expect is graceful death.
In any SOA enabled environment, typical service interaction can be depicted as:
In this diagram the service under consideration is MyService which is calling right hand side service and being called by right hand side service in some business orchestration.
For Exception/Fault and Error occurrence perspective, exception/fault or error can occur in MyService, or called service or calling service.
For brevity let us call Exception/Fault and Error just Exception. If separation required in Exception/Fault and Error then Exception/Fault and Error will be mentioned explicitly.
As a good exception handling practice any exception occurring in any service should be handled in that service and should be resolved there. If resolution is not possible only then exception should propagated to calling service.
For Ontology perspective, exception can be divided into two broad categories:
1. System
2. Business
And if we go into details of each exception then an exception object (sic!) should have following attributes:
a. Exception Group: most of the applications like to group exception for the resolution and notification perspective.
b. Exception Type: Exception, Error, Warning
c. Internal Exception Code: Code to be used by service internally for logging and identification
d. External Exception Code: Code to be used by calling service
e. Detailed Description of Exception
f. Reporting time for Exception
g. Possible Corrective Action/s
h. Severity
i. Service ID
j. Instance ID: of Service
k. Business Object Name: In some cases/implementations payload and/or stack trace may not contain business object name.
l. Stack trace
m. Payload
The code for exception can follow following nomenclature
Posts
No comments:
Post a Comment