[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: NEW ISSUE: WS-AT: Make completion protocol request-reply, permittinganon
My apologies to the committee. I overlooked sending this issue in before the deadline -- it was one I had noted down from the Dublin face-to-face, and I had intended to put it in with the WS-BA batch. I hope the TC will stretch a point on Friday's deadline... Thanks, Alastair Issue name -- WS-AT: Make completion protocol request-reply, permitting anon PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON THREAD UNTIL THE ISSUE IS ASSIGNED A NUMBER. The issues coordinator will notify the list when that has occurred. Target document and draft: Protocol: WS-AT Artifact: spec Draft: AT spec cd 2 Link to the document referenced: http://www.oasis-open.org/committees/download.php/18888/wstx-wsat-1.1-spec-cd-02.doc Section and PDF line number: Section 4.2 "Completion Protocol"; Section 9, "Use of WS-Addressing Headers" Issue type: Design Related issues: Issue Description: A client that initiates a transaction using WS-Coordination CreateCoordinationContext can do so using one-ways, or the anonymous back-channel. The latter facility was added to permit "thin clients" (ones that cannot listen for inbound messages) to initiate an activity. Such a client is likely to have responsibility for terminating the transaction, and it would therefore be appropriate to make the completion protocol have the same characteristics. Issue Details An interoperable client program is very likely to wish to conduct the following sequence of actions: a) send CreateCoordinationContext to the Activation Service of a Coordination Service b) send Register for the AT Completion Protocol to the Registration Service of a Coordination Service c) send AT Completion Protocol Commit or Rollback to the Coordinator for the activity within the Coordination Service. It was accepted at the Dublin F2F that activities a) and b) should be allowed to use the anonymous back channel for the CCCResponse and RResponse replies, allowing the client program to be a thin client, i.e. one that is unable to listen for unsolicited inbound messages. It seems illogical to prevent a thin client conducting all three of the actions in this common sequence. The inability to do c) is likely to vitiate the purpose of the accepted change allowing such a client to enact a) and b). Proposed resolution Specify that WS-AT Completion Protocol has the same addressing characteristics as WS-Coordination, i.e. that the [reply endpoint] property is used to indicate the target of the expected response, and that that endpoint reference is permitted to have the WS-A anonymous URI as its URI.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]