HI Dominic: Thanx for the response.
For that reason I mentioned the "superseded by" information that could be added to the context. A third party might need to check whether the SLA is superseded by another SLA periodically. Kind of ugly...
I see. I had been wondering what you meant by "superseded by".. It might be necessary to have a Notification sent to all the bodies using the old EPR...
oh, does this imply that you want a simple two way communication?
AI ------ 1. please change SLA like this ------> AR 2. AR changes SLA <------ 3. confirms change ------------------
or
AI ------ 1. please change SLA like this ------> AR 2. AR rejects change <------------- 3. exception ------------------
for AI to AR yes, for AR to AI this becomes a bit more complex.. (Please cf. the ppt attached in the Wiki page)
AI ------ 1. please change SLA like this ------> AR 2. AR decides that it can change SLA 3. AR calculates price of modification <----------- 4. new offer ------------------ 5. AI decides whether change is worth the price --------- 6. confirmation/rejection --------->
I agree that this is more beautiful. OTOH I think that this raises the issue related to two phase commit protocol that had been discussed for a long time and in a heated manner by quite a number of people (before my time actually) and finally got rejected in the original WS-Agreement protocol. I am a bit afraid of waking the sleeping monster, but I welcome people's comments.. Best regards Toshi ----- Toshiyuki Nakata 中田 登志之 Executive Chief Engineer, Central Research Lab. NEC 1753, Shimonumabe, Nakahara-Ku, Kawasaki,Kanagawa 211-8666,Japan Tel +81-44-431-7653 (NEC Internal 22-60035) Fax +81-44-431-7609 (NEC Internal 22-60509)
-----Original Message----- From: Dominic Battre [mailto:mailinglists@battre.de] Sent: Thursday, August 23, 2007 5:25 PM To: Toshiyuki Nakata Cc: 'GRAAP-WG' Subject: Re: [GRAAP-WG] Modification to the wiki Page on Renegotiating an established Agreement
Hi Toshi,
(I am resending this mail because I used the wrong email address and it bounced)
Hi: Dominic： Thank you very much for your thoughtful comments. I'll just address the first one. For the rest, please give me some time.
ad "New EPR or re-write the current WS-AG document?" during the renegotiation the agreement is in some kind of intermediate change (i.e. it might be in a proposed new status that is not yet accepted by the other party), don't we need a new EPR for that?
The reason that I wanted to re-write the current WS-AG rather than a new EPR was that one could never know who might be using the old EPR. In a complex scenario like the one I mentioned in Business Grid Computing case or some broker case, old EPR might be propagated to other parties who would be using it.
For that reason I mentioned the "superseded by" information that could be added to the context. A third party might need to check whether the SLA is superseded by another SLA periodically. Kind of ugly...
So I thought that it would not be realistic to assure that the NEW EPR would be propagated to all the bodies who might be referring to the old EPR.
On the other hand, re-writing the current WS-AG document kept by the Agreement Responder does cause a serious race condition when the AR is the requestor for modifying the Agreement. (ie. it must be re-written only after the AI says he agrees, but when?)
oh, does this imply that you want a simple two way communication?
AI ------ 1. please change SLA like this ------> AR 2. AR changes SLA <------ 3. confirms change ------------------
or
AI ------ 1. please change SLA like this ------> AR 2. AR rejects change <------------- 3. exception ------------------
I am not sure whether this is sufficient. Suppose that the SLA carries a price tag that needs to be calculated by the AR. I would like to see some kind of two phase protocol...
AI ------ 1. please change SLA like this ------> AR 2. AR decides that it can change SLA 3. AR calculates price of modification <----------- 4. new offer ------------------ 5. AI decides whether change is worth the price --------- 6. confirmation/rejection --------->
In my opinion, for negotiation and for renegotiation we need this kind of request-offer-commit protocol. So it is no easier if the AR initiates the renegotiation than if the AI initiates the renegotiation. But I think that we see the same issue there: "What do the resource properties of the agreement look like if an offer has been sent but not confirmed?"
I agree that creating a new agreement EPR is not very beautiful. Maybe one could create such an EPR for negotiation until a party commits. At that time Context, SDTs and GTs are copied to the old agreement.
Best regards,
Dominic