[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Proposed clarificaiton resolutions to Ferris comments 1,2,24,5,7,9,16,19
Proposed resolutions for some of Chris Ferris comments on WS-Reliability ED 1.05: Comments 1, 2, 24: Need to clarify that no implementation details are prescribed for abstract RMP operations: Proposed clarification: Add at the end of line 85 the following sentence to the qos bullet: “ These abstract operations are associated with processing of an RMP, however implementation aspects regarding how, or when, they are invoked are not prescribed by this specification. “ Add the following new paragraph between lines 105 and 106, before the Note “ The direction of the arrows for the qos contract abstract operations, shown in Figure 1, represents the direction of information flow associated with the operation. Implementation details of how these operations are invoked, including which entity invokes the abstract operation, are not prescribed by this specification. “ Lines 182-198: generalize the definitions of the four abstract operations “ Deliver: An abstract operation supported by the RMP. When invoked on a Receiving RMP, the operation makes the payload of one Reliable Message available to the Consumer. For example, in one specific implementation choice, the payload is placed into a queue by the Receiving RMP to be consumed by an application component. Submit: An abstract operation supported by the RMP. When invoked, the operation transfers payload data from the Producer to the Sending RMP (e.g., a request to the Sending RMP to take responsibility for the Reliable Message). Respond: An abstract operation supported by the RMP. When invoked, the operation transfers payload data from the Consumer to a Receiving RMP. Notify: An abstract operation supported by the RMP. When invoked, the operation makes available a response payload received by the Sending RMP, to the Producer, or makes available to the Producer the status of a Reliable Message (e.g., a notification that the Sending RMP failed to send a Reliable Message). “ with the following: “ Deliver: An abstract operation associated with a Receiving RMP. When invoked, the operation makes the payload of one Reliable Message available to the Consumer from the Receiving RMP. For example, in one specific implementation choice, the payload is placed into a queue by the Receiving RMP to be consumed by an application component. Submit: An abstract operation associated with a Sending RMP. When invoked, the operation transfers payload data from the Producer to the Sending RMP (e.g., a request to the Sending RMP to take responsibility for the Reliable Message). Respond: An abstract operation associated with a Receiving RMP. When invoked, the operation transfers payload data from the Consumer to a Receiving RMP. Notify: An abstract operation associated with a Sending RMP. When invoked, the operation makes available a response payload received by the Sending RMP, to the Producer, or makes available to the Producer the status of a Reliable Message (e.g., a notification that the Sending RMP failed to send a Reliable Message). “ Comment 5: WSRM TC has agreed to fix unnecessary use of Soap 1.2 terminology Proposed resolution, agreed at July 13 WSRM TC meeting: Line 67-68: change sentence: “ WS-Reliability is a SOAP Module (as defined by [SOAP 1.2]), which fulfills reliable messaging requirements that are critical in some applications of Web Services. “ to: “ WS-Reliability is a SOAP based specification, which fulfills reliable messaging requirements that are critical in some applications of Web Services. “ Lines 166-170: change “ Reliable Messaging Processor (RMP): A SOAP Node (as defined by [SOAP 1.2]), or a subset or superset thereof, capable of performing Reliable Messaging as described by this specification. With regard to the transmission of a Reliable Message from one RMP to another, the former is referred to as the Sending RMP, and the latter as the Receiving RMP. An RMP may act in both roles. “ to: “ Reliable Messaging Processor (RMP): A SOAP processing element, capable of performing Reliable Messaging as described by this specification. With regard to the transmission of a Reliable Message from one RMP to another, the former is referred to as the Sending RMP, and the latter as the Receiving RMP. An RMP may act in both roles. “ Comment 7: Message Delivery is not the end of Receiving RMP processing Proposed clarification: Lines 204-206: change “ Message Delivery: The action of invoking the “deliver” operation for a Reliable Message. This action marks the end of the RMP processing for this message. “ to “ Message Delivery: The action of invoking the “deliver” operation for a Reliable Message. “ Comment 9: Use of the word implement with Abstract operation Proposed clarification: Lines 256-257: change “ An RMP acting in the role of a Sending RMP MUST implement Submit, and notification of failure (Notify). An RMP acting in the role of a Receiving RMP MUST implement Deliver. “ with “ An RMP acting in the role of a Sending RMP MUST support use of Submit and Notify. An RMP acting in the role of a Receiving RMP MUST support use of Deliver. “ Comment 16: MUST ignore extra information is too strong a constraint for a spec Proposed clarification Lines 601-604: change sentence “ If a message contains additional elements not described in this specification, the Reliable Messaging Processor MUST ignore those elements. “ to “ If a message contains additional elements not described in this specification, the Reliable Messaging Processor MAY ignore those elements. “ Comment 19: definition of Payload Proposed clarification Lines 173-174: change “ Payload: Subset of message data that is intended for the consumer of the Reliable Message. “ to “ Payload: Message data that is transferred from or to an RMP through the use of an abstract RMP operation. “ -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]