From your list, I think that only c) and d) can work. a) and b) assume a lot about when payment occurs, etc. I'm not sure that it's always possible to roll things back. The way that you "get out" of a contract, is by both parties signing some sort of "amendment" to the contract - case c). It is possible that there would be some sort of clause pre-written into some agreements - your case d). These could be used to handle specific things like, "if the resource falls over during the execution of your job, you get any money back, and there's nothing else to happen between us". Note that these are not something special - they are simply the "compensation" clauses that we used to talk about in GESA. I think you need to able to do c) - to just have d), you need to be able to predict all the conditions that might arise, which is (of course) impossible. (Incidentally, I argued for c) strongly in the past, when I first saw the "terminate" operation.) I think that one of the reasons that thinking about this is complicated is that you have a resource, fronted by a service, to represent the agreement. It's a very odd responsibility model - essentially a single (potentially third) party is trusted for maintaining the definitive version of the agreement. I disagree with Karl's statement that the resource IS the agreement - if this were true, some accident befalling the resource can eliminate it! In Grid computing, resources are fallible. They can disappear. What happens when a WS-Agreement resource fails? Is it equivalent to contracts disappearing into thin air? Or do we say that WS-Agreement resources have to be reliable, and always available? If so, how is this achieved? If the agreement was represented by a signed document, which both parties had a copy of, then these strange issues about the meaning of terminating the service would not present themselves. Both parties have a responsibility to look after their copy of the agreement...just like that paper based system which has worked for hundreds of years. Jon. On Feb 25, 2005, at 12:43 AM, Karl Czajkowski wrote:
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@univa.com