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: comments on ws-r 1.05


Comments on 
in diminishing order of importance. 


Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://webpages.charter.net/chrisfer/blog.html
phone: +1 508 377 9295
cell: 508 667 0402

1) line 170 defines the term "Deliver" as 
        "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.". 
The operation is not in fact invoked *on* a receiving RMP but rather *by* 
it. Also, it is not an operation supported by the RMP but rather an 
(abstract) operation that is expected to be implemented by the "consumer" 
which the RMP calls.

2) line 194/8defines the term "Notify" as 
        "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).". 
As with the term "deliver" above, the abstract operation in question is 
not "supported by" the RMP but in fact implemented by the "producer" and 
called by the RMP. Also, as with Submit, is far too suggestive of an 
implementation strategy. Basically, all that Notify should be concerned 
with is notifying the producer that the message was delivered (although I 
for one have real heartburn about this particular point, I am only calling 
out the fact that as currently defined, it drifts too far into 
implementation strategy and unnecessarily so).

3) lines 151/5 and 250/1 should have a normative reference to the OASIS 
SOAP Message Security 1.0 spec not "WS-Security"

4) line 489/90 reads: 
        "It is RECOMMENDED to NOTresend a message for which an RM-Reply 
with one of the following Fault types has been received:". 
Why is this only a RECOMMENDATION? Furthermore, in the case where ordered 
delivery is expected, then it would seem that the whole sequence/group 
should be terminated.

5) line 166 defines "RMP" in terms of a SOAP node (as defined by SOAP1.2) 
and yet it is intended that the protocol be capable of being used with 
SOAP1.1 which does not have the term defined. It seems odd to define such 
an important term using the formal definition defined for only one of the 
two protocols for which the WS-R protocol is intended to be usable. Is 
this suggesting that a conformant RMP must be capable of processing 
SOAP1.2 messages? It makes for a cleaner specification if one defines 
behaviour in terms of destination and source because it is entirely 
feasible that a component might implement only one of those roles. As 
defined, WS-R requires that a conformant implementation of an RMP 
implement both roles which would limit its applicability to certain use 
cases such as small footprint devices or in cases where reliability was 
only needed in one direction. Also, what is with the "a subset, or 
superset thereof". What does that mean exactly?

6) line 171/2 defines the term "reliable message". This seems unnecesary. 
I realize that there is a need to be able to talk about the message being 
delivered with some reliability qos but IMO it should be more precisely 
identified as a SOAP message carrying a <wsr:Request> header block.

7) line 204/6 defines the term "Message Delivery" as 
        "The action of invoking the “deliver” operation for a Reliable 
Message. This action marks the end of
        the RMP processing for this message." 
Here is a case where the impreciseness of the definition might actually 
result in an improper implementation that could claim conformance. To be 
precise, the termination of "RMP processing" for the message must include 
housekeeping of any state associated with the message so as to mark it as 
having been delivered. Furthermore, the action of "invoke" does not 
necessarily imply that the message will or has been successfully 
"delivered". A fault that occurred as part of the execution of 
"invocation" of the abstract deliver operation could leave the system in a 
state in which the RMP considers the message to have been delivered to the 
"consumer" when it has in fact never seen the message. Basically, in order 
to maintain a completely reliable system, the abstract deliver operation 
needs to be *completed* in the context of a transaction. Once again, this 
is a case of the WS-R specification drifting too close towards 
implementation guidance that is not really relevant to the *protocol*. 
Certainly, an implementation would have a carefully crafted and vetted 
technical specification to ensure correctness of operation. It needs no 
guidance from this specification as it should concern itself exclusively 
with the protocol as manifested on the wire so as to ensure 

8) line 217 defines the term "PollRequest Message" as
        "A polling message for Acknowledgment Indication(s). A Sending RMP 
may send a PollRequest
        Message for polling of Acknowledgment Indication(s) regardless of 
RM-Reply Pattern of the original Reliable Message. For example, the 
Sending                 RMP may send PollRequest Message to retrieve 
Acknowledgment Indication for a message originally sent using Callback 
RM-Reply Pattern." 
Again, just define the term and leave out the embellishments. It is a 
message sent by the sending RMP to the receiving RMP that requests that it 
respond with acknowledgement information. The additional text will only 
get you into trouble (see below).

