ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [ws-rx] i145 - design: Implications of Sequence Expiration notspecified
- From: Doug Davis <dug@us.ibm.com>
- To: ws-rx@lists.oasis-open.org
- Date: Thu, 6 Jul 2006 09:25:37 -0400
The timer started when the sequence
is created - or in state table terms, when we move from "none"
state to "created" state. Why would we need any finer granulatity
than that?
Its interesting that you think the lifetime
of the Sequence should be longer on the RMS than the RMD. I would
think it would be the other way around. It seems like it would worse
for the RMS to think that a sequence lived longer than it really did. Stopping
early (for the RMS) wouldn't cause too much pain (at least its in control
over why it stopped using the sequence) but sending a message and finding
out that the sequence it wanted to use is no longer there seems a bit scarier.
Did it go away because it expired or because of some internal error
that now required some kind of admin help? It (the RMS) just doesn't
know and it would worry me if it made some kind of assumption. It
would be much safer to have the RMS expire before the RMD and let the RMS
have control over when to stop using a sequence.
re:MakeConnection - I'm no so sure it
belongs in the state table at all. Its more of a transport level
thing and doesn't really have 'state' per say. Either there are messages
waiting to be delivered or not - just 2 possible states. Not very
exciting :-)
thanks,
-Doug
"Bob Freund-Hitachi"
<bob.freund@hitachisoftware.com>
07/05/2006 12:57 PM
|
To
| Doug Davis/Raleigh/IBM@IBMUS, <ws-rx@lists.oasis-open.org>
|
cc
|
|
Subject
| RE: [ws-rx] i145 - design: Implications
of Sequence Expiration not specified |
|
Doug,
The state table relies on definitions
of events to advance from state to state.
It looks pretty bad to say
in the RMD state table that the sequence comes to life at some implementation
defined time and that it stays in the none state until that time occurs.
The state transitions are all very black and white
I know of a community of potential
users who are more than a bit concerned about the security of the protocol.
I believe that their opinion would be to define expires to be fairly
tight compared with the expected time for sequence transmission. Others
might feel fine leaving it at PT0S
One aspect of the text I proposed
that I like is defining expiry that way ensures that the Sequence will
expire at the RMS at the same time or later than at the RMD (no fair discussing
clock granularity at this juncture). This provides at least known
behavior and supports silent termination. The RMS can be reasonably
assured that it need not be concerned about what is going on at the RMD.
As for MakeConnection, I have
been thinking a bit about its representation.
I am drifting in the direction
of defining an underlying “transfer engine” that would deal with it independently
of the sequence state tables. I think that this also might take care
of re-transmissions as well as the handling of responses which are hard
to find in the spec J.
Thanks
-bob
From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Wednesday, July 05, 2006 12:29 PM
To: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] i145 - design: Implications of Sequence Expiration
not specified
I had forgotten that I did have a version that fixed the start of the duration,
how about:
This element, if present, of type xs:duration specifies the duration
of time until the Sequence SHOULD be terminated, relative to its creation
time.
The termination should probably be silent since we don't have a message
for it. Its not a fault, per say, so I'm not sure SeqTerminated Fault
makes sense.
My concern with the text you've proposed is that it mandates that the sequences
are created at a certain time and I'm not sure we can mandate that. For
example, you say the sequence starts (on the RMD) when the CSR is transmitted.
Is that before or after the MakeConnection is received? I would
prefer before, but the 'transmit' in there may imply something else to
others. I think leaving it as a generic "creation time"
is best - leaves it up to the impl to decide when that time is.
Likewise, as you asked, whether the Offered sequence is 'created' during
the generation of CS or during the processing of the CSR is an RMS detail
that we should not get into.
Overall, I'm not that concerned about the timing of this, and am ok with
leaving it a bit loose, because I don't think this timing is that critical.
If this timing were critical and every millisecond counted then I
would agree with you that we would need to be very precise and need more
work in this area, but I just don't think the expiry/lifetime of a sequence
is mission critical - it just needs to remain available 'as long as' the
requested Expires time - note it doesn't have to commit suicide at that
time at all, it just can't do it before that time.
thanks
-Doug
"Bob Freund-Hitachi"
<bob.freund@hitachisoftware.com>
07/05/2006 11:57 AM
|
To
| Doug Davis/Raleigh/IBM@IBMUS,
<ws-rx@lists.oasis-open.org>
|
cc
|
|
Subject
| RE: [ws-rx] i145 - design: Implications
of Sequence Expiration not specified |
|
Doug,
Is that termination silent?
I think that you are correct, a new section is not really necessary.
Do we care what signals the start of that xs:duration?
I think that this may be tied to definition of the sequence lifetime which
may be better defined in Section 3.4 “Sequences”
My suggestion would be to insert in the first paragraph of 3.4, perhaps
at the end, something along the lines of:
“A Sequence exists at the RM Source from the processing of the wsrm:CreateSequenceResponse
until the earlier of the transmission of wsrm:TerminateSequence or the
Sequence expires (see section 3.1). A Sequence exists at the RM Destination
from the transmission of a wsrm:CreateSequenceResponse until the earlier
of the successful processing of a wsrm:TerminateSequence or the Sequence
expires (see Section 3.1).”
Once that is done, then in Section 3.3 “Sequence Termination” expiration
behavior could be stated as something like:
At the end of the first paragraph of 3.3
“Sequence are also implicitly terminated without further exchange of protocol
messages upon the expiration of the Sequence (see Section 3.1)”
Then in Section 3.1 something along the lines of:
Following the paragraph headed by the line: /wsrm:CreateSequenceResponse/wsrm:Expires
the following refining language:
“The Sequence is said to expire when wsrm:CreateSequenceResponse/wsrm:Expires
elapses from either the perspective of the sender or the receiver of this
element”
I am still a bit vague about the usage of the Expires within an Offer.
What does it mean to you?
Thanks
-non
From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Wednesday, July 05, 2006 10:38 AM
To: ws-rx@lists.oasis-open.org
Subject: [ws-rx] i145 - design: Implications of Sequence Expiration
not specified
http://lists.oasis-open.org/archives/ws-rx/200606/msg00216.html
Bob,
I think we can resolve this issue with a much smaller change - instead
of creating an entire new section why not just modify the description of
the Expires element like this:
This element, if present, of type xs:duration specified the duration of
time until the Sequence SHOULD be terminated.
It will need to be modified slightly based on the exact usage but you get
the idea.
thanks
-Doug
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]