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. As you already have a system for creating agreements, making an amendment is using a system you've already defined. Whereas adding a "terminate" operation is creating a new mechanism. It would actually be simpler to remove "terminate" from the specification. I believe that you'll find the "terminate" operation to be quite complicated to actually use. At least if you have a second agreement, you have a signed record that this has happened. (With a "terminate" operation, the only records you have are in log files.) And you'll need some sort of amendment system if you want to do re-negotiation anyway... Getting back to Karl's message, I agree that you could find scenarios where option a) would work. (I don't think that it would always work in job management, though. There are probably charging models where rolling back is not sufficient, and some other form of compensation is required for backing out of the contract. Also, I agree that there can be meaningful early ways out of a contract, but that these should be pre-defined. Like if I was renting an apartment for a year, but there is a clause stating that with 2 months notice, I can leave during the term of the contract. You can agree this sort of stuff, but it's execution should be out of band in terms of the agreement protocol. It's between the two parties to arrange this sort of stuff. (Of course, this complicates the expiry of the agreement resource - maybe you want to keep it around until the original end-date in any case.) Jon. On Feb 28, 2005, at 11:05 AM, Heiko Ludwig wrote:
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@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@univa.com