[graap-wg] proposal: agreement lifecycle end-games
Karl Czajkowski
karlcz at univa.com
Tue Mar 22 01:53:34 CST 2005
I think the best solution to this termination/expiration mess is to
separate completely the notions of "lifetime of obligations" and
"lifetime of Agreement interface".
A. The lifetime of obligations should be captured solely in term-level
meta-data and/or domain-specific lifecycle models. Individual
service or guaranatee terms MAY have expiration times on them that
are set statically or renegotiated by a mechanism outside the scope
of our first specification. Additionally, some obligations MAY
last indefinitely or until some domain-specific events occur.
B. The lifetime of the service interface SHOULD be greater than the
effective lifetime of any obligations, but I guess I can accept
that this may not be possible with limited Agreement implementation
QoS. It is hard to be normative about such failure modes.
C. I suggest that we drop (for now) any notion of terminating the
obligations using WS-Agreement mechanisms. If we can find a clear
proposal for handling such ammendment of obligations before the
spec is done, I am not personally against reincorporating it in
some form.
D. I suggest that we defer to WS-ResourceLifetime for handling the
termination of the Agreement resource itself, with the
specification advocating the above "SHOULD" about Agreements
outlasting their embedded obligations (B).
E. We should introduce an agreement-wide state, complementing the
proposed Pending/Rejected/Observed states, to represent the
Complete or PostObserved condition where all terms have passed "out
of scope" and into history. What is the best state name for this?
F. Should we introduce any kind of "linger" time to indicate an
interaction with WS-ResourceLifetime to commence an automatic
countdown to Agreement destruction once it has reached the Complete
or PostObserved state?
karl
--
Karl Czajkowski
karlcz at univa.com
More information about the graap-wg
mailing list