[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue 003 - WS-C: Appropriate categories of fault
This is hereby declared to be ws-tx Issue 003. Please follow-up to this message or ensure the subject line starts Issue 003 - (ignoring Re:, [ws-tx] etc) The Related Issues list has been updated to show the issue numbers. Issue name -- WS-C: Appropriate categories of fault Owner Alastair Green [mailto:alastair.green@choreology.com] Protocol: Coord Artifact: spec / schema Draft: WS-Coordination spec working draft uploaded 2005-12-02 WS-Coordination schema contributed by input authors, not yet uploaded to Working Drafts folder Link to the document referenced: http://www.oasis-open.org/committees/download.php/15738/WS-Coordination- 2005-11-22.pdf Section and PDF line number: Section 4 "Coordination Faults", ll. 371-468 Issue type: Design Related issues: Issue 004 - WS-C: Add new fault CannotCreateContext Issue 005 - WS-C: Add new fault CannotRegisterParticipant Issue 006 - WS-C: Remove fault 4.4. NoActivity Issue 008 - WS-C: Remove fault 4.6 AlreadyRegistered Issue 012 - WS-C: Make precise, permissive statement relating to methods of context propagation Issue 013 - WS-C: Remove fault 4.5 ContextRefused Issue Description: Faults in WS-C should be divided into two categories: those which apply to the process of context creation and registration (or which apply to the misuse of the conversational channel created by registration), and those which are basic faults available to all coordination protocols. Issue Details: [This issue stems from Choreology Contribution issue TX-19.] This issue is a methodological issue that relates to additional issues relating to specific cases (see "Related issues" above). Adoption of the principles stated in the proposed resolution of this issue will guide the resolution of those specific issues; conversely, appropriate resolution of the specific issues may render this issue inoperable. However, it is likely to be valuable to consider the general approach in conjunction with the individual issues. Faults in WS-C should be divided into only two categories: those which apply to the process of context creation and registration (or which apply to the misuse of the conversational channel created by registration), and those which are basic faults required by all coordination protocols. The spec as it stands suffers from three related defects: 1. Faults are not defined to permit rejection of attempts to create contexts or register participants. Examples: no CannotCreateContext, no CannotRegisterParticipant. 2. Faults are defined which are not truly basic or general to all coordination protocols, and which therefore should be removed. Examples: NoActivity, AlreadyRegistered. 3. A fault, ContextRefused, is defined which relates to the operation of a context-propagating application protocol. Proposed Resolution: Named faults should be added to permit the ActivityService and RegistrationService to repudiate legal messages that cannot be processed at run-time. Faults that apply to the behaviour of some but not all conceivable coordination protocols should be defined by the specification of each individual coordination protocol, and should not be specified in WS-Coordination. Faults that apply to the interactions of application elements (as opposed to the interactions of Coordinators and Participants, viewed as roles in a coordination protocol), e.g. those relating to potential unwillingness or incapacity to use a propagated context, should not be specified in WS-Coordination.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]