#4 seems like a nice option, except one caveat. I actually want to
allow for future extensibility by adding an xsd:any element w/ 0 to n
occurrences. So really, we're looking at a schema more like this:
<xsd:complexType name="GetTodaysRedSoxScoreResponseType">
<xsd:sequence>
<xsd:element name="Status" type="xsd:string" />
<xsd:element name="Opponent" minOccurs="0" type="xsd:string" />
<xsd:element name="SoxScore" minOccurs="0" type="xsd:int" />
<xsd:element name="OpponentScore" minOccurs="0" type="xsd:int" />
<xsd:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
With the minOccurs="0" on the other elements (#4 in my previous
options), this causes validation problems:
Schema validation error on node xsd:complexType
"http://mlb.com/scores/types":Opponent and WC[##any] (or elements from
their substitution group) violate "Unique Particle Attribution".
During validation against this schema, ambiguity would be created for
those two particles.
I guess we can fix this by moving the Status element so it is the last
element before the xsd:any. Then it validates fine. But I kind of
like the Status element being first... Oh well... Who ever said SOA
was easy? ;-)
Thanks for your thoughts so far. They've been helpful.
-Chris
--- In [email protected], 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:
> >
> > <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]
> >
>
