[graap-wg] termination versus determination

[Karl Czajkowski]

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