NEW issue: WS-AT: Completion protocol should be interminable

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

Issue name -- WS-AT: Completion protocol should be interminable

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:  AT

Artifact:  spec

Draft:

AT spec working draft uploaded 2005-12-02

Link to the document referenced:

http://www.oasis-open.org/committees/download.php/15719/WS-AT%20Working%20Draft.pdf

Section and PDF line number:

WS-AT spec, Section 9 "Use of WS-Addressing Headers", ll. 412-457


Issue type:

Design


Related issues:

Issue [] WS-C/WS-AT: Is request-reply MEP useful?
Issue [] WS-C: Make Register/RegisterResponse retriable
Issue [] WS-BA: Protocols should be terminable


Issue Description:

Define Completion protocol as "interminable".


Issue Details:

This issue assumes that the issue "WS-C/WS-AT: Is request-reply MEP 
useful?" has been resolved in such a way
as to define a concept of "interminable exchanges". The Completion 
protocol in WS-AT is an example of a
protocol where there is no reason to mandate that the relationship 
between the "Initiator" and the
"Coordinator" will ever end. In the Choreology product we maintain 
"eternal logs". It is possible to respond
to an enquiry by returning the final status of a completed transaction. 
WS-AT lacks a status enquiry message,
but an intentional or inadvertent double commit or double rollback can 
play this role.

Currently Section 9 of WS-AT does not define the nature of the 
Completion protocol messages Commit/Committed,
and Rollback/Aborted, which are distinct in meaning from the messages 
with the same name in the 2PC protocols.

The type or category of these messages should be defined, and it seems 
unnecessary to define any as having the
type "terminal notification".


Proposed Resolution:

Insert into Section 9 text stating:

"The Completion protocol messages Commit, Rollback, Committed and 
Aborted are all notification messages.
Commit and Rollback can be sent to by the Initiator to the Coordinator 
even if one of Committed or Aborted has
already been received by the Initiator. The exchanges Commit - Committed 
| Aborted, and Rollback - Committed |
Aborted are interminable, therefore."