[GRAAP-WG] Modification to the wiki Page on Renegotiatinganestablished Agreement
Toshiyuki Nakata
t-nakata at cw.jp.nec.com
Mon Aug 27 03:25:43 CDT 2007
Karl:
Thank you very much for a detailed comment on the wiki page.
Please give me some time to digest and respond as I am out of cycles right
now:-(
Best Regards & Thank you very much
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: Karl Czajkowski [mailto:karlcz at univa.com]
> Sent: Monday, August 27, 2007 11:50 AM
> To: Toshiyuki Nakata
> Cc: 'Dominic Battre'; 'GRAAP-WG'
> Subject: Re: [GRAAP-WG] Modification to the wiki Page on
> Renegotiatinganestablished Agreement
>
> 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.
>
> After much debate, as I recall, we limited WS-Agreement to simple
> acceptance of an offer. If the offer has alternatives in it, then
> the responder is accepting to satisfy this compound expression in
> any way he sees fit, with no information about how, or indeed
> whether his solution might vary over time and be satisfied by
> different clauses in the compound rules! It would take
> domain-specific interpretation of the SDTs to somehow fix this
> solution, as there is nothing in the protocol to communicate a
> "lowering" or simplification of the alternatives expression. (For
> example, I anticipated that in a basic use of JSDL for a job term,
> the interpretation could be defined that the service terms are
> chosen at job-start time and frozen, as is a typical implementation
> requirement for HPC resources... you would know they are not
> time-varying, though there is still no facility to communicate
> which exact parameters were chosen.)
>
> 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.
>
> For example, a relatively simple renegotiation could adapt the
> existing factory pattern for both initial and subsequent
> negotiations. If a future specification provides a multi-round
> negotiation to lower/simplify abstract agreement constraints to a
> more concrete solution, this could replace the basic factory
> pattern in both cases too.
>
>
> 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"?
>
> I am not sure how "supercededby" would be applicable here. 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, 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 do not see a necessary
> race condition for "supercededby" because I don't think the
> initiator (for example) needs to be aware of this state change in
> order to meaningfully express a claim against an agreement. If an
> agreement is renegotiated, it could still be usable for claiming by
> name, while the actual resource manager has to take into account
> that there are now aliases to the newly revised delivery terms...
>
>
> 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.
>
>
> karl
>
>
> --
> Karl Czajkowski
> Software Architect
>
> Univa Corporation
> 1001 Warrenville Road, Suite 550
> Lisle, IL 60532
>
> karlcz at univa.com
> www.univa.com
> ________________________________________________________________
> www.univa.com.
>
> The Leaders of Open Source Cluster and Grid Software
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4038 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/graap-wg/attachments/20070827/71449c5b/attachment.bin
More information about the graap-wg
mailing list