[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: i145 - Current proposal?
"Bob Freund-Hitachi"
<bob.freund@hitachisoftware.com>
07/20/2006 04:12 PM |
|
"Marc Goodner"
<mgoodner@microsoft.com>
07/20/2006 03:45 PM |
|
"Marc Goodner" <mgoodner@microsoft.com>
07/20/2006 02:14 PM |
|
Guys, following up from my post earlier today on current proposals I realize
the proposal 1 for i145 is not current. Reading the below thread
to see where this issue is the discussion seems to have stopped here. Is
there any agreement on this issue? Is there a proposal available we could
consider on today’s call?
From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Thursday, July 06, 2006 6:26 AM
To: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] i145 - design: Implications of Sequence Expiration
not specified
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 |
|
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
"Bob Freund-Hitachi"
<bob.freund@hitachisoftware.com>
07/05/2006 11:57 AM |
|
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]