[graap-wg] termination versus determination

[Karl Czajkowski]

On Mar 02, Heiko Ludwig loaded a tape reading:
...
> 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.
> 

I agree. If I am understanding the objections raised, it is that even
this "simple" case is underspecified.  Even if termination is meant
for things like "end my job", I think Jon has raised the issue that
you really need to know in what way (with what amended obligations)
the job will be ended... who gets paid what, etc.

I think it would be more clear if we just had a way to annotate
service descriptions w/ temporal scoping (start+end times) and leave
the whole Agreement expiration as the latest of all service
description end times.  To adjust the end time(s) would require
amendment of the scope of these services.


> 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 had assumed from the start (until I read that bit in the draft about
the separate agreement expiration time) that the times were the same.
I realize now that this becomes murky when one pays attention to cases
with more than one service or when the "second-class" obligations,
like accounting and payment, become an issue...


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

Then the resource would stick around and hopefully indicate a
"something has gone wrong, please help me" status? :-) Note, however,
that I think obligations could equally go out of scope after having
been satisfied or violated and abandoned.  Once there is no more
service action that will result, we are just talking about knowledge
of past obligations for accounting.

I don't think there is ever a time when it is impossible that an
amendment could be made, so I am willing to admit that some amendments
will happen after the Agreement resource has been retired.  For
example, contested payment obligations could be reversed or even just
refunded on a basis of generosity (or any arbitrary domain-specific
policy).  I am not advocating that Agreement resources must persist
forever to allow for these cases.


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

I think we could (must?) avoid mandating a behavior because it is so
dependent on domain-specific semantics.  But I think we could appeal
to intuition and abstraction in trying to clarify the difference
between "retiring" the resource and actually amending obligations; I
think it would be best for most domain-specific deployments of
WS-Agreement to resist tearing down the management interface before
the interesting obligations are met or terminally rejected.


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

I could accept the "options" being encoded explicitly or implicitly in
domain-specific terms/extensions.  The only question then is whether
obligation termination or amendment can be addressed through a generic
"terminate" operation or whether domain-specific "exercise option Foo"
operations must always be introduced for this?


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

I am not sure this introduces as much complication as you imply.  I
think all agreements always "modify the rights and obligations that
are in force between 2 parties", because these parties live in a
stateful and finite universe.  So I've _always_ viewed WS-Agreement as
modifying the universe of policies based on a particular set of
"transient" goals.  The specification is more or less aligned to
support this now, and I think we just need to clean up some rough
edges.

As for monitoring, I think any realistic scenario will always admit
that there are external services and parties who may play parts in
monitoring, detection, adaptation, audit, and accounting.  When I say
"external", I mean external to the WS-Agreement specification and
quite possibly external to any domain-specific Agreement that is
established.  WS-Agreement only needs to establish the parts that are
being dynamically established and adjusted by automated entities; it
does not have to presume an initial context of nothingness between the
parties.


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

I'm not sure how much more requirements are placed on implementors.

Again, I see this mostly as trying to clarify the semantics of what we
are proposing (and adjusting the mechanisms if they aren't consistent
with a reasonable semantics).  The only implementor burden I see is in
understanding the domain terms well enough to decide if
termination/amendment should be allowed or not, and I think this
burden already existed; I think this discussion is just about how to
render the mechanisms to clarify their meaning as it relates to the
domain-specific environment.


> <rest removed>
> 
> Heiko

karl

-- 
Karl Czajkowski
karlcz at univa.com