[graap-wg] termination versus determination

[Heiko Ludwig]

Conceptually, I agree with the notion that agreements shouldn't be 
terminated at all and their useful lifetime as a resource int he WSRF 
sense ends at some point. The validity of agreements should only be 
terminated by another agreement. However, this raises 2 pragmatic issues:

1. Agreements not having a reasonable end date don't quite fit the 
resource lifecycle model since they, in theory, should be available 
indefinitely. We have to find a pragmatic way of removing them when they 
are not useful anymeore, e.g., when one cannot claim service against them 
etc.

2. Agreeing to "terminate" (not provide service against it) an agreement 
using another agreement is quite a bit of overhead. It would be good to 
have a simple standard means that would shortcut this, such as a 
"terminte" method. Ths could be optional and rejectable.

Trying to keep things simple,
Heiko

owner-graap-wg at ggf.org wrote on 02/25/2005 10:54:03 PM:

> On Feb 25, Jon MacLaren loaded a tape reading:
> > 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.
> > 
> 
> I wonder if (a) can work in certain domains, e.g. job
> management. First, I think domain-specific terms could imply the
> compensation mechanism and have specialized terms to parameterize any
> variants allowed in this domain.  Secondly, I think we have to admit
> that existing domains may have the ability to cancel requests while
> the entire accounting system is understood out of band.  (I can cancel
> a job on any Grid system I know of today, and some _unspecified_
> accounting takes place.  We need to support these systems in a
> transitional sense; we cannot say "no entry" until each domain has a
> rich cost modeling language.)
> 
> 
> > The way that you "get out" of a contract, is by both parties signing 
> > some sort of "amendment" to the contract - case c).
> > 
> 
> Yes, I understand that point... the question is, are these amendments
> always WS-Agreements?  Or should we admit the fact that some
> (lowercase) agreements are formed by simpler interactions that can
> terminate a WS-Agreement?
> 
> 
> > 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!
> > 
> 
> When I said "resource" I meant the WS-Resource which is nothing but
> abstract document state in my mind.  I did not mean computing resource
> etc.  I still think it is appropriate and even desirable to say that
> this WS-Agreement resource represents the (lowercase) agreement in a
> one-to-one manner.  We can mandate that destruction of the resource
> implies "retirement" of the agreement and vice-versa.  What I mean is
> that we cannot destroy the management interface used to talk about the
> obligations until the obligations are "complete", e.g. historical and
> no longer constraining the behavior of the parties in the
> (domain-specific) service domain.  Retired doesn't mean forgotten, but
> transitioned from this on-line systems management regime to some other
> audit, accounting, and reconciliation regime.
> 
> The way I really see it is: the WS-Agreement resource for a particular
> domain-specific service captures a limited slice of the operating
> policies of the domain-specific service provider and consumer. This is
> its primary purpose: to allow automated management of domain-specific
> operating policies. As long as there are still dynamically-created
> operating policies, the WS-Agreement resource should remain to allow
> management of these policies.  As soon as the dynamic policies are
> removed, whether by the passing of time or some explicit termination
> request, the WS-Agreement resource may be safely eliminated. I think
> of the domain-specific operating policies as the first-order
> obligations of the agreement parties.
> 
> The WS-Agreement resource also may capture how those operating
> policies relate to other domains such as accounting, audit, and
> payment.  As we have both said, these second-order obligations cannot
> be erased or "managed" in the sense that we would like to manage the
> first-order operating policies.  When we drop the first-order rock
> into the job pool or take it out again, there are ripples through the
> second-order accounting system. We cannot just will the ripples
> away. :-)
> 
> Fundamentally I see WS-Agreement as the projection of
> systems-management platforms into the multi-agent realm: negotiated
> system behavior through automated federation of policies.  The
> cost/accounting stuff comes up because it is obviously important to
> allow reasoning about alternatives in a multi-agent system.  But
> WS-Agreement is not _about_ the accounting stuff; it just has to make
> nods to it in order to make systems management tasks feasible in a
> decentralized environment. (Ignoring, of course, that a domain-specific
> WS-Agreement could be about an accounting system!)
> 
> 
> > 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?
> > 
> 
> I don't think we should mix up availability and existence.  An
> implementation of WS-Agreement may have better or worse QoS.  We can
> still talk about Agreements and hope they (or a good copy) will become
> available in the future by the same name.  Destruction/termination
> means throwing away the name for the obligations and making them
> unmanageable forever.  We should never allow, say, a job to keep
> existing in the job system if the WS-Agreement job-submission resource
> is terminated.
> 
> 
> > 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.
> > 
> 
> There is nothing stopping both parties from requiring WS-Security or
> equivalent signed-message mechanisms in the binding layer, and
> archiving these messages as their "signed copies".  Perhaps this is a
> good argument for leaving the full Agreement document in the
> acceptance message?  Otherwise, some sort of out-of-spec "offer hash"
> would have to be added to the headers, or a signed RP query of the
> agreement would be needed to give the initiator his signature proof.
> 
> Separable from this who-signed-what question is the presentation of
> the obligations and service delivery---the on-line management
> interface. The current client-server interface is obviously asymmetric
> and "unfair" in that it doesn't give the initiator a way to report on
> his view of the obligation and performance.
> 
> I would like to see the symmetric (peer-to-peer) protocol variant
> corrected both for this "fair presentation" reason and for the more
> basic asynchronous signaling benefits.  I think both parties in the
> symmetric case would present WS-Agreement resources which represent
> the (lowercase) agreement obligations and performance, but each
> presenting their own view on it.  This gives you the "he said, she
> said" view of the system, but of course 3rd-party monitoring and audit
> might always be necessary to get the "actually happened" view.
> 
> 
> karl
> 
> -- 
> Karl Czajkowski
> karlcz at univa.com
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/graap-wg/attachments/20050228/5d25746f/attachment.html