OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

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