Issue 003 - WS-C: Appropriate categories of fault

["Peter Furniss" <peter.furniss@choreology.com>]

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.