9) line 256/7 reads:
        "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."
In fact, the RMP does not *implement* "Notify", it calls "Notify" on the 
Producer. Nor does it *implement* "Deliver", a receiving RMP calls 
"Deliver" on the consumer. Again, this spec drifts too far into the 
implementation strategies for its own good, and unnecessarily so to boot.

10) line 265/8 reads:
        "An RMP which supports both Submit and Notify MUST be able to 
associate a failure notification
        (Notify) with the related submitted payload(Submit). In case the 
notification of payload is
        supported, the RMP MUST be able to associate a received 
payload(Notify) with a previously
        submitted payload(Submit)."
Again, this is getting perilously close to implementation detail. None of 
this has anything to do with reliable messaging. This is what a SOAP node 
does in support of various MEPs. Is this a specification for reliable 
messaging protocol or a specification for an implementation of the 

11) lines 763/4 reads: 
        "If present, the format of ReplyTo element MUST be specified by 
the reference-schema attribute. If
        the attribute is omitted, the default format of ReplyTo element is 
URI as defined in [RFC 2396]."
 It would seem to me that since the table states that there are no child 
elements of ReplyTo, that it must be a schema simpleType. I would suspect 
that this is an effort at punting on the format of an EPR such that the 
specification could be composed with whichever addressing specification 
wins the day. However, the specification states clearly that the RMP MUST 
ignore elements not defined in this specification. Hence, it seems clear 
to me that the specification is internally inconsistent in this regard. 
That is, of course, if on line 484 is intended to refer to SOAP header 
blocks and not elements. As presently specified, the protocol schema is 
not extensible and there is a specific prohibition that an RMP process any 
elements not defined here. However, if the content of the ReplyTo is 
intended to permit use of a WS-Addressing EPR or a WS-MD corollary, then 
clearly the specification needs to be fixed in this regard so as to allow 
for extensibility.

12) lines 430/1 contradict the requirement expressed beginning on line 421 
because it suggests that terms that are defined under group scope as their 
"smallest scope" can be used for messaging scope. These lines should 
probably be removed.

13) line 484/5 says: 
        "A Sending RMP that has not been able to receive an acknowledgment 
for a sent message, MUST
        notify the Payload Producer of a delivery error." 
What does "not been able to receive" mean? Shouldn't this state: "A 
Sending RMP that has not received an acknowledgment for a sent message 
MUST notify the Payload Producer of a delivery error."? As written, if an 
RMP goes off-line, then when it resumes operation, it MUST notify the 
Producer (Application Source) of a failure to deliver which is obviously 
not what was meant.

14) line 507/8 - again, defined in terms of payload which suggests that 
the RMP must have some ability to evaluate equivalence of "payload".

15) lines 509/11 - rather than characterize a re-transmission of the same 
message as being "the same message" the WS-R spec characterizes this as a 
new message instance. This only makes things confusing. A message, not a 
payload is what the sending RMP deals with, and it is that message that is 
assigned its unique identifier (the GroupId/Sequence) upon receipt by the 
sending RMP that is transmitted and/or re-transmitted as need be. As 
specified, it appears as if the RMP is responsible for packaging, etc and 
clearly, this is NOT a function of a SOAP node.

16) line 600/2 reads: 
        "In a case where the text of the specification is shown to be in 
conflict with schema statements, the
        schema statement prevails. If a message contains additional 
elements not described in this
        specification, the Reliable Messaging Processor MUST ignore those 
By stipulating that an RMP MUST ignore elements not defined in the 
specification, it eliminates the ability for an implementation to add 
"secret sauce" that might be used to optimize the protocol or the 
implementation's performance, etc. IMO, this is unwise. The MUST should be 
changed to a SHOULD or more preferably a MAY. There is absolutely no 
reason that MUST be specified here. Is an RMP to ignore policy assertions? 
What if they become the means by which we exchange the QoS parameters, 
etc.? MUST they be ignored? That would be silly. See my comment on the 
ReplyTo element as an example of how silly this constraint is.

17) line 669/71 reads: 
        "If the MessageOrder element appears in the message received, the 
Receiving RMP MUST NOT
        deliver the message until all messages with the same groupId value 
and a lower number value
        have been delivered." 
