[graap-wg] proposal: stateful async agreement

[Karl Czajkowski]

I reviewed all of the comments on the GGF tracker, and I do not see
any real surprises relative to the "big issues" that have been in
discussion.

Here, I want to group together a set of possible resolutions that go
together if we accept my earlier proposal to handle "asynchronous
agreement" via a new stateful Agreement life-cycle.

  A. Agreements get a new life-cycle state "Pending" which means that
     an offer has been made but no obligations are in effect yet. The
     term-level status is undefined at this point.

  B. Agreements get a new life-cycle state "Rejected" which means that
     the offer was rejected and no obligations will ever be in effect.

  C. Agreements get a new life-cycle state "Observed" which means that
     an offer has been accepted and all obligations are in effect. The
     term-level status is meaningful at this point.  This state
     captures the semantics of the entire lifespan of the Dec 2004
     draft (module the confusion around termination).

     1. The life-cycle model includes transitions Pending->Observed and
        Pending->Rejected but NOT Observed->Rejected.

     2. Additional states may be warranted to try to resolve the many
        questions surrounding "termination" and "expiration."

  D. The existing createAgreement operation remains as an interaction
     where an input offer initiates a synchronous acceptance decision;
     the response is either a fault for rejection or an EPR to an
     Agreement that MUST already be in the Observed state.

     1. The optional initiatorAgreement EPR is retained but the
        responder is under no obligation to invoke anything on this
        service.  It is an optional avenue for the responder to
        monitor the "initiator's view" of their agreement. (And to
        attempt to initiate other control processes?)

  E. An optional AgreementAcceptance portType is introduced with two 
     operations: acceptAgreement and rejectAgreement.

     1. Both operations accept an empty input, as the association with
        an agreement is implicit via the WSRF addressing model.

     2. An optional fault might be useful on rejectAgreement input to
        communicate why the offer was rejected?

     3. These operations are only meaningful when the
        AgreementAcceptance service is in a Pending state. The
        operations synchronously change the service state to Observed
        or Rejected, respectively.

     4. The AgreementAcceptance and Agreement portTypes may be merged
        to form a single service interface, and the state is shared
        between them. (What is the right way to do this in WSDL?
        Provide portType combinations in specification?)

  F. A new createPendingAgreement operation is introduced where an
     input offer initiates an asynchronous acceptance decision; the
     response is either a fault (fatal errors/rejection) or an EPR to
     an Agreement that MAY be in Pending, Observed, or Rejected state.

     1. The responder MUST update its state RP to either Observed or
        Rejected following its decision.

     2. The initiator MAY use alternate mechanisms to determine if and
        when the Agreement transfers to Observed, including but not
        limited to the querying of a state RP.  Until the initiator
        determines the state as changed to Observed or Rejected, it
        SHOULD NOT assume the outcome.

     3. An optional initiatorAcceptance EPR MAY appear in the input
        message, in which case the responder MUST invoke
        acceptAgreement or rejectAgreement to communicate its
        decision, in addition to updating its state RP.

     4. An optional initiatorAgreement EPR MAY appear as in
        createAgreement.  This EPR MAY be the same as the
        initiatorAcceptance EPR, if the service implements both
        interfaces.

     5. Should the output allow an optional state indicator?  I think
        it is simpler to say "no" and uniformly assume an interaction
        after creation.

  G. Topic "Changing Offers" is resolved as the input offer is
     accepted or rejected WITHOUT MODIFICATION by the agreement
     acceptance decision.  Because of this, no response Agreement
     document is required in any of the above mechanisms.

     1. Should there be an optional mechanism to retrieve the
        agreement document from the responder in such a way that it
        MAY be signed or otherwise held as proof of acceptance for
        auditing purposes?  If so, does a queryable "agreement RP"
        satisfy this need?

karl

-- 
Karl Czajkowski
karlcz at univa.com