[GRAAP-WG] FW: Re-negotiation Protocol Proposal

[Toshiyuki Nakata]

 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 at 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 at 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.