[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