 | Mailing List | | Home | | Forum Home | | JBoss - Java Application Server | | Struts - A MVC web framework | | Tomcat - JSP/Servlet container | | iText - An open source PDF Java Library | | JDOM - JDOM XML Parser | | J2EE - A mailing list for Java(tm) 2 Platform, Enterprise Edition | | J2EE Pattern - An interest list for Sun Java Center J2EE Pattern Catalog | | Servlet - A mailing list for discussion about Sun Microsystem's Java Servlet API Technology | | JSP - A mailing list about Java Server Pages specification and reference | |
Struts & Hibernate
|
|
|
| | | Error Handling Strategy in an SOA | Error Handling Strategy in an SOA 2004-01-21 - By Eric Parker
Back
Handling error messages in a widescale distributed system is always
challenging. Codes are certainly one possibility. Another option is
using constant definitions for error messages. Constants have the
advantage of being readable in log traces, while also functioning as
lookup keys. They can also be extended with additional detail text for
extra trace information. We use this approach in our framework generator,
details at
http://sandboss.org/sand/apps/basics/docs/javadoc/org/sandev/basics/structs
/SandTransmitMessage.html
If you have a small number of errors, it might be reasonable to leave error
handling to each client. If there are a lot of codes/constants then you
could set up a translation service, or provide a translation files that
each client can load and use.
HTH.
cheers,
-ep
At 12:26 PM 1/21/04 -0700, you wrote:
>Hi,
>
>I am looking for best practices, patterns for handling errors (business
>and system) in a service-oriented architecture. The requirements I'm
>trying to address here are as follows:
>
> * Participating services shall throw a service exception encapsulating
> the business / system error.
> * Consumers could be UI-based that need to comply with I18N as well as
> batch-oriented systems (could be COTS-based systems e.g. based on SAP).
>Here are some of my questions:
>
> * Should the services return error codes that then gets resolved into
> a message and possibly even internationalized by the consumer service?
> Each consumer would need to be aware of all possible error codes,
> messages and any associated parameters from the services.
> * Should the responsibility for the management of error codes and
> their translation be handled by a totally different service (some sort of
> an Error Director) that is also I18N-aware? Overkill?
> * Should each service in the SOA be responsible for I18N - in other
> words upon error, the Service would return a fully I18N message back to
> the consumer. This would require the Consumer to let the Service know of
> its language preferences, though.
>Any pointers to best practices / patterns would be much appreciated.
>
>Thanks
>vp
>====================================================================
>Companion Site: http://www.corej2eepatterns.com J2EE BluePrints:
>http://java.sun.com/blueprints/corej2eepatterns List Archive:
>http://archives.java.sun.com/archives/j2eepatterns-interest.html
>Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
Eric Parker
SAND Solutions Architect
phone: 617.721.4350
http://www.sandservices.com
====================================================================
Companion Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
<html>
Handling error messages in a widescale distributed system is always<br>
challenging. Codes are certainly one possibility. Another
option is<br>
using constant definitions for error messages. Constants have
the<br>
advantage of being readable in log traces, while also functioning
as<br>
lookup keys. They can also be extended with additional detail text
for<br>
extra trace information. We use this approach in our framework
generator,<br>
details at<br>
<a href="http://sandboss.org/sand/apps/basics/docs/javadoc/org/sandev/basics
/structs/SandTransmitMessage.html" eudora="autourl">http://sandboss.org/sand
/apps/basics/docs/javadoc/org/sandev/basics/structs/SandTransmitMessage.html</a>
<br><br>
If you have a small number of errors, it might be reasonable to leave
error<br>
handling to each client. If there are a lot of codes/constants then
you<br>
could set up a translation service, or provide a translation files
that<br>
each client can load and use.<br><br>
HTH.<br>
cheers,<br>
-ep<br><br>
<br>
At 12:26 PM 1/21/04 -0700, you wrote:<br>
<blockquote type=cite class=cite cite><font face="arial" size=2>Hi,</font><br>
<br>
<font face="arial" size=2>I am looking for best practices, patterns for
handling errors (business and system) in a service-oriented architecture.
The requirements I'm trying to address here are as follows: </font><br>
<ul><font face="arial" size=2>
<li>Participating services shall throw a service exception encapsulating
the business / system error.
<li>Consumers could be UI-based that need to comply with I18N as well as
batch-oriented systems (could be COTS-based systems e.g. based on SAP).
</font>
</ul><font face="arial" size=2>Here are some of my
questions:</font><br>
<ul><font face="arial" size=2>
<li>Should the services return error codes that then gets resolved into a
message and possibly even internationalized by the consumer service? Each
consumer would need to be aware of all possible error codes, messages and
any associated parameters from the services.</font>
<font face="arial" size=2>
<li>Should the responsibility for the management of error codes and their
translation be handled by a totally different service (some sort of an
Error Director) that is also I18N-aware? Overkill?</font>
<font face="arial" size=2>
<li>Should each service in the SOA be responsible for I18N - in other
words upon error, the Service would return a fully I18N message back to
the consumer. This would require the Consumer to let the Service know of
its language preferences, though.</font>
</ul><font face="arial" size=2>Any pointers to best practices / patterns
would be much appreciated.</font><br>
<br>
<font face="arial" size=2>Thanks</font><br>
<font face="arial" size=2>vp</font><br>
====================================================================
Companion Site:
<a href="http://www.corej2eepatterns.com/" eudora="autourl">http://www
.corej2eepatterns.com</a>
J2EE BluePrints: <a href="http://java.sun.com/blueprints/corej2eepatterns"
eudora="autourl">http://java.sun.com/blueprints/corej2eepatterns</a> List
Archive: <a href="http://archives.java.sun.com/archives/j2eepatterns-interest
.html" eudora="autourl">http://archives.java.sun.com/archives/j2eepatterns
-interest.html</a> Unsubscribing: email "signoff J2EEPATTERNS-INTEREST"
; to listserv@(protected) </blockquote><br>
<br>
<br>
<div>Eric Parker</div>
<div>SAND Solutions Architect</div>
<div>phone: 617.721.4350</div>
<div><a href="http://www.sandservices.com/" EUDORA=AUTOURL>http://www
.sandservices.com</a></div>
</html>
====================================================================
Companion Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
|
|
|
