Code design ideas?

[Jens Jensen]

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

 

[adi]

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:

 

[Jens Jensen]

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.

Hi Adi,
Is this a standard pattern or an home made one? I strive to use standard
method. But i do understand they might not always apply in particular cases.
If what you describe is in fact a standard pattern then, where can i read
more about it?


Many thanks
JJ

 

[adi]

Sorry, this is my "hand-made" pattern.
No standard pattern I read about satisfied all my needings.
If you find one, I kindly ask you to post it here.

Thanks.
Adi.


Jens Jensen a scris:

 

[Jens Jensen]

Hi Adi,
I found the belwo:
http://msdn2.microsoft.com/en-us/library/aa480534.aspx

Maybe you also might want to have a look.
Thanks
JJ

 

[Samuel R. Neff]

I would personally shy away from any web-service that directly returns
XML or forces the caller to directly handle XML. The power of web
services is in the automatic serialization and deserialization of
native objects to XML. As soon as you return XML from a web service
then you're forcing the caller to work with XML directly when the web
service library in their language would most likely have abstracted
this away for them.

The same is true for errors, Web Services have a standard way to deal
with errors and you can take advantage of this simply by throwing
errors in your web service method, which will be serialized to XML
according to SOAP standards and most client libraries will handle it
accordingly.

So I would say don't return XML and don't handle errors differently.
Certainly you want to trap internal errors and translate them to
something the caller will understand and can work with, but don't
return something that purports to be an OK resopnse (i.e., not a
standard SOAP error) which is really a custom error format.

HTH,

Sam

 

[Jens Jensen]

I would personally shy away from any web-service that directly returns
XML or forces the caller to directly handle XML. The power of web
services is in the automatic serialization and deserialization of
native objects to XML. As soon as you return XML from a web service
then you're forcing the caller to work with XML directly when the web
service library in their language would most likely have abstracted
this away for them.

The same is true for errors, Web Services have a standard way to deal
with errors and you can take advantage of this simply by throwing
errors in your web service method, which will be serialized to XML
according to SOAP standards and most client libraries will handle it
accordingly.

So I would say don't return XML and don't handle errors differently.
Certainly you want to trap internal errors and translate them to
something the caller will understand and can work with, but don't
return something that purports to be an OK resopnse (i.e., not a
standard SOAP error) which is really a custom error format.

HTH,

Sam

Hi Sam,
Thank you for your very interesting input to this discussion and i do
understand your point.
Can you provide link to some online resources on this subject?

I used this method after consuming an oracle application web service.
I know wonder why they have adopted this strategy?

Thanks
JJ

 

[Samuel R. Neff]

Here's a good starting point on MSDN. The links include a design
guideline page (which is unfortunately brief) and discussion of error
handling:

http://msdn2.microsoft.com/en-gb/library/ba0z6a33.aspx

Also as a learning experience I would highly recommend writing a few
web services in several languages (particularly .NET and Java) and
then writing client code to consume each from every language. Be sure
to include services that both accept and return complex content. That
experience of programming cross-language web services will give you a
better understanding of developing client-friendly web services.

Best regards,

Sam

 

[MBocciaMcArt]

Hello ! JJ (e-mail address removed) , ) ,
Are you the same professional that went to Brazil - DK - for F.L.Smidth
S/A,
to work for the project - cement industry MAUA-CANTAGALO ?

If so... - Do you still works for F. L. Smidth DK ????

Jens Jensen escreveu:

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Hello ! JJ (e-mail address removed) , ) ,
Are you the same professional that went to Brazil - DK - for F.L.Smidth
S/A,
to work for the project - cement industry MAUA-CANTAGALO ?

It could be your old friend, but note that Jens Jensen is not an unusual
name in Denmark.

[the danish statistical agency claims that there are 4579
of them]

Arne