termination versus determination
The whole idea of an abstract "agreement" that is separable from the Agreement resource is troublesome. In order to make sense of it, I have taken to understanding the "agreement" word to mean "the obligations to which the parties are bound as a result of this WS-Agreement interaction." I cannot readily accept the idea that the Agreement resource can be destroyed and yet the "agreement" still exists in some state other than "all obligations are now historical and let's balance the accounting." If the agreement terms have obligations that are still within scope, I think it should be impossible to destroy the Agreement resource which represents the management interface to those active/pending behavioral obligations. The spec currently says, I think, that the resource SHOULD outlast the agreement and I think the spec should read that the resource MUST outlast any obligations denoted in the agreement. I think, but am not sure, that Heiko's idea of terminating an agreement (not the Agreement resource) is to release the parties from these obligations. If I understand Jon's objection, I think it is that such a notion is not really well defined. Releasing parties from the obligation can mean a number of different things: a) Truncate the scope of obligations and resolve accounting as if the obligations had been scoped from their original start time until the time of this truncation. b) Act as if the obligations never existed, and each party absorbs their own costs incurred so far. c) Form a new Agreement which amends the obligations of the old; resolve accounting based on the new terms, which could encode a detailed transitional cost model, etc. d) Trigger some existing "escape" clause in the agreement terms which specified how to amend the obligations as in (c). Of course, in all of these there is an assumed change in behavior of the parties to coincide with these changes in obligation. I think it is a fair point that one cannot simply talk about terminating the Agreement resource or its represented obligations without identifying which of these avenues (or some other) are to be followed. In the real world of contracts and agreement, things are not destroyed so much as ammended and obsoleted. The old stuff is never forgotten, and in fact can be dragged in to court as evidence to help resolve later conflicts. At the same time, we have practical use for cancelling the obligations in some domains, e.g. cancel a job halfway through the run. What we need to do is capture the right form of ammendment. I think for jobs, the flavor (a) is about right; the job execution gets truncated and the user gets billed for time spent so far. If we get into fancier resources or advance reservation, we might need some additional penalty clause to be triggered as in (d). The general case is (c) where another offer/accept cycle can explicitly "ammend" or "obsolete" an existing agreement. I don't know if this should always create a new Agreement resource or simply operate on the existing one. In practice when two people decide to "tear up" a contract they are really making a token gesture that destroys some physical records and creates a new verbal agreement that they will ammend the old agreement as described above in (b)! What I think all of this gets at is that the Agreement resource universe of WS-Agreement is a subset of the "agreement" universe where our WS-Agreement parties live. An Agreement resource MAY be retired because its agreement obligations have become historical curiosity. The various actions that can cause obligations to become "past tense" range from timer expiration, to explicit destroy-resource requests or replacement Agreement creation. When this happens, history is not erased but rather system management state is ammended and pertinent information is recorded into audit and accounting systems. Do we need more explicit Agreement content to denote what forms of ammendment can (or have) been applied to the obligations of an Agreement? Or can that be implicit in the domain-specific terms? karl -- Karl Czajkowski karlcz@univa.com
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. The way that you "get out" of a contract, is by both parties signing some sort of "amendment" to the contract - case c). It is possible that there would be some sort of clause pre-written into some agreements - your case d). These could be used to handle specific things like, "if the resource falls over during the execution of your job, you get any money back, and there's nothing else to happen between us". Note that these are not something special - they are simply the "compensation" clauses that we used to talk about in GESA. I think you need to able to do c) - to just have d), you need to be able to predict all the conditions that might arise, which is (of course) impossible. (Incidentally, I argued for c) strongly in the past, when I first saw the "terminate" operation.) 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! 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? 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. On Feb 25, 2005, at 12:43 AM, Karl Czajkowski wrote:
The whole idea of an abstract "agreement" that is separable from the Agreement resource is troublesome. In order to make sense of it, I have taken to understanding the "agreement" word to mean "the obligations to which the parties are bound as a result of this WS-Agreement interaction."
I cannot readily accept the idea that the Agreement resource can be destroyed and yet the "agreement" still exists in some state other than "all obligations are now historical and let's balance the accounting." If the agreement terms have obligations that are still within scope, I think it should be impossible to destroy the Agreement resource which represents the management interface to those active/pending behavioral obligations.
The spec currently says, I think, that the resource SHOULD outlast the agreement and I think the spec should read that the resource MUST outlast any obligations denoted in the agreement.
I think, but am not sure, that Heiko's idea of terminating an agreement (not the Agreement resource) is to release the parties from these obligations. If I understand Jon's objection, I think it is that such a notion is not really well defined. Releasing parties from the obligation can mean a number of different things:
a) Truncate the scope of obligations and resolve accounting as if the obligations had been scoped from their original start time until the time of this truncation.
b) Act as if the obligations never existed, and each party absorbs their own costs incurred so far.
c) Form a new Agreement which amends the obligations of the old; resolve accounting based on the new terms, which could encode a detailed transitional cost model, etc.
d) Trigger some existing "escape" clause in the agreement terms which specified how to amend the obligations as in (c).
Of course, in all of these there is an assumed change in behavior of the parties to coincide with these changes in obligation.
I think it is a fair point that one cannot simply talk about terminating the Agreement resource or its represented obligations without identifying which of these avenues (or some other) are to be followed. In the real world of contracts and agreement, things are not destroyed so much as ammended and obsoleted. The old stuff is never forgotten, and in fact can be dragged in to court as evidence to help resolve later conflicts.
At the same time, we have practical use for cancelling the obligations in some domains, e.g. cancel a job halfway through the run. What we need to do is capture the right form of ammendment. I think for jobs, the flavor (a) is about right; the job execution gets truncated and the user gets billed for time spent so far. If we get into fancier resources or advance reservation, we might need some additional penalty clause to be triggered as in (d). The general case is (c) where another offer/accept cycle can explicitly "ammend" or "obsolete" an existing agreement. I don't know if this should always create a new Agreement resource or simply operate on the existing one.
In practice when two people decide to "tear up" a contract they are really making a token gesture that destroys some physical records and creates a new verbal agreement that they will ammend the old agreement as described above in (b)!
What I think all of this gets at is that the Agreement resource universe of WS-Agreement is a subset of the "agreement" universe where our WS-Agreement parties live. An Agreement resource MAY be retired because its agreement obligations have become historical curiosity. The various actions that can cause obligations to become "past tense" range from timer expiration, to explicit destroy-resource requests or replacement Agreement creation. When this happens, history is not erased but rather system management state is ammended and pertinent information is recorded into audit and accounting systems.
Do we need more explicit Agreement content to denote what forms of ammendment can (or have) been applied to the obligations of an Agreement? Or can that be implicit in the domain-specific terms?
karl
-- Karl Czajkowski karlcz@univa.com
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
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
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
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 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? 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?
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.
We also have practical concerns about "resource leakage" which is why I emphasize the retirement idea above. I think we have to provide a way to purge WS resources during operation, or many people will ignore the specification as malformed or impractical.
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...
Would you accept the retirement of agreement interfaces without any change to the agreed obligations? Would you accept the use of a terminate pattern to trigger a non-reversable escape clause, e.g. "cancel my job according to the original agreement"?
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.)
I am only concerned about whether this escape mechanism, when applicable, has to be explicitly modeled in the agreement terms or whether it can be implicit in the type/domain-specialization. Keeping on my Globus GRAM architect hat, I have to be able to support existing job cancel mechanisms! I need to do this even if the initial semantics are weakly defined and future standards efforts are needed to rationalize different cancelation/compensation approaches.
Jon.
karl -- Karl Czajkowski karlcz@univa.com
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
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@univa.com
I think that escaping from an agreement should always be considered domain specific, and remain outside of the scope of the protocol. The proposed standard already encompasses agreement discovery, creation and monitoring. I think including specific support for acceptable scenario-specific escape conditions introduces another facet. Introducing the terminate operation tries to do this too. In my view, it provides a false panacea - it encourages people to believe (and perhaps even expect) that they can simply and generically escape from an agreement... Jon. On Mar 2, 2005, at 8:40 PM, Karl Czajkowski wrote:
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@univa.com
participants (3)
-
Heiko Ludwig -
Jon MacLaren -
Karl Czajkowski