Chris
-1 for me too, I buggered it up
Good points all, perhaps I should explain
what led me down this path.
As I was checking the state tables to the
text as is my usual Monday morning after breakfast warm-up, I looked at the RMD Sequence
State table and noticed
that it is a very simple machine. It sits there in an idle state waiting
for a CreateSequence that it can process and then if it accepts the sequence it
enters the Connected State (true, the state is a fabrication , but stay with
me) I found no text that seem to fill the box of a CreateSequence being
received for a sequence already in progress. I filled the box with a
protocol error indication (Unknown Sequence fault) since I found no specific
guidance in the spec.
It seems that I had my CS/CSR backwards in
my head. Must have been a brain fault since I know that CS is not
sequence targeted.
So the receipt by the RMD of a duplicate
CS will cause an orphaned sequence which I agree is ig big deal
My error was in the filling of the CS
while in connected and closed states which is in error and should really be N/A.
Revisions to the State Tables are
accumulating
-bob
From: Christopher B
Ferris [mailto:chrisfer@us.ibm.com]
Sent: Monday, June 26, 2006 5:08
PM
To: Bob Freund-Hitachi
Cc: [WS-RX]
Subject: Re: [ws-rx] NEW ISSUE
Editorial Create Sequence assumes both request and response are received.
Bob,
A
couple of things. First, I don't think that the specification has to say what
to do in the event that
either
the CreateSequence or CreateSequenceResponse are unsuccessfully transmitted. I
don't think
it
is necessary to include language that says that the RMS MUST do this or that in
such an eventuality.
How
the RMS deals with this situation is completely its concern. IMO.
As
for the RMD receiving a "duplicate" CreateSequence, it isn't at all
clear to me that it should
be
checking for duplicate CS messages. An RMD that responds to a CS with a CSR
(creating a
Sequence
in the process) that for some reason is never received by the RMS will simply
have
an
orphaned Sequence that can be harvested after some period of inactivity. The
receipt
of
a subsequent CS from the RMS can be dealt with as if there had been no previous
Sequence
created
without ill effect.
It
is unnecessary to state that the RMS shall not send any messages in the
Sequence until it
receives
the CSR because without the CSR, it has no knowledge of the Sequence
Identifier.
hence,
there is no need to make any statement about this in the spec.
Finally,
A RMD cannot, by definition, receive a CS for a Sequence that already exists
because
there is no Sequence Identifier in the CS message.
So,
in general, -1 to the proposed new issue.
Cheers,
Christopher
Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295
"Bob Freund-Hitachi"
<bob.freund@hitachisoftware.com>
wrote on 06/26/2006 01:55:18 PM:
> In WD 15 Section3.1 “Sequence
Creation” it is stated starting at line 253
>
>
“The RM Source MUST request creation of an outbound Sequence by
> sending a CreateSequence
> element
in the body of a message to the RM Destination which in turn
> responds either with a message
>
containing CreateSequenceResponse or a CreateSequenceRefused fault.”
>
> This
does not account for the possibility that any of the
> CreateSequence, CreateSequenceResponse, or
CreateSequenceRefused
> fault may have been lost in transit.
>
>
Proposal:
>
> New
text:
>
>
“The RM Source MUST request creation of an outbound Sequence by
> sending a CreateSequence
> element
in the body of a message to the RM Destination which in turn
> responds either with a message
>
containing CreateSequenceResponse or a CreateSequenceRefused fault.
> In the event that the RM Source fails to
receive either a
> CreateSequenceResponse or a CreateSequence
fault in a timely manner
> then it MUST do either a) re-send the
CreateSequence, or b) abandon
> the CreateSequence attempt and terminate the
Sequence. If the RM
> Destination received a CreateSequence that it
has already processed
> such that the indicated Sequence exists, then
it shall respond with
> a CreateSequenceResponse providing that there
have been no messages
> in that sequence received and the state of
that Sequence shall
> remain unchanged. The RM Source SHALL
NOT under any circumstances
> send any message to the RM Destination for a
particular sequence
> until that Sequence has been successfully
created as evidenced by
> the successful the receipt of a
CreateSequenceResponse. In the
> event that the RM Destination receives a
CreateSequence for a
> Sequence that already exists and for which
the RM Destination has
> already accepted messages, then the RM
Destination shall respond
> with a Sequence Terminated fault as described
in Section 4.2 and
> SHALL immediately terminate the
Sequence”
>
>
> State
table impacts:
>
> Add a
two new row to the RM Destination state table as follows
>
CreateSequence (duplicate & empty)[msg]{3.1) | N/A | Send Create
> Sequence Response[Same] | Send Unknown
Sequence Fault[Same]{4.3}
>
CreateSequence (duplicate & not empty)[msg]{3.1) | N/A | Send
> Sequence Terminated fault[None]] | Send
Unknown Sequence Fault[Same]{4.3}
>
>
>