Re: [GRAAP-WG] Re-negotiation Protocol Proposal
[This started as a private message but Toshi and I realized we should put the discussion on the list...] On Feb 29, Toshiyuki Nakata modulated:
Hi Karl: we had three interesting sessions today. For the preparation of the sessions I created (today ;-) Some slides trying to see the roles. In pages 6-7 I tried to depict my interpretation of your comments. Please see if they are wrong or right. a)If wrong: Please tell me where I'd gone wron (and a picture would help :-))) b)If OK please give us comments on my question in slide 7. ie. How can ADF verify thatAR agreed to the modification?
I wouldn't say slide 7 captures my comment. My endpoint rendering doesn't imply a third entity, just that the responder entity is rendered with multiple endpoints to allow a more general scenario such as renegotiation that could combine multiple agreements (something you couldn't do if the preceding agreement is always implied like the "this" pointer in a simple object system): 1. agreement initiator sends offer to agreement factory 2. agreement factory sends accept (sync or async reply) ... repeat 1-2 for multiple agreements... 3. renegotiation initiator sends offer to agreement factory 4. agreement factory sends accept (sync or async reply) in step (3) the renegotiation offer includes a reference to the initial agreement(s) and the responder needs to validate that it makes sense, e.g. that the right parties are involved and that the terms would meaningfully supercede all of the referenced agreements. I would also disagree with your reversed roles being a 2-phase decision protocol. The fact that you have an extra round-trip to find the agreement EPR is an artifact of your rendering. Due to the nature of the obligation assumed by the offerer when he sent the offer, he doesn't have the right to refuse to give you the agreement when you decide to accept. Having this fail is no different than any other communication or implementation fault; it can happen in the real world, but it is clear that the contract is binding anyway if the responder got an offer and "sent an accept" based on the post-box rule mentioned in the renegotiation proposal paper. Apparently, you want to consider the original agreement responder as a "server side" component, so you don't feel complete until the original initiator holds an EPR to an agreement representing the renegotiation back on this "server side". Am I correct? A better rendering might eliminate this round-trip. What you could do is send a PendingAgreement EPR in the initial renegotiation offer, so the renegotiation responder already has an EPR before he decides to accept. This would also support the Accept message, so the responder could simply invoke that and be done with it. This same thing would apply in any symmettric peer-to-peer scenario as well, just as with the existing WS-Agreement mechanism. By maintaining Agreement and RenegotiatedAgreement resources "on both sides", we can see the decoupled state of the negotiations from each party's perspective. karl -- Karl Czajkowski Software Architect Univa UD 1001 Warrenville Road, Suite 550 Lisle, IL 60532 karlcz@univaud.com www.univa.com ________________________________________________________________ www.univa.com. The Leaders of Open Source Cluster and Grid Software The information contained in this e-mail message is from Univa UD and may be privileged, confidential, and protected from disclosure. If you are not the intended recipient, any further disclosure or use, dissemination, distribution, or copying of this message or any attachment is strictly prohibited. If you think that you have received this e-mail message in error, please delete the e-mail, and either e-mail the sender at the above address or notify us at our address.
Hi Again:
I wouldn't say slide 7 captures my comment. My endpoint rendering doesn't imply a third entity, just that the responder entity is rendered with multiple endpoints to allow a more general scenario such as renegotiation that could combine multiple agreements (something you couldn't do if the preceding agreement is always implied like the "this" pointer in a simple object system):
1. agreement initiator sends offer to agreement factory
2. agreement factory sends accept (sync or async reply)
... repeat 1-2 for multiple agreements...
3. renegotiation initiator sends offer to agreement factory
4. agreement factory sends accept (sync or async reply)
These are somethngs I can guess and feel provide an elegant solution, but I feel that the implicit messages needed here between the Agreement Responder and the Agreement Factory would needed to be spelt out or (My guess) would always, fail.. #Karl please tell me that I'm wrong... So for the moment, I personally feel that a more simple protocol either using PendingXXX would be better.. #Your thoughts everyone :-) Best Regards Toshi @ safely moved from freezing East Coast US to a warmer Silicon Valley ----- 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)
Hi Toshi & Karl, I am about to re-draw the slides of Toshi for inclusion in a document that presents the ideas of the three presentations given in the second and third GRAAP session. I will also try to re-draw slide 7 taking into account the discussion on the list and then sent it to the list again to see whether I understood Toshi, Karl and the ongoing discussion ;-) Best regards Wolfgang Toshiyuki Nakata schrieb/wrote:
Hi Again:
I wouldn't say slide 7 captures my comment. My endpoint rendering doesn't imply a third entity, just that the responder entity is rendered with multiple endpoints to allow a more general scenario such as renegotiation that could combine multiple agreements (something you couldn't do if the preceding agreement is always implied like the "this" pointer in a simple object system):
1. agreement initiator sends offer to agreement factory
2. agreement factory sends accept (sync or async reply)
... repeat 1-2 for multiple agreements...
3. renegotiation initiator sends offer to agreement factory
4. agreement factory sends accept (sync or async reply)
These are somethngs I can guess and feel provide an elegant solution, but I feel that the implicit messages needed here between the Agreement Responder and the Agreement Factory would needed to be spelt out or (My guess) would always, fail..
#Karl please tell me that I'm wrong...
So for the moment, I personally feel that a more simple protocol either using PendingXXX would be better..
#Your thoughts everyone :-) Best Regards Toshi @ safely moved from freezing East Coast US to a warmer Silicon Valley
----- 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)
-- graap-wg mailing list graap-wg@ogf.org http://www.ogf.org/mailman/listinfo/graap-wg
-- Wolfgang Ziegler www.scai.fraunhofer.de/ziegler.html Fraunhofer-Institute for Algorithms and Scientific Computing (SCAI) Schloss Birlinghoven, D-53754 Sankt Augustin, Germany Tel: +49 2241 14 2258; Fax: +49 2241 14 42258 CoreGRID Network of Excellence www.coregrid.net Collaboration Gateway www.coregrid.net/cg Institute on Resource Management and Scheduling www.coregrid.net/irms
HI:
I am about to re-draw the slides of Toshi for inclusion in a document that presents the ideas of the three presentations given in the second and third GRAAP session.
I think it should Interesting... 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)
On Mar 01, Toshiyuki Nakata modulated:
Hi Again:
I wouldn't say slide 7 captures my comment. My endpoint rendering doesn't imply a third entity, just that the responder entity is rendered with multiple endpoints to allow a more general scenario such as renegotiation that could combine multiple agreements (something you couldn't do if the preceding agreement is always implied like the "this" pointer in a simple object system):
1. agreement initiator sends offer to agreement factory
2. agreement factory sends accept (sync or async reply)
... repeat 1-2 for multiple agreements...
3. renegotiation initiator sends offer to agreement factory
4. agreement factory sends accept (sync or async reply)
These are somethngs I can guess and feel provide an elegant solution, but I feel that the implicit messages needed here between the Agreement Responder and the Agreement Factory would needed to be spelt out or (My guess) would always, fail..
What I'm trying to say is that there is no "implicit message"... the agreement factory is the agreement responder in this picture (for AI=MI in your terminology). It is one entity and we really should not say anything about the internal implementation structure. I should have labeled the "agreement factory" in steps (3) and (4) as "renegotiated agreement factory" since we really haven't stated whether these would be separate port types. But it was my intention that these factories be interfaces to the same responder entity for the AI=MI case. For the case where AI=MR, it gets more complicated just as the basic existing WS-Agreement is more complicated when you put agreement resources on both sides: 1. Agreement initiator sends offer to agreement responder's factory. (with embedded PendingAgreement EPR in offer, representing initiator's view of the offered agreement, also combining the AgreementAcceptance port type) 2. Agreement responder sends accept (sync factory response or async Accept response) 3. Eventually initiator's agreement state progresses to Observed when he learns of acceptance (this is the decoupled distributed state transition we've discussed before) everything above is possible in the existing WS-Agreement protocol. ...discovery magic happens... 4. Agreement responder, acting as renegotiation initiator, sends renegotiate offer to agreement initiator's renegotiation factory. (with embedded PendingRenegotiatedAgreement EPR in offer, representing renegotiation inititator's view of the offered renegotiated agreement) 5. Agreement initiator, acting as renegotiation responder, sends accept (sync factory response or as async Accept response) 6. Eventually agreement responder's renegotiatedion agreement state progresses to Observed when he learns of acceptance (this again is the decoupled distributed state transition) Several notes: A. The magic discovery is there because the renegotiation initiator has to determine the appropriate renegotiated agreement factory EPR from the existing agreement information. I didn't want to attempt to address that technical issue here, but just assume it is dealt with somehow. B. This symmetric arrangement established in (1)-(3) would support either AI=MI or AI=MR scenarios, since both parties would have discovered renegotiation endpoints for the other party. The simpler, asymmetric client-server arrangement of the previos email only supports AI=MI since there are no factory service endpoints on the agreement initiator side in that case. C. With the right message schemas, one polymlorphic factory type could serve both initial and renegotiated agreement requests, so there would only need to be two factories (one per party) instead of the four logically separated roles above. D. A somewhat hairy naming issue exists. Do we really want to create new Agreement resources and EPRs for each renegotiation, or is it better to treat the resource like an "envelope" and use some internal GUID-like name to name specific versions of agreement? (In this case, the agreement resource would hold info for the first, superceded, agreement and then the revised agreement, with stable addressing. I'm not sure which approach is better, but I seem to recall there being a versioning/naming mechanism inside the WS-Agreement schema already. I have a bad network connection today and cannot easily retrieve the current specification to verify this... apologies if I'm remembering something that got dropped during the standardization process.) karl -- Karl Czajkowski Software Architect Univa UD 1001 Warrenville Road, Suite 550 Lisle, IL 60532 karlcz@univaud.com www.univa.com ________________________________________________________________ www.univa.com. The Leaders of Open Source Cluster and Grid Software The information contained in this e-mail message is from Univa UD and may be privileged, confidential, and protected from disclosure. If you are not the intended recipient, any further disclosure or use, dissemination, distribution, or copying of this message or any attachment is strictly prohibited. If you think that you have received this e-mail message in error, please delete the e-mail, and either e-mail the sender at the above address or notify us at our address.
HI Again:
What I'm trying to say is that there is no "implicit message"... the agreement factory is the agreement responder in this picture (for AI=MI in your terminology). It is one entity and we really should not say anything about the internal implementation structure.
I totally agree..
I should have labeled the "agreement factory" in steps (3) and (4) as "renegotiated agreement factory" since we really haven't stated whether these would be separate port types. But it was my intention that these factories be interfaces to the same responder entity for the AI=MI case.
I am worried about this ""renegotiated agreement factory" with the role of the original agreement factory . Can they be completely differnent? 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: Karl Czajkowski [mailto:karlcz@univaud.com] Sent: Saturday, March 01, 2008 3:09 PM To: Toshiyuki Nakata Cc: graap-wg@gridforum.org Subject: Re: [GRAAP-WG] Re-negotiation Protocol Proposal
On Mar 01, Toshiyuki Nakata modulated:
Hi Again:
I wouldn't say slide 7 captures my comment. My endpoint rendering doesn't imply a third entity, just that the responder entity is rendered with multiple endpoints to allow a more general scenario such as renegotiation that could combine multiple agreements (something you couldn't do if the preceding agreement is always implied like the "this" pointer in a simple object system):
1. agreement initiator sends offer to agreement factory
2. agreement factory sends accept (sync or async reply)
... repeat 1-2 for multiple agreements...
3. renegotiation initiator sends offer to agreement factory
4. agreement factory sends accept (sync or async reply)
These are somethngs I can guess and feel provide an elegant solution, but I feel that the implicit messages needed here between the Agreement Responder and the Agreement Factory would needed to be spelt out or (My guess) would always, fail..
What I'm trying to say is that there is no "implicit message"... the agreement factory is the agreement responder in this picture (for AI=MI in your terminology). It is one entity and we really should not say anything about the internal implementation structure.
I should have labeled the "agreement factory" in steps (3) and (4) as "renegotiated agreement factory" since we really haven't stated whether these would be separate port types. But it was my intention that these factories be interfaces to the same responder entity for the AI=MI case.
For the case where AI=MR, it gets more complicated just as the basic existing WS-Agreement is more complicated when you put agreement resources on both sides:
1. Agreement initiator sends offer to agreement responder's factory.
(with embedded PendingAgreement EPR in offer, representing initiator's view of the offered agreement, also combining the AgreementAcceptance port type)
2. Agreement responder sends accept (sync factory response or async Accept response)
3. Eventually initiator's agreement state progresses to Observed when he learns of acceptance (this is the decoupled distributed state transition we've discussed before)
everything above is possible in the existing WS-Agreement protocol.
...discovery magic happens...
4. Agreement responder, acting as renegotiation initiator, sends renegotiate offer to agreement initiator's renegotiation factory.
(with embedded PendingRenegotiatedAgreement EPR in offer, representing renegotiation inititator's view of the offered renegotiated agreement)
5. Agreement initiator, acting as renegotiation responder, sends accept (sync factory response or as async Accept response)
6. Eventually agreement responder's renegotiatedion agreement state progresses to Observed when he learns of acceptance (this again is the decoupled distributed state transition)
Several notes:
A. The magic discovery is there because the renegotiation initiator has to determine the appropriate renegotiated agreement factory EPR from the existing agreement information. I didn't want to attempt to address that technical issue here, but just assume it is dealt with somehow.
B. This symmetric arrangement established in (1)-(3) would support either AI=MI or AI=MR scenarios, since both parties would have discovered renegotiation endpoints for the other party. The simpler, asymmetric client-server arrangement of the previos email only supports AI=MI since there are no factory service endpoints on the agreement initiator side in that case.
C. With the right message schemas, one polymlorphic factory type could serve both initial and renegotiated agreement requests, so there would only need to be two factories (one per party) instead of the four logically separated roles above.
D. A somewhat hairy naming issue exists. Do we really want to create new Agreement resources and EPRs for each renegotiation, or is it better to treat the resource like an "envelope" and use some internal GUID-like name to name specific versions of agreement? (In this case, the agreement resource would hold info for the first, superceded, agreement and then the revised agreement, with stable addressing. I'm not sure which approach is better, but I seem to recall there being a versioning/naming mechanism inside the WS-Agreement schema already. I have a bad network connection today and cannot easily retrieve the current specification to verify this... apologies if I'm remembering something that got dropped during the standardization process.)
karl
-- Karl Czajkowski Software Architect
Univa UD 1001 Warrenville Road, Suite 550 Lisle, IL 60532
karlcz@univaud.com www.univa.com ________________________________________________________________ www.univa.com.
The Leaders of Open Source Cluster and Grid Software
The information contained in this e-mail message is from Univa UD and may be privileged, confidential, and protected from disclosure. If you are not the intended recipient, any further disclosure or use, dissemination, distribution, or copying of this message or any attachment is strictly prohibited. If you think that you have received this e-mail message in error, please delete the e-mail, and either e-mail the sender at the above address or notify us at our address.
participants (3)
-
Karl Czajkowski -
Toshiyuki Nakata -
Wolfgang Ziegler