[graap-wg] termination versus determination

[Heiko Ludwig]

Coming back to the termination issue ...

owner-graap-wg at ggf.org wrote on 02/28/2005 09:20:15 PM:

> 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 figure the notion of an "contract end date" refers mostly to a 
colloqialism implying the time when all obligations relating to service of 
the contract are over and is particularly applicable to services that are 
provided for a particular time.

Q: Do we want to make the resource lifetime the equivalent of the time of 
the main service; and what if the model doesn't fit, e.g., in case of a 
set of services, disputes or services where an end time doesn't really 
apply. 
 
> 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?

This means that the AgreementProvider will se tthe resource lifetime 
according to the (domain-specific) times the terms indicate and will only 
really end the resource when the last "main" obligation is fulfilled. What 
happens if it never is, if something goes wrong? 

I am not sure whether we want to bring too much contract-specific 
semantics to the notion of recource lifetime. If we cannot map reasonably, 
we should keep it separate. 

>   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?
> 

Following approach 2 entails extending the obligation and rights semantics 
that we have. At the moment we don't have the explicit notion of an option 
on an agreement level, just service terms and guarantee terms. However our 
service description terms might contain this on the domain-specific level. 
We could extend our term model to distinguish options, guarantees and 
services (what will be done without exercising the option). That's what 
WSLA provides and it worked well. On which level, though, will the 
AgreementProvider offer an operation to exercise an option, if we assume 
that also the initiator might want to exercise it: Agreement or service? 

2 and 3 point to a model where agreements basically modify the set of 
rights and obligations that are in force between 2 parties. That's a model 
that is not uncommon in service management but would require some 
adjustments to the expressivness of the agreement spec and it raises the 
issue of how to expose the state monitoring. A per-agreement state 
monitoring might not be appropriate in this case.

Amending the spec in the proposed sense might be worth the effort but it 
will take some time. Furthermore, the proposal puts quite some more 
requirements on the implementors of the spec. Finally, we still don't have 
a very simple mechanism by which initiator or provider can terminate the 
agreement consensually and easily. The terminate opreation was meant do 
provide this, probably still requiring all those mechanism you listed 
above.

<rest removed> 

Heiko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/graap-wg/attachments/20050302/73da01ae/attachment.html