OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-tx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ws-tx] Issue 085 - WS-BA: Protocol messages should be redefined toprovide specific guarantees


Ram

I would agree with the proposed changes with the following clarifications:

Should the fault Fault be modified to distinguish between ParticipantCompletion & CoordinatorCompletion (i.e. Completing/Fault only occurs for the latter).

Exit

Regards
Tom
Inactive hide details for "Ram Jeyaraman" <Ram.Jeyaraman@microsoft.com>"Ram Jeyaraman" <Ram.Jeyaraman@microsoft.com>


          "Ram Jeyaraman" <Ram.Jeyaraman@microsoft.com>

          07/22/2006 12:47 AM


To

<ws-tx@lists.oasis-open.org>

cc


Subject

[ws-tx] Issue 085 - WS-BA: Protocol messages should be redefined to provide specific guarantees

This is identified as WS-TX issue 085.

Please ensure follow-ups have a subject line starting "Issue 085 – WS-BA: Protocol messages should be redefined to provide specific guarantees".

From: Ram Jeyaraman [mailto:Ram.Jeyaraman@microsoft.com]
Sent:
Friday, July 21, 2006 10:44 PM
To:
ws-tx@lists.oasis-open.org
Subject:
[ws-tx] NEW Issue - WS-BA: Protocol messages should be redefined to provide specific guarantees

Protocol: WS-BA

Artifact: spec

Draft: BA specification CD 02

Link to the document referenced:

http://www.oasis-open.org/committees/download.php/18818/wstx-wsba-1.1-spec-cd-02.pdf

Section and PDF line number: sections 1, 3.1 and 3.2

Issue type: design

Related issues:

Issue Description:

It is fundamentally important for interoperability that the BA specification provide a clear definition of the semantics of each protocol message, in order to establish the precise state management guarantees that must be provided by a conformant implementation.

For example, the current definition of Compensated does not indicate that the participant should actually complete its compensation efforts before sending the message. For a participant to return this message, all it has to do is record a compensation request. It is not clear what has happened or will happen to the work that needs to be compensated

As another example, the current definition of the Exit message does not clearly state what happened to the work performed by the participant prior to exiting. Was the work successfully cancelled? Or perhaps no work was performed at all?

Similarly, other protocol messages need to be reviewed to ensure that specific guarantees are provided.

Proposed resolution:

Modify the message definitions as follows:
The coordinator accepts:
Completed Fault Compensated Closed Canceled Exit The participant accepts:
Close Cancel Compensate Faulted Exited Further, the following statement in the Introduction section of the specification should be modified from:
“All notifications are acknowledged in the protocol to ensure a consistent view of state between the coordinator and participant.”
to
“All non-terminal notifications are acknowledged in the protocol to ensure a consistent view of state between the coordinator and participant. A coordinator or participant may retry sending notifications in order to achieve this.

GIF image



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]