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: feedback from implementors


Title: feedback from implementors

Here are 4 comments on V0.992 after a detailed review ,
mostly from Hamid who is currently implementing.

Sunil, can you review in particular #1 and #4 ?

All, except  #4 maybe, could have a purely editorial treatment.

Jacques & Hamid

<<Current-Issues-V0992.txt>>


---------------------------------------------------------------------------------
1. RM-Replies, and Messages neither Acked or Faulted :

Issue: For those messages that have neither been delivered (Acked) or been Faulted
at the time a PollRequest is received, the doc is not clear on what should be done in the 
response element. The text seems contradictory: implies that a response element 
will simply not say anything about such messages (Section 4.4.2.1, and also Example 3 ),
but also that all messages MUST be replied (4.3.1). 

Proposal: In case of message non-delivered yet, and non-faulted, 
it should be clearly stated taht the Response does not have to say anything. 
(unless we create a third state for these? That would help distinguish if a 
response is mute about a message because it is expired (see #2 below), or because
it is held in out-of-order sequence)
Editorial updates:
- in 4.3.1 (L883) replace:
"...MUST send back all RM-replies for the messages received in the MessageId" 
with:
"...MUST interpret such poll requests as concerning the entire set of messages received 
so far for this group." (which means returning RM-Replies for those messages
either delivered or faulted.)
- L886: replace:
"...MUST return RM-reply for messages received..." 
with : 
"... MUST interpret such poll requests as concerning the set of messages..." 
- L845 (section 4.3)
replace:
"...to determine non-expired messages which have been delivered."
with:
"...to determine the status of non-expired messages."

---------------------------------------------------------------------------------
2. Time limit for messages referred in the Response element,
in particular for poll requests with broad range:

Issue: It will not be technically possible to provide status for any
past message, especially if they have expired.

Proposal: A Receiver should only be required to send Acks (and Faults) for messages that
have not expired yet. So a Response is exempt from reporting on expired messages.
Make that clear in the spec. (Section 4.4)

---------------------------------------------------------------------------------
3. parameters for "Resending" :

Issue: The RetryTimeInterval RM agreement item, as described in 3.1 (Line512)
is specifying the interval between two retries. A fixed interval may not be appropriate, and
a more dynamic one may be better, and may be dynamically adjusted based on context of operations.
Plus, this resending technique does not really make sense when using PollRequest:
we would expect the Sender to only resend *after* doing the PollRequest (which may be done
for several messages). The spec is mute on what should be the resending policy in that case.

Proposal 1: 
(lite) Modify text so that RetryTimeInterval is only an initial value, 
that the implementation is free to interpret the way it wants. (e.g. for exponential variation). 
Also mention how these parameters should be interpreted in case of PollRequest: 
- the RetryTimeInterval should be the elapsed  time before doing the (first) polling (followed by
message resending for messages not Acked.)
- the RetryMaxTimes parameter should be for how many times the PollRequest will be tried
for a message that was not Acked.
NOTE: a Receiver should be free to ignore PollRequest messages that are sent too frequently for
a [group of] particular messages.

Proposal 2: 
(radical) Get rid of RetrymaxTimes and RetryTimeInterval alltogether.
After all, the way a Sender is resending (frequency, # of times) does not affect interoperability.
It is not something that Sender and Receiver have to settle on.
GuaranteedDelivery is before all about notifying the Sender in case of delivery failure, 
and requesting Acks. 
The resending effort is implementation dependent and may vary dynamically with context. 
These 2 parameters cannot even be always complied with 
(memory issues may prevent to store for too long and resend). 
The only requirement we can have, is that no attempt to resend should be made 
beyond ExpiryTime (for obvious reasons). Using text like:
"The Sender RMP MUST do its best effort to resend a non-acknowledged message until
the mesage expires or is acknowledged. The resending policy and algorithm 
(frequency, dependency on storage and load constraints) is left to the implementation."

---------------------------------------------------------------------------------
4. Discard or Forward message after consuming the Response header :

Issue: Depending on whether a Response message is (a) alone or (b) piggybacked on a business message,
the processing of the RMP will be different. Let us say the RMP is implemented as a SOAP node:
We must do:
- in (a) discard the message after consuming the Response header block,
- in (b) forward the message after consuming the Response header block, as it is intended to another node.
However, as a SOAP node is not expected / allowed to access the SOAP body to figure whether
this is a stand-alone Response or not, it should only rely on the Header.
But nothing in the header will tell the RMP which case (a) or (b) we are in. As a business message
is not required to have SOAP headers, the SOAP header may look exactly the same for (a) and (b).
Note: In some case where the RMP is implemented as a "handler" (Apache / Java), there is a work-around.
But that is only for very specific cases.

Proposal: Add an attribute to the Response element, like @mode="alone" or "bundled".
The sender RMP always knows how to set this attribute. The Receiever RMP node will forward 
after processing only if @mode= "bundled". More details below about the problem:

There two cases to consider about the addressing of an RMP:
Case 1:
------
The address on which the RMP is listening and the address of the web service are the same.

Case 2: 
-------
The RMP can receive messages on its own address that is different from the address
of the web service, and yet  it can process messages on both addresses.

The only case in which the RMP can distinguish between (a) and (b) above, is the case 2 where
the message is received on the RMP's own address (given in the replyTo element for a response/callback
reply pattern). Note that when receiving poll requests (that could be also be piggybacked), the RMP 
is still unable to distinguish between (a) and (b) above.



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