and yet the element being defined here is MessageId which really has 
nothing to do with MessageOrder
semantics. These lines should be relocated to the section that defines the 
MessageOrder element unless 
they are redundant in which case they should be removed.

18) line 161 defines the term "reliable messaging" as
        "The act of processing the set of transport-agnostic SOAP Features 
defined by WS-Reliability,
        resulting in a protocol which guarantees certain qualities of 
service. This includes the processing of
        Acknowledgment indications, re-sending of messages, duplicate 
message elimination, and
        message ordering." 
It is unclear to me that the definition is necessary nor that it even 
applies. If anything, it should be defined in generic terms not in terms 
of the specification itself or its protocol artifacts. Users consider 
"reliable messaging" to be a non-functional quality or characteristic.
Suggest that the term and its definition be removed or reworded in more 
generic terms.

19) line 173 defines the term "payload". Why define this term if the 
protocol is defined in terms of SOAP and SOAP has no such term defined? 
Suggest that the term and its definition be removed and that its use 
throughout the specification be omitted as well. A SOAP node operates on a 
SOAP message (infoset), not a payload. The fact that the message may be 
augmented with SOAP header blocks in a sending SOAP node is irrelevant. 
Furthermore, the SOAP1.2 spec defines a term for SOAP application as:
        "An entity, typically software, that produces, consumes or 
otherwise acts upon SOAP messages in a manner conforming to the SOAP 
        processing model (see 2. SOAP Processing Model)."
Note that there is no mention of "payload" only of SOAP messages. While it 
may be the case that there can be application components that interact 
with the SOAP application to process the "payload", that is completely 
outside the scope of SOAP and if the RMP is intended to be a SOAP node, 
then I fail to see how it can make claims about how such a SOAP 
application interacts with these other components.

20) line 229/38 defines the term "publish". The embellishments starting at 
line 232 are completely redundant with other aspects of the spec. Say 
something once and only once or you will get into trouble.

21) line 402 "messaging scope" s/b simply "scope"

22) line 496/500 - why is this constraint defined in terms of a "payload"? 
This is too imprecise. These lines should be removed.

23) line 771 - exactly what value does AckRequested add? Are there any QoS 
modes that do not involve an acknowledgment?

24) line 187/90 defines the term "Submit" as 
        "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).". 
As with line 163, this definition is far too suggestive of an 
implementation strategy. It makes an assumption that the RMP is also 
packaging the "payload" in a SOAP message. What is really happening here 
is that the application (in ws-r terms the producer) is transferring 
responsibility to transmit the message reliably to the RMP. Making 
distinctions between payload and non-payload is irrelevant. In SOAP terms, 
there is only the SOAP message. The message can be processed as it is 
being transmitted and as it is being received in ways that effect the 
content of the message.

25) line 202/3 defines the term "duplicate message" as 
        "A message is a duplicate of another message if it has same 
message identifier.". 
In fact, a message is not a duplicate unless it is perceived in the 
context of the RMP that receives a message that has a message identifier 
that is identical to that contained in a previously received message. I 
suppose that one could use the term to describe a message to be 
re-transmitted, but IMO, a re-transmission of a message should be a 
re-transmission of the SAME message, not a duplicate (at least not in 
these terms because it isn't clear whether any other aspects of the 
message might be altered between re-transmission instances).

26) line 211/4 defines the term "Reliable Messaging Fault Indication (RM 
Fault)" as 
        "An indication which refers to a previous message that encountered 
a Reliable Messaging fault condition at the Receiving RMP. It signals to 
the             Sending RMP of the referred message that there was a 
failure to invoke the deliver operation for the message.". 
Again, I will reiterate my concern that this specification define its own 
fault mechanism orthogonal to the SOAP Fault mechanism. IMO, there are 
only two possible conditions: a recoverable condition and an unrecoverable 
condition. The specifics of the fault are unimportant. Either the message 
could not be processed and the receiving RMP can recover should the 
message be re-transmitted, or else the receiving RMP should simply 
terminate the session/sequence, possibly giving some indication as to why 
it is doing so. The entire RM Fault mechanism serves only to unnecessarily 
complicate the protocol. Sure, it might be useful for distributed 
debugging purposes to have information as to the nature of process 
failures, but this is a completely orthogonal issue to that of reliable 
messaging protocol. It would be more appropriate to leverage the likes of 
WSDM to monitor failures and take compensatory actions, etc than for every 
protocol to define its own unique fault strategy. A fault is a fault. 
Leverage the SOAP Fault mechanism as it was intended. As for RM, the 
concern should be exclusively as to whether the message has been received 
(or delivered in the case of WS-R) or not, not why. The sending RMP is 
simply going to retransmit messages that are not acknowledged. What would 
the RMP do in the case of some weird fault? Is it supposed to do anything 
else but punt? If indeed the message cannot be received/delivered, then 
there should be a SOAP fault generated.

