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

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

This is hereby declared to be ws-tx Issue 010.

Please follow-up to this message or ensure the subject line starts Issue
010 - (ignoring Re:, [ws-tx] etc)

The Related Issues list has been updated to show the issue numbers.


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

Owner:  Alastair Green [mailto:alastair.green@choreology.com]

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 009 - WS-C/WS-AT: Is request-reply MEP useful?
 Issue 007 - WS-C: Make Register/RegisterResponse retriable 
 Issue 011 - 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."