Hi Chris, The UPA problem is a huge problem in XML Schema. Here's a few links for how design your xml schemas: http://www.xml.com/pub/a/2004/10/27/extend.html http://www.w3.org/2001/tag/doc/versioning http://www.w3.org/2001/tag/doc/versioning-xml Cheers, Dave <http://www.w3.org/2001/tag/doc/versionin>
_____ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Moesel Sent: Wednesday, March 14, 2007 1:32 PM To: [email protected] Subject: [service-orientated-architecture] Re: Faults vs. Returning Status Types #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/ <http://mlb.com/scores/types> 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 service-orientated- <mailto:service-orientated-architecture%40yahoogroups.com> [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. <http://us.click.yahoo.com/hOt0.A/lOaOAA/yQLSAA/NhFolB/TM> yahoo.com/hOt0.A/lOaOAA/yQLSAA/NhFolB/TM > > ---------------------------------------------------------- > > ~-> > > > > > > Yahoo! Groups Links > > > > > > fullfeatured@ <mailto:fullfeatured%40yahoogroups.com> yahoogroups.com > > >
