[graap-wg] termination versus determination

[Karl Czajkowski]

On Feb 28, Jon MacLaren loaded a tape reading:
> I didn't catch any previous suggestion that agreements would have no 
> end date.  Contracts typically have some sort of end date attached to 
> them.  The problem for me is having this "terminate" operation, whose 
> semantics are hard to define, for ending things ahead of time.
> 

I am wondering if the full space should have three different ending
mechanisms:

  1) Retirement via the WSRF terminate or lifetime expiration, which
     shuts down the first-class WS-Agreement management interface but
     does not amend any obligations represented in the Agreement
     resource.  It simply makes them unavailable for direct monitoring
     or amendment by reference.

     Q: Should retirement ever be allowed while service-domain
     obligations are still in scope?  Can we even distinguish what I
     referred to before as "first class" obligations (like running a
     job) from "second class" obligations (like making payment)?
     Perhaps some extra markup could annotate such terms?

  2) Activation of a pre-specified escape clause of the Agreement
     resource which amends the obligations and also could amend or
     hasten the retirement schedule.

     Q: How can we do this to support existing domains and encourage
     better modeling of escape terms over time?

  3) Full first-class amendment via WS-Agreement creation.  Once an
     existing agreement is subsumed by another and its obligations are
     out of scope, the old one can be retired.

If these reasonably cover the termination variants we have discussed,
I would tend to think it is better to include them in the
specification and leave it up to domain specializations or operating
policies to determine when the different mechanisms are allowed.  I am
not certain, however, that we can capture (3) because it requires the
"related agreement" concept to reference existing Agreement resources
in a new offer; can we see a generic enough pattern for mechanism (3)
such that we can introduce a relationship for that without trying to
over-reach?


> As you already have a system for creating agreements, making an 
> amendment is using a system you've already defined.  Whereas adding a 
> "terminate" operation is creating a new mechanism.  It would actually 
> be simpler to remove "terminate" from the specification.
> 

We also have practical concerns about "resource leakage" which is why
I emphasize the retirement idea above.  I think we have to provide a
way to purge WS resources during operation, or many people will ignore
the specification as malformed or impractical.


> I believe that you'll find the "terminate" operation to be quite 
> complicated to actually use.  At least if you have a second agreement, 
> you have a signed record that this has happened.  (With a "terminate" 
> operation, the only records you have are in log files.)  And you'll 
> need some sort of amendment system if you want to do re-negotiation 
> anyway...
> 

Would you accept the retirement of agreement interfaces without any
change to the agreed obligations?  Would you accept the use of a
terminate pattern to trigger a non-reversable escape clause,
e.g. "cancel my job according to the original agreement"?


> Getting back to Karl's message, I agree that you could find scenarios 
> where option a) would work.  (I don't think that it would always work 
> in job management, though.  There are probably charging models where 
> rolling back is not sufficient, and some other form of compensation is 
> required for backing out of the contract.
> 
> Also, I agree that there can be meaningful early ways out of a 
> contract, but that these should be pre-defined.  Like if I was renting 
> an apartment for a year, but there is a clause stating that with 2 
> months notice, I can leave during the term of the contract.  You can 
> agree this sort of stuff, but it's execution should be out of band in 
> terms of the agreement protocol.  It's between the two parties to 
> arrange this sort of stuff.  (Of course, this complicates the expiry of 
> the agreement resource - maybe you want to keep it around until the 
> original end-date in any case.)
> 

I am only concerned about whether this escape mechanism, when
applicable, has to be explicitly modeled in the agreement terms or
whether it can be implicit in the type/domain-specialization.  Keeping
on my Globus GRAM architect hat, I have to be able to support existing
job cancel mechanisms!  I need to do this even if the initial
semantics are weakly defined and future standards efforts are needed
to rationalize different cancelation/compensation approaches.

> Jon.
> 
> 



karl

-- 
Karl Czajkowski
karlcz at univa.com