[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] feedback from implementors
Comments inlined:
---------------------------------------------------------------------------------
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).
<SK-1>
I agree that clarification
is needed, but some editorial comments on the propsed
text.
</SK-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.)
<SK-1>
instead, hou about just simply
saying:
"...MUST send back RM-replies
for non-expired messages that were either delivered or faulted in that
message range"
Because, the phrase "as concerning"
is ambiguous as the current state.
</SK-1>
- L886: replace:
"...MUST return RM-reply for messages received..."
with :
"... MUST interpret such poll requests as concerning the set of messages..."
<SK-1>
and this one with:
" ... MUST retuen RM-rplies for non-expired delivered or fault messages for messages received ..."
</SK-1>
- 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)
<SK-1>
We already agreed upon this.
Infact in section 4.1 (line no. 845), we clearly state this.
I'm not sure what additionally
needs to be said in section 4.4.
</SK-1>
---------------------------------------------------------------------------------
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.
<SK-1>
I prefer the above proposal with a minor change.
I don't even want to say that it is an
initial value, rather describe them conceptually,
and leave it to the implementation for
interpretation.
</SK-1>
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.
<SK-1>
I don't think we have to say
anything here for 2 reasons:
i) We have decided that we are
going to support RM for end-to-end entities only {REL-8]. So we don't
have deal with
intermediaries in our case
ii) Leave it to the SOAP processing
logic (based on soap actor/role/relay stuff) to decide on when to
remove the
header and when not to remove it.
Also, distinguishing the 'alone'
and 'piggyback' is doable even now, i.e., if there is no (RM)Request
Header, then it is standalone
and if there is (RM)Request and (RM)Response then it is a
RM-piggybacking. So I don't
see a need for the additional attribute.
</SK-1>
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.
==============================================================================
-Sunil
Jacques Durand wrote:
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>>
To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]