FW: Re-negotiation Protocol Proposal
Hi Karl:
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?
I would not say that the agreement responder would be on the "Server" side. I had just assumed that the agreement factory would be on the Agreement responder side.
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.
WOuld this be same for both the cases of MI=AI and MI=AR? We were discussing in the group about the appplicability of having a modified EPR for MI=AR case... 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: Friday, February 29, 2008 5:16 PM To: Toshiyuki Nakata Subject: Re: [GRAAP-WG] Re-negotiation Protocol Proposal
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.
On Mar 01, Toshiyuki Nakata modulated: ...
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.
WOuld this be same for both the cases of MI=AI and MI=AR?
Yes, this symmetric rendering is general. The asymmetric client-server case is just a subset where the "optional" initiator-provided Agreement EPR is absent, so no endpoint is known for initiating new web service requests towards the agreement initiator. As such, this purely client-server subset is not suitable for MI=AR, unless you want to use some more passive means of deliverying offers, e.g. via resource properties or notification, but it is perhaps simpler for basic MI=AI cases.
We were discussing in the group about the appplicability of having a modified EPR for MI=AR case...
For the symmetric case, it is important to understand that there are already TWO EPRs for the underlying agreement. Each party presents a web resource representing his own view of the agreement. The symmetry was made optional because people wanted WS-Agreement to be usable in purely client-server environments, even if it lacked some of the general capability. Conceptually, the initiator's pending agreement always exists when he makes an offer, but the specification allows him to omit the EPR for this implied pending agreement if he doesn't care to support symmetric message patterns. So, renegotiation would generate two more EPRs when it is done. The initiator can provide an EPR to the pending offer and the responder has to produce an EPR if he accepts (or if he may accept in the async case). These two renegotiation EPRs represent each party's view of the distributed decision process that supercedes the agreement represented in the original two agreement EPRs. In the symmetric case, there is probably a desire to use another name space for the agreements so that both parties' agreement resources can be easily correlated by seeing that they share the same agreement ID, despite having separate agreement EPRs. This is an existing issue regardless of whether you intend to do renegotiation. 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 all, based on Toshi's slides and the discussion I prepared three pngs with the scenarios I see: AI = MI AR = MI (rendered with the pending agreement as proposed by Karl) AR = MI ( 2PC as proposed by Toshi) Anything else we should consider? Best regards Wolfgang Karl Czajkowski schrieb/wrote:
On Mar 01, Toshiyuki Nakata modulated: ...
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.
WOuld this be same for both the cases of MI=AI and MI=AR?
Yes, this symmetric rendering is general. The asymmetric client-server case is just a subset where the "optional" initiator-provided Agreement EPR is absent, so no endpoint is known for initiating new web service requests towards the agreement initiator. As such, this purely client-server subset is not suitable for MI=AR, unless you want to use some more passive means of deliverying offers, e.g. via resource properties or notification, but it is perhaps simpler for basic MI=AI cases.
We were discussing in the group about the appplicability of having a modified EPR for MI=AR case...
For the symmetric case, it is important to understand that there are already TWO EPRs for the underlying agreement. Each party presents a web resource representing his own view of the agreement. The symmetry was made optional because people wanted WS-Agreement to be usable in purely client-server environments, even if it lacked some of the general capability. Conceptually, the initiator's pending agreement always exists when he makes an offer, but the specification allows him to omit the EPR for this implied pending agreement if he doesn't care to support symmetric message patterns.
So, renegotiation would generate two more EPRs when it is done. The initiator can provide an EPR to the pending offer and the responder has to produce an EPR if he accepts (or if he may accept in the async case). These two renegotiation EPRs represent each party's view of the distributed decision process that supercedes the agreement represented in the original two agreement EPRs.
In the symmetric case, there is probably a desire to use another name space for the agreements so that both parties' agreement resources can be easily correlated by seeing that they share the same agreement ID, despite having separate agreement EPRs. This is an existing issue regardless of whether you intend to do renegotiation.
karl
-- 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
participants (3)
-
Karl Czajkowski -
Toshiyuki Nakata -
Wolfgang Ziegler