[graap-wg] lifecycle concerns

[Karl Czajkowski]

I wish to raise the discussion again regarding what I find as
confusing facets of lifecycle in the WS-Agreement draft spec.

In my earlier note about asynchronous/asymmetric operation patterns, I
suggested that one way to address the message correlation problem is
to return to something like our earlier Agreement state-machine: We
could return an Agreement resource EPR immediately and have the
Agreement start in a "not committed" state, which I will call
"DecisionPending" to avoid confusion with the removed negotiation
facilities.  The initiator (client) can then monitor/poll the
Agreement resource to determine whether the responder (service)
accepts the offer or not.  I think this would be a good change to
allow an application-level asynchronous creation or other future
negotiation patterns to compose with the basic Agreement presentation.

I see the lifecycle then being basically:

      1. DecisionPending

      2. Observed  (passively or actively) [violated or satisfied]

      3. Complete  (no longer observed)    [violated or satisfied]

These three phases are demarked by the state of the obligations
between the two parties: there are no obligations yet in (1); in (2)
the obligations are present but whether they affect service delivery
has to do with the precise scoping of the terms; and in (3) the
obligations are still present in a historical sense, but they are
permanently out of scope and no longer affect service
delivery.

During observation (2), we can also consider whether the obligations
are presently being satisfied or violated.  This relates to the
monitoring/enforcement discussion as to whether we wish to capture
this in any way.

During both (2) and (3), we can consider historically whether the
obligations were satisfed or violated and by "how much".  This relates
more to audit and accounting.

This notion of satisfied/violated is represented in the Guarantee
States diagram as not-determined, fullfilled, and violated.  As I read
it, this section refers to the present conditions of phase (2) only,
without any memory of past delivery.

The basic state phases described above sound similar to the Service
Runtime States diagram, but this part of the spec is scoped to
individual services rather than the agreement as a whole.  I think the
states here are are embedded in the Observed (2) phase, except when
all service terms are in the "Completed" state then the agreement as a
whole is Completed as well.

I have minor quibbles with the states "Ready," "Not Ready," and
"Processing" which I think are straying towards domain-specific
extensions.  I think a generic state would be more like "Out of Scope"
and "In Scope", e.g. is the service present according to the scoping
conditions of the agreement terms.  Orthogonally, we can consider
readiness as whether the service terms are fullfilled or violated
according to this scoping.

Thoughts?  Rotten fruit?


karl

-- 
Karl Czajkowski
karlcz at univa.com