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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[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]