OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-tx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Issue 105 - WS-AT: Determine standard fault requirements in WS-AT


This issue is identified as 105.

Please use the subject line for future correspondence on this issue: "Issue 105 - WS-AT: Determine standard fault requirements in WS-AT".

-----Original Message-----
From: Monica.Martin@Sun.COM [mailto:Monica.Martin@Sun.COM]
Sent: Friday, October 27, 2006 4:59 PM
To: ws-tx@lists.oasis-open.org
Subject: [ws-tx] NEW ISSUE: Determine standard fault requirements in WS-AT

Protocol:  WS-AT
Artifact:  spec
Draft:  AT specification, Public Review 01
http://www.oasis-open.org/committees/download.php/20224/wstx-wsat-1.1-spec-pr-01.doc
(Note: The .pdf was used for this issue but the OASIS sites are
currently unavailable for a reference)
Issue type: design
Related issues: 097, 102 (at a minimum)
Issue description:
The Public Review Draft of WS-AT references 3 standard faults in the
State Tables in Section 9. Two of those faults are also referenced in
Section 9 prose and their definitions exist in Section 5.1 and 5.2.
What are the implementation requirements surrounding these standard
faults?

A similar question exists for WS-BA.  Standardizing fault generation may
increase in importance for the compensating transaction model, as that
defined in WS-BA. Note, only WS-AT is addressed here.

It is logical that guidance on standard fault usage should come in WS-AT
(and WS-BA as appropriate) rather than WS-C. For WS-AT, two questions
are important for discussion:

    * The requirements surrounding the use of standard faults in Section
      9 in prose and the State Tables (and as supported in WS-C and
      WS-AT, Section 5.1 and 5.2)
    * Links to WS-C where those standard faults are defined,
      particularly those currently used in WS-AT

Proposed resolution:
Consider in Section 9 "State Tables", WS-AT:

Change from:

    503 ...   Unexpected protocol messages will result in a fault
    504 message, with a standard fault code such as Invalid State or
    Inconsistent Internal State.

Change to:

    503 ...   Unexpected protocol messages SHOULD result in a fault
    504 message. Such fault messages include those standard fault codes
    defined in [WS-COOR] and found earlier in Section 5, Transaction Faults.

Reason for change: Invalid State fault is currently defined in WS-C but
no reference exists in WS-AT to WS-C for that fault (WS-C includes its
definition). Therefore, for simplicity, we have opted to realign the
sentence and provide the WS-C reference. It is recognized there may be
other faults than those specified here, such as those in WS-A. This
reasoning was used in the rewording suggested.

Any TC decision surrounding the rigor of guidance of the use of standard
faults will drive whether or not further statements are made in Section
9, particularly regarding those faults used in the State Tables in that
section. Our actions may also be related to any decisions surrounding
the RFC 2119 review initiated by Actions #56-58, to part of #097, and to
#102.

Note: At this time, the OASIS sites are unavailable due to maintenance.
This issue may be updated when the links are available. Thank you.





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]