I agree with you, Chris, none of the listed solutions look good tome too.
The problem here is that the response is defined w/o a context while the
problem you face is the context-based. The business context in your case is a
Game Calendar.
The Game Calendar event (probably, including the time of the day because the
game may be in progress when request comes and you might need to add more
logic to cover current score rather than the final score) has to be checked to
make a decision which response to send back - the
GetTodaysRedSoxScoreResponseType or "NO_GAME_SCHEDULED". You can define an
enumeration of all answers using a 'choice' XSD element, for example.
I am afraid, your example does not relate directly to the topic "Faults vs.
Returning Status Types". I think that resolution of the topic issue based on
system error vs. application/business exception is consistent enough and does
not require further discussion.
- Michael Poulin
Chris Moesel <[EMAIL PROTECTED]> 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
---------------------------------
Don't get soaked. Take a quick peek at the forecast
with theYahoo! Search weather shortcut.
