JJ
I implemented the following pattern in my webservice. Below is a
simplified view.
When calling a webmethod, I see two types of errors:
1. Subsystem errors. Like: there is no connectivity between the client
app and the webservice, etc. These are errors that are independent from
my code inside the webservice
2. System errors. These errors are the direct or indirect effect of my
code inside the webservice. Like: executing a select statement while
the database is down, or raising an error from inside my own code, etc,
etc.
Now, my design pattern says:
A. Errors of type 1 should be handled by the client side. For example,
you should identify the error and display "There is no conectivity with
the server", etc.
B. Errors of type 2 should ALWAYS be handled by my code. Then the
caught exception will be sent to a method that will identify it and
will assign a unique error code along with some text that will describe
the error. Usually it is the Message of the Exception.
Unidentified exception should have also an error code. I also assign a
severity level for each identified exception; for now, I have only 2
severity levels: warning and error.
So, when an exception of type 2 occurs, I create an XML string
containing:
- the error code obtained after the exception is identified
- the error text. Each exception caught has a Message
- the severity level; my case: warning or error
Now, the information about the error is ready. We only have to
transport it to the client.
I chose to transport it using an SoapException object. How? I fill the
Detail member with the information about the error and throw the
SoapException object.
The client will listen for exceptions of SoapException type and will
analyse them.
If the object caught has its Detail member null, then we know that the
exception is of type 1 and try to identify the exception on the client
side. If Detail property is not null, you just have to interpret the
data contained inside and provide to the user the apropriate feedback.
Now, in my real application, I have to deal with errors and warnings
inside my webservice. Errors are simple: when you encounter one just
rollback some operations if needed and exit. Anyway, warnings bring a
bit of complexity here. I mean, you need to warn the user about
something, but this doesn't mean you have to exit. Au contraire, you
need to continue processing and at the end TO RETURN THE RESULT OF
PROCESSING.
I solved this issue by defining a Response object that contains 2 main
parts:
1. A header containing error and/or warning messages. Why multiple?
Because when processing, you could yield multiple warning messages in a
single request.
2. A data section that contains the results of the processing.
My methods always return an xml string that describe such an Response
object that will be recreated on the client side.
Jens Jensen a scris:
Hello all,
I need some design advice for my web service.
I' have written a web service that exposes a function that takes some
parameters
and return an xml.
The function have up to 10 parameters. There are many situations where the
function returns an error xml.
The parameters need to be checked in many differents ways (10 power X ways).
So an error xml is just returned to the caller.
I'm looking for a pattern to best implement this. So far, i have written a
working code but , i'm not really proud of writing this code.
I beleive /i'm convinced it can be done much better. The code does works as
it should. The only problem is the design.
I'm looking at some pattern (maybe GOF) or other patterns that can be used.
Any idea?
Thanks
JJ