27) line 215/8 defines the term "Reliable Messaging Reply (RM-Reply)" as 
        "An indication referring to a previous Reliable Message, that is 
either an Acknowledgment Indication
        or a Reliable Messaging Fault Indication. For the Callback and 
Poll RM-Reply Patterns, RM-Replies
        for multiple Reliable Messages MAY be included in a single 
Reliable Messaging response." 
Remove the last sentence as it is duplicate of the formal constraints 
defined elsewhere. A specification should say something once and only once 
to avoid the possibility that through revisions it becomes 
self-contradictory. By the way, what is an "indication"? This term is 
underfined although used extensively.

28) lines 408 uses the term "smallest scope". This is confusing. I think 
that instead that these things should be assigned a default scope with a 
statement that indictates that terms applying to the message scope MAY be 
applied at the group scope. "smallest" is simply an inappropriate 

29) line 541/2 - it would appear that the constraint that the sequence 
number be monotonically increasing from 0 by 1 applies only to the case 
where ordered delivery is required? Again, this is a case of saying things 
more than once when once will suffice. Remove this and defer to the 
section that defines the @sequence.

30) line 666/8  reads: 
        "In a request message, the sender MAY include either a 
@groupExpiryTime or a
        @groupMaxIdleDuration corresponding to the group termination 
parameters specified in Section 5.1.2:" 
Is the either exclusive or inclusive? This is left to the imagination of 
the reader. (I note below that it is meant to be exclusive)

31) line 692 clears up the confusion above as to whether "either" was 
exclusive or inclusive... it is exclusive. However, it seems to me that 
there is no reason why these two should be considered mutually exclusive 
of one another. This seems rather arbitrary.

32) lines 731/3 reads: 
        "Note: Given the above definition of ExpiryTime, when a received 
message requiring Duplicate
        Elimination is processed, it is sufficient to only check for its 
duplicates among MessageIds of past
        messages that have not expired yet at the time of the duplicate 
Whoa! This would mean that a message could indeed be processed more than 
once if the sending RMP were to have incorrectly changed the expiryTime. 
It is unwise to make an assumption of correct processing of an 
implementation when defining a constraint or in adding suggestive prose 
such as this (and I would definitely characterize this as implementation 
guidance and not a normative statement of the specification in the first 
place!). This note should be striken as it is simply a bad idea. In 
general though it should be made clear, possibly in Notational Conventions 
that Notes are NON-NORMATIVE. It would be even better if they were styled 
specially so as to be easily distinguishable from normative prose.

33) line 838/9 reads: 
        "If a Receiving RMP does not support the use of PollRequest as a 
general status query
        mechanism, it MAY return a NonSupportedFeature fault." 
and yet this element is required to carry a SOAP mustUnderstand attribute. 
If the feature is not supported, why is this not treated as not 
understanding? Why is it that this specification must invent its own 
mechanisms when there are perfectly reasonable mechanisms already in 
place? Further, if the receiving RMP does not support the feature, why is 
sending the unsupported fault an option? How is the sending RMP supposed 
to know that it is barking up the wrong tree? This is totally broken as 

34) line 175/7 defines the term "producer" as 
        "Producer (or Payload Producer)
        An abstract component which produces the payload of a message to 
be sent out. An example of
        Producer is an application component able to invoke an RMP for 
sending the payload." 
This term's definition is too suggestive of an implementation and makes 
use of the term "payload" which is foriegn to SOAP. If anything, the term 
here should be "sending SOAP application" I suppose as this is the entity 
that produces the SOAP message (even though it might still be augmented 
with header blocks etc before it is physically transmitted to the next 
SOAP node in the SOAP path).

35 ) line 178/81 defines the term "consumer" see above.

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