[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] New proposed issues 11/17 - 11/30
Of course more came in after I sent this. Inline below. - Regards, Marc g Proposed-01 Title: Semantics of offered Sequences Proposed-02 Title: How does a RM Destination reject an offered Sequence? Proposed-03 Title: Lost TerminateSequence Proposed-04 Title: SequenceClosed fault and SequenceAcknowledgement(Final) ------------------------------- Proposed-01 Title: Semantics of offered Sequences Origin: Matt Lovett http://lists.oasis-open.org/archives/ws-rx/200511/msg00205.html Description: The current specification explains how a RM Source may offer a Sequence to the RM Destination, but does not explain what this really means. It can be read as a protocol optimization, with no deeper semantics. It could alternatively be assumed that the 2 sequences are linked in some way - perhaps application replies are expected to travel back on this sequence (and no other); perhaps the offered Sequence is supposed to close/terminate when the other Sequence closes/terminates. Someone might even assume that offers will only be made for request-reply applications, wheras the absence of an offer implies fire-and-forget messaging. (I am not advocating this interpretation!) We should clarify the specification, so that the reader is fully aware of the semantic import of offering (or accepting the offer of) a Sequence. Justification: The capabilities in the spec should have clear semantics Target: core Type: design Proposal: I think that we should clearly state that there is no deep semantic to offering a Sequence, it is merely a protocol optimization. I think that the right way to explain that is to add a note into the text that introduces offer, saying that the use of offer is semantically identical to not using offer, and then initiating another Sequence between the two endpoints. Describing this is a little tricky, as we don't want to talk about creating a Sequence from RM Destination to RM Source.... and we don't have a term in the spec for the middleware layer that implements RM in either direction. Here is a concrete proposal: Add the following as a continuation of line 256 (using line numbers from wsrm-1.1-spec-wd-06.pdf): Note, offering a Sequence within the <wsrm:CreateSequence> element is simply a protocol optimization. There is no semantic difference between offering a Sequence, and choosing not to offer one and subsequently creating a Sequence to carry messages from the Ultimate Receiver to the Initial Sender. Related issues: None ------------------------------- Proposed-02 Title: How does a RM Destination reject an offered Sequence? Origin: Matt Lovett http://lists.oasis-open.org/archives/ws-rx/200511/msg00206.html Description: Section 3.1 lines 254 - 256 in wsrm-1.1-spec-wd-06.pdf says: <wsrm:CreateSequence> MAY carry an offer to create an inbound sequence which is either accepted or rejected in the <wsrm:CreateSequenceResponse>. However, there is no way to reject the offered sequence without faulting the entire CreateSequence message, as lines 348 - 352 also say: /wsrm:CreateSequenceResponse/wsrm:Accept This element, if present, enables an RM Destination to accept the offer of a corresponding Sequence for the reliable exchange of messages transmitted from RM Destination to RM Source. This element MUST be present if the corresponding <wsrm:CreateSequence> message contained an <wsrm:Offer> element. I believe this is inconsistent. We should either define how a RM Destination can accept an inbound Sequence while rejecting the offer, or adjust the text in lines 254 - 256 to say that it is not possible. Justification: The specification should be consistent. Target: core Type: design Proposal: As noted above, I can see 2 alternatives. I believe the way to go is to say that it is not possible to reject an offered Sequence without rejecting the entire CreateSequence message. Reword lines 254 - 256 to read: <wsrm:CreateSequence> MAY carry an offer to create an inbound sequence which is then accepted in the <wsrm:CreateSequenceResponse>. If the RM Destination is unable to accept the offered Sequence then it MUST respond with a CreateSequenceRefused fault. Related issues: none --------------- Proposed-03 Title: Lost TerminateSequence Description: It is not unreasonable to anticipate that from time to time TerminateSequence sent from the RMS may be lost. Should TerminateSequence be lost, the only way for the RMD to reclaim resources is to wait for sequence expiry or to garbage collect based on implementation policy. Justification: Retrying TerminateSequence is not a reasonable alternative since the RMS cannot determine if CloseSequence was successful, besides the RMS has no evidence of the loss of TerminateSequence. Origin: Bob Freund http://lists.oasis-open.org/archives/ws-rx/200511/msg00244.html Proposal: To improve this situation, we propose to change oneway TerminateSequence to request-response TerminateSequence so that the RMS can on the same connection determine whether TerminateSequence was successful and thus can retry CloseSequence if necessary. ---------------- Proposed-04 Title: SequenceClosed fault and SequenceAcknowledgement(Final) Description: When the RMD autonomously closes a sequence while the RMS is sending messages, messages that the RMD has already received cause SeqAck(Final) but other messages cause SequenceClosed fault or SeqAck(Final). Which is to be returned is unclear. The SequenceClosed fault is not useful for the RMS to determine the maximum message number that the RMD had accepted. Justification: Provides the RMS correct ending status on autonomously closed sequences. Origin: Bob Freund http://lists.oasis-open.org/archives/ws-rx/200511/msg00245.html Proposal: We propose that SeqAck(Final) be piggybacked on the SequenceClosed fault
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]