Todd, your explanations are very good for OO development. In SOA, the
service is not an object with published interface, it has to have a business
meaning (for the described case). The SOA RM standard defines a notion of
business execution context to avoid cases like this.
No requests or answers/responses may be done in SOA outside of the context.
This is why it does not make sense to guess which one of the four offered
"solutions" is correct - none of them is. When you look at the context of the
service such as a Game Calendar, you easily find simple solution to this
problem.
Also, I am afraid you interpret 'exception' in too programmatic way. Abnormal
things, in many cases, are regular business things. If business is modeled
properly, you would get a sort of application/business exceptions and related
solutions/scenarios for them.
In your own example with query returning an empty address, "a zero record
response", your program does not fail. The error is possibly in the data
quality control. It is not obvious whose fault it is - your program's one or
business operation's one (that did not insert an address for particular
entity). Plus, it may be fine from business perspective not having an address
available at the moment of the request. This is the risk of using internal
identifier w/o a request context.
I apologies for the mentor tone and hope I do not sound offensive.
- Michael Poulin
Todd Biske <[EMAIL PROTECTED]> wrote: I tend to agree with the popular
opinion, although I wouldn't use the
terms system exception and application exception. An exception,
regardless of the adjective before it, should represent something
abnormal (not necessarily unexpected though). In your example, as
you rightly point out, there are days off during the baseball
season. Therefore, a request for the score on a day when there is no
game should not be considered abnormal. Interestingly, however, a
request for the score in January would be.
The example I always use in this discussion is the data query that
returns zero records. There isn't a blanket statement that says it
should be a fault condition or not. If I'm asking for the address of
a customer and passing in an internal identifier that could only have
been retrieved from the database, a zero record response should be
considered a fault. If I'm asking for the order activity for that
customer for today, however, a zero record response is perfectly normal.
One caveat that should be considered is the view of intermediaries
and management systems on the use of faults. If you used a fault in
your example, a WSM system will show a 100% failure rate for that
operation on days when the Red Sox don't play. I doubt that's what
you want.
As far as which option to use, I'd tend toward options 3 or 4 as they
are the only ones that result in a correct description of the
message. My personal preference would be 4. Creating responses that
don't validate doesn't make sense, and throwing in dummy values isn't
much better. Again, you need to be concerned about the view that
other systems may have on the in flight messages. Again, if the
intermediary is collecting messages for out-of-band analysis, now you
need to put in special processing to tell it to ignore your dummy
elements, rather than relying on the schema definition itself to give
appropriate information to analytical systems.
Also, I agree with JP. If you're exposing services to external
consumers, you need to unsure that uncaught exceptions don't turn
into SOAP faults with embedded stack traces. One approach is to
direct all traffic, whether outgoing or incoming, through an XML/WS
Gateway that can capture these internal faults and turn them into a
generic fault that won't disclose inappropriate information.
-tb
On Mar 13, 2007, at 2: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:
>
>
>
>
>
>
>
>
>
>
> 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
>
>
>
>
> ------------------------ Yahoo! Groups Sponsor --------------------
> ~-->
> Yahoo! Groups gets a make over. See the new email design.
> http://us.click.yahoo.com/hOt0.A/lOaOAA/yQLSAA/NhFolB/TM
> --------------------------------------------------------------------
> ~->
>
>
> Yahoo! Groups Links
>
>
> [EMAIL PROTECTED]
>
Yahoo! Groups Links
---------------------------------
Finding fabulous fares is fun.
Let Yahoo! FareChase search your favorite travel sites to find flight and hotel
bargains.
