Though my comment does not relate to this Forum, I cannot resist, sorry.
Robin wrote: " I personally 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."
I do opposite, always. XML schema written with required level of details,
provides control for data quality. If an XML Schema is used for just
meta-description, I think, it is too expensive exercise. I also use XML Schema
for generation of Java objects to control data quality once again. This saved
me many times from the 'data owners' who tended to give me what they had
instead of what they promised to give me.
I do not try to substitute a business logic with a schema, no way. However, I
distinguish between simple business data validation and business validation
based on rules applied to data - the XML Schema perfectly works for me in the
first case.
- Michael
Robin <[EMAIL PROTECTED]> wrote:
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
>
---------------------------------
Be a PS3 game guru.
Get your game face on with the latest PS3 news and previews at Yahoo! Games.
