Great question. Here's a small, technical tidbit to consider that
I've discovered through trial and error, faults may be a security
flaw because they could leak information they shouldn't back to the
consumer.
In my SOA for retail chains I only use a return structure that
includes a text description, a code and a boolean as well as an array
of data containing returned data if needed. If you don't have a
valid token, the only thing you get back is a message telling you
that you don't have a valid token. However, an improperly designed
fault generated off a try...catch block in code can accidentally
release more information than you intended and can may be able to be
used by hackers to figure out how to breach the service.
JP
__________________________________
JP Morgenthal
President & CEO
Avorcor, Inc.
46440 Benedict Drive
Suite 103
Sterling, VA 20164
(703) 444-1130 : Office
(703) 554-5301 : Cell
[EMAIL PROTECTED]
__________________________________
Powering the next generation of multi-channel execution...
On Mar 13, 2007, at 3:57 PM, Chris Moesel wrote:
Summary of Question:
When is it best to return a fault vs returning a status element as
part of the response? If you believe faults should only be returned
on system-level exceptions, then what if a required element in the
response is inapplicable because of an application-level exception?
How do you resolve that?
Details of Question:
It seems to be a popular opinion that faults should be reserved for
system exceptions (that is, unexpected errors) and status elements
should be used for application exceptions (those errors that are
expected to occur in regular business interactions). While I agree
that this seems a good idea, I've run into one problem. Here is an
example:
Suppose I have an operation called GetTodaysRedSoxScore. The response
XSD might look like this:
<xsd:complexType name="GetTodaysRedSoxScoreResponseType">
<xsd:sequence>
<xsd:element name="Status" type="tns:StatusType" />
<xsd:element name="Opponent" type="xsd:string" />
<xsd:element name="SoxScore" type="xsd:int" />
<xsd:element name="OpponentScore" type="xsd:int" />
</xsd:sequence>
</xsd:complexType>
Now suppose that someone invokes this operation on the Red Sox's day
off. Since this is really an application-level exception, many would
say we should return a status indicating "NO_GAME_SCHEDULED" or
something like that (instead of using a fault). BUT… Opponent,
SoxScore, and OpponentScore are all required elements… What do I do?
(1) Exclude these elements from my response (thus returning XML that
is not valid against my own schema)?
(2) Return default values for the required elements (empty string for
string, 0 or -1 for int, etc)?
(3) Change the XSD to make all elements nillable?
(4) Change the XSD to make all elements minOccurs="0"?
I don't really like any of these options, so I'm tempted to use a
fault, even though it's not a system level exception.
What is the best practice concerning when it it appropriate to use
faults vs. returning status elements?
-Chris
