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