The question of exception vs result is not trivial and not limited to SOA. I've heard so many times that you can recognize a good developer just by looking at its exception handling. We have this in all programming languages where the concept of exception exists. For me, a no data found is not an exception (a fault) but if this no data found is because the service implementation was not able to reach the Database, it is. Faults must be triggered when the service was not able to complete for technical reasons (most often infrastructure related) or in the case of an unexpected bug.
The problem here is that it is not possible to put a constraint in XML Schema like: if the status is "OK", then the elements are required, elsewhere they are not. You can do this in Schematron but not with XML Schema validation. I personnaly never activate XML schema validation at runtime. I think XML schema validation is not strong enough and does not replace validation logic in the service implementation. My prefered way to design such a service would be to put the status as an attribute of the GetTodaysRedSoxScoreResponse. The score as such could be a reusable element. If you create a specific complexType containing Opponent, SoxScore and OpponentScore, you don't have this problem of validation anymore. Your XML should look like this: <GetTodaysRedSoxScoreResponseType status="..."> <soxGameScore gameDate="..."> <opponent>...</opponent> <soxScore>...</soxScore> <opponentScore>...</opponentScore> </soxGameScore> </GetTodaysRedSoxScoreResponseType> If you work this way, you can perfectly have a minOccurs=0 on the element soxGameScore and still have meaningfull constraints on the elements opponent, soxScore and opponentScore. This new element soxGameScore could be used as well in other operations like getting the score for a date in the past or having the list of all scores for a complete season. Best regards. Robin --- In [email protected], "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 >
