Karl: Thank you very much for your comments (and your patience in wating for my reply) The repli ----- 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)
Toshi, I have the following comments/observations after reviewing your wiki page... sorry I have not been able to keep a close watch on the recent activities of the group.
1. The idea of negotiation of alternatives is difficult and I think requires a better negotiation protocol.
OK <snip>
What I would suggest is that you try to keep this aspect of negotiation protocol orthogonal to the underlying notion of renegotiation. First, work on the semantics for renegotiation of an agreement as you have done, e.g. replacement/superceding of an agreement. Then, admit that basic or advanced protocols could be used to negotiate either the initial or subsequent agreement.
I think this is fine as *much* discussion would have to be made for negotiation of alternatives.
2. I think the idea of superceding an agreement is fine, but I have trouble seeing a distinction between this and the general use of agreements in the context of other agreements. For example, the advance reservation scenario allows "claiming" of a resource reservation, and you can interpret this as adjusting an initial resource agreement to include binding to an application, with the same results as if someone simply negotiated an application with the same QoS terms in one shot...
What I would point out is that this claiming/context model allows many:many derivation of agreements in the general case. E.g. I could reserve a large resource (in space-time) and consume it with multiple applications which either run serially or in parallel. I could also combine several resources (in separate agreements) into a complex application. Couldn't a renegotiation also be temporary, e.g. "boost this resource reservation for the next hour, but then fall back to the previous terms"?
Your points are exactly what we had in mind in the business grid project.. (The scenarios are included in HPCC2006 paper http://www.coregrid.net/mambo/images/stories/TechnicalReports/tr-0050.pdf I've also uploaded an excerpt from the presentation we made onto the Wiki. The last slide exactly shows the point I wanted to make.)
I am not sure how "supercededby" would be applicable here.
I think Supercededby could be useful for some purposes. eg. Logging purposes to show which Agreement had been effective until when then Superceded/replaced by which Agreement to check for SLA violation etc.
Is it worth having one more general metalanguage for discovery/navigation of agreements which are linked to other agreements? We could use the extensibility of the wsag:Context to enumerate the actual claimed or superseded agreements,
I think this could be one way of realizing this feature. (I had intended to put the 'Superceded-by " in the wsag:Context)
and it seems useful to have a dynamic resource property which could provide reverse-lookup of new agreements which list an agreement in the new wsag:Context too.
3. Also, a general concern I have is that the discussions are not crisp about the uses of the agreement. The talk of race conditions makes me nervous, as it seems to combine denotation of service terms with the implementation of resource managers. In my view, WS-Agreement is completely focused on the establishment of terms between the two parties, and says nothing about how one of the parties is implementing the protocol.
I agree that this is a bit of an implementation issue but I think the discussion we had in Terminating was that Termination could take a long time to be decided and we extended the Agreement State wiht such states as ObservedAndTerminating so I had wanted to be consistent in this sense. ##As an off track issue, It seems in creating the official pdf, # http://www.ogf.org/documents/GFD.107.pdf Figure in Section 7.1 got corrupted.. Any way to remedy this?
4. The question of having "responder initiated renegotiation" was foreseen in the optional symmetric protocol mode. In essence, if EPRs are exchanged so that both parties have an EPR representing the other party's view of the agreement, then they can switch roles and become initiator for further rounds of communication. In order to use this feature, one would need to define an extension to the protocol, e.g. have the symmetric agreement resources support an extended protocol which includes the renegotiation operations as well as the basic monitoring/cancellation operations.
I think it would be appropriate to define a new negotiation protocol as a profile on this feature, so that a specific SDT would demand the presence of a renegotiation facility which would then be available as extended operations and resource properties on the Agreement resource.
Again, if we consider the fuzzy case of many:many renegotiations, the best approach might be a simple RP in the agreement that holds an EPR to the renegotiation service, thereby separating discovery (via lookup of this RP an existing agreement) from claiming/context references which might involve more than one agreement at a time.
This is an interesting (if stagering) point. I had naively assumed that AR would be maintaining the Agreements A third party Agreement Factory could solve the problem with No.7 but this might have quite an impact on other parts of WS-Agreement Spec. Comments from other people also appreciated. Best Regards and Thanks Toshi
karl
-- Karl Czajkowski Software Architect
Univa Corporation 1001 Warrenville Road, Suite 550 Lisle, IL 60532
karlcz@univa.com www.univa.com ________________________________________________________________ www.univa.com.
The Leaders of Open Source Cluster and Grid Software