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: > > <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 > > > > > ------------------------ 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 Sponsor --------------------~--> Great things are happening at Yahoo! Groups. See the new email design. http://us.click.yahoo.com/lOt0.A/hOaOAA/yQLSAA/NhFolB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
