The whole idea of an abstract "agreement" that is separable from the
Agreement resource is troublesome. In order to make sense of it, I
have taken to understanding the "agreement" word to mean "the
obligations to which the parties are bound as a result of this
WS-Agreement interaction."
I cannot readily accept the idea that the Agreement resource can be
destroyed and yet the "agreement" still exists in some state other
than "all obligations are now historical and let's balance the
accounting." If the agreement terms have obligations that are still
within scope, I think it should be impossible to destroy the Agreement
resource which represents the management interface to those
active/pending behavioral obligations.
The spec currently says, I think, that the resource SHOULD outlast the
agreement and I think the spec should read that the resource MUST
outlast any obligations denoted in the agreement.
I think, but am not sure, that Heiko's idea of terminating an
agreement (not the Agreement resource) is to release the parties from
these obligations. If I understand Jon's objection, I think it is that
such a notion is not really well defined. Releasing parties from the
obligation can mean a number of different things:
a) Truncate the scope of obligations and resolve accounting as if
the obligations had been scoped from their original start time
until the time of this truncation.
b) Act as if the obligations never existed, and each party absorbs
their own costs incurred so far.
c) Form a new Agreement which amends the obligations of the old;
resolve accounting based on the new terms, which could encode a
detailed transitional cost model, etc.
d) Trigger some existing "escape" clause in the agreement terms
which specified how to amend the obligations as in (c).
Of course, in all of these there is an assumed change in behavior of
the parties to coincide with these changes in obligation.
I think it is a fair point that one cannot simply talk about
terminating the Agreement resource or its represented obligations
without identifying which of these avenues (or some other) are to be
followed. In the real world of contracts and agreement, things are
not destroyed so much as ammended and obsoleted. The old stuff is
never forgotten, and in fact can be dragged in to court as evidence to
help resolve later conflicts.
At the same time, we have practical use for cancelling the obligations
in some domains, e.g. cancel a job halfway through the run. What we
need to do is capture the right form of ammendment. I think for jobs,
the flavor (a) is about right; the job execution gets truncated and
the user gets billed for time spent so far. If we get into fancier
resources or advance reservation, we might need some additional
penalty clause to be triggered as in (d). The general case is (c)
where another offer/accept cycle can explicitly "ammend" or "obsolete"
an existing agreement. I don't know if this should always create a
new Agreement resource or simply operate on the existing one.
In practice when two people decide to "tear up" a contract they are
really making a token gesture that destroys some physical records and
creates a new verbal agreement that they will ammend the old agreement
as described above in (b)!
What I think all of this gets at is that the Agreement resource
universe of WS-Agreement is a subset of the "agreement" universe where
our WS-Agreement parties live. An Agreement resource MAY be retired
because its agreement obligations have become historical curiosity.
The various actions that can cause obligations to become "past tense"
range from timer expiration, to explicit destroy-resource requests or
replacement Agreement creation. When this happens, history is not
erased but rather system management state is ammended and pertinent
information is recorded into audit and accounting systems.
Do we need more explicit Agreement content to denote what forms of
ammendment can (or have) been applied to the obligations of an
Agreement? Or can that be implicit in the domain-specific terms?
karl
--
Karl Czajkowski
karlcz(a)univa.com
