Doorgaan naar hoofdcontent

Service Orientation: Exception handling pattern

Introduction

I am a great fan of the service orientation principles described by Thomas Erl: http://www.soaprinciples.com/
And also of its patterns: http://www.soapatterns.org/
This will not be a sucking up story about Thomas, but the need for a pattern on error handling.

Layering

One of the patterns is that of Service Layering, in which the Services can be categorized in the following layers:


The Utility Service Layer consists of Services that are of agnostic functional nature and are not functional related to a business entity or business process.
The Entity Service Layer contains Services that are related to business entities and are usually also agnostic.
The Task Service Layer is more related to Services that are specific to a particular task or process.
Usually you also have a Orchestrated Task Service layer contains Services that orchestrates Services to fulfill a business process.

My question is how to deal with errors in the separate layers?

Error Types

Let me first describe the type of errors we can have:
  • Technical Errors
    Those are errors of technical nature, like database can not be reached, wrong message format. Mostly internal service errors that occur.
  • Capability Errors
    Those are the errors due to the fact that a capability of a service can not be executed. These errors are more of a functional nature.
  • Business Process Errors
    Those are errors that occur within the logic of a business process.

The next item you have to think about, is which errors you want to expose.

Expose errors?

The first option that comes to mind is that all errors remain internal, using the Abstraction Principle.
However if you think deeper then:
  • Technical errors may kick off other processes that will deal with service errors, by sending mails to maintenance for example. Then technical errors are part of the service contract.
  • A composite controller may handle a capability error by trying it again or using an alternative path.
    A service does (generally) does not know in which activity it participates, so the service can not decide what to do when something happens. Then the error is also part of the service contract.

How to expose errors?

When you decided to expose errors then you have to think about how to expose the errors.
When looking at webservice services you have several options:
  1. Return an error within the output message
  2. Generate a soap fault
  3. Generate a business event that something happend
I am more in favorite of the last two, because the first option always blurs your goodweather logic and this way the maintenance of your code can be more complex.

Conclusion

Hope this gives you some stuff to think about when designing your service contract.
Other suggestions are welcome !

Reacties

  1. Roger, thanks for these insights.

    Some questions that come to mind:
    - Are the options how to expose an error mutual exclusive or is it possible that one error is (concurrently) exposed in multiple ways?
    - Is there a guideline how to either handle errors internally or how to expose them?

    BeantwoordenVerwijderen
  2. Harald,
    Thanks for the questions!

    You can decide to expose an error in multiple ways. This is the same as deciding that capabilities are copied with different granularities. This way consumers have the option to choose.

    About the guideline:
    - Hide technical errors as much as possible
    - Expose functionel errors when really needed

    Other suggestions or guidelines are appreciated.

    Thx
    Roger

    BeantwoordenVerwijderen

Een reactie posten

Populaire posts van deze blog

Microservices mindmap

"The tree" - See also   my photo page When you are fairly new within the Microservices land, there are a lot of terms fired at you. So also for my own understanding i have made a mindmap. I think it has a good status now, so that i can share it with you. As always feedback is very welcome ! You can download the mindmap here .

OSB 10gR3 and SWA and MTOM

This blog is about using soap with attachments and the use of MTOM within the OSB (10gR3). A service is created that accepts a soap with attachment (DocumentService) and translates it to a service that accepts a binary element. MTOM is used for performance reasons for the second. Some notes: * For the use of attachments you need RPC-style document instead of the usual document-style. This due to the fact that the document-style limits a message to a single . * A service can not have both SWA and MTOM within OSB. First a WSDL is setup for the DocumentService: The $attachments variable holds the attachments and the body holds the attachment data. Also other data is stored within the attachment element (see h

Installing Oracle SOA Suite/JDeveloper 11g

This post guides you through the installation of the Oracle SOA Suite 11g with JDeveloper 11 with the use of Oracle XE database (for Windows). Note: It is assumed that Oracle XE database is already installed. Required downloads Oracle Weblogic Server 10.3.1   SOA Suite   Repository Creation Utility JDeveloper Studio The detailed steps are nicely described here . The next picture gives a nice overview of the directory structure created. Step1 -  Create Schemas for Oracle SOA Suite and Oracle BAM (RCU) Unzip the files Run bin/rcu.bat At the Database Connection Details fill in the XE details. If you encounter the next fault you have probably not started the XE database.   Ignore all warnings Click OK Select all components I ran into the following problem: When you click Ok you see the following error: And this is about the Processes DB Init parameter that is wrong. To fix this goto the Database Home page, Sql Editor and execute the following statements: a