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(a)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.
[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(a)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.
