[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: comments on ws-r 1.05
Tom, Comments on http://www.oasis-open.org/committees/download.php/7598/WS-Reliability-2004-07-07.pdf in diminishing order of importance. Cheers, 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 interoperability. 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 protocol? 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 elements." 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 adjective. 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 check." 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 specified. 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]