NEW issue: WS-C: Appropriate categories of fault

[Alastair Green <alastair.green@choreology.com>]

Issue name -- WS-C: Appropriate categories of fault

PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON THREAD UNTIL 
THE ISSUE IS ASSIGNED A NUMBER.

The issues coordinators will notify the list when that has occurred.

Target document and draft:

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 [] WS-C: Add new fault CannotCreateContext
Issue [] WS-C: Add new fault CannotRegisterParticipant
Issue [] WS-C: Remove fault 4.4. NoActivity
Issue [] WS-C: Remove fault 4.6 AlreadyRegistered
Issue [] WS-C: Make precise, permissive statement relating to methods of 
context propagation
Issue [] 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.