Coming back to the termination issue ...

owner-graap-wg@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