From karlcz at univaud.com Sat Mar 1 00:08:33 2008 From: karlcz at univaud.com (Karl Czajkowski) Date: Sat, 1 Mar 2008 13:08:33 +0700 Subject: [GRAAP-WG] Re-negotiation Protocol Proposal In-Reply-To: <002901c87b2c$f841d2e0$b084380a@Sakurai> References: <20080216053555.GC3569@granite.bbswl> <000701c87a6d$78d30b60$b084380a@Sakurai> <20080229081611.GC21529@crater.lan> <20080229103504.GC4937@crater.lan> <002901c87b2c$f841d2e0$b084380a@Sakurai> Message-ID: <20080301060833.GB26330@granite.bbswl> 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 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. From t-nakata at cw.jp.nec.com Sat Mar 1 05:08:19 2008 From: t-nakata at cw.jp.nec.com (Toshiyuki Nakata) Date: Sat, 1 Mar 2008 20:08:19 +0900 Subject: [GRAAP-WG] Re-negotiation Protocol Proposal In-Reply-To: <20080301060833.GB26330@granite.bbswl> References: <20080216053555.GC3569@granite.bbswl> <000701c87a6d$78d30b60$b084380a@Sakurai> <20080229081611.GC21529@crater.lan> <20080229103504.GC4937@crater.lan> <002901c87b2c$f841d2e0$b084380a@Sakurai> <20080301060833.GB26330@granite.bbswl> Message-ID: <000001c87b8c$8e8d9360$b084380a@Sakurai> 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 at univaud.com] > Sent: Saturday, March 01, 2008 3:09 PM > To: Toshiyuki Nakata > Cc: graap-wg at 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 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. From karlcz at univaud.com Sun Mar 2 02:22:29 2008 From: karlcz at univaud.com (Karl Czajkowski) Date: Sun, 2 Mar 2008 15:22:29 +0700 Subject: [GRAAP-WG] FW: Re-negotiation Protocol Proposal In-Reply-To: <001a01c87b25$acc028a0$b084380a@Sakurai> References: <001a01c87b25$acc028a0$b084380a@Sakurai> Message-ID: <20080302082229.GD26330@granite.bbswl> 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 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. From Wolfgang.Ziegler at scai.fraunhofer.de Tue Mar 4 10:44:07 2008 From: Wolfgang.Ziegler at scai.fraunhofer.de (Wolfgang Ziegler) Date: Tue, 04 Mar 2008 17:44:07 +0100 Subject: [GRAAP-WG] FW: Re-negotiation Protocol Proposal In-Reply-To: <20080302082229.GD26330@granite.bbswl> References: <001a01c87b25$acc028a0$b084380a@Sakurai> <20080302082229.GD26330@granite.bbswl> Message-ID: <47CD7C57.10604@scai.fraunhofer.de> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: Negotiation_AR=MI.png Type: image/png Size: 49966 bytes Desc: not available Url : http://www.ogf.org/pipermail/graap-wg/attachments/20080304/c1c119a8/attachment.png -------------- next part -------------- A non-text attachment was scrubbed... Name: Negotiation_AI=MI.png Type: image/png Size: 38986 bytes Desc: not available Url : http://www.ogf.org/pipermail/graap-wg/attachments/20080304/c1c119a8/attachment-0001.png -------------- next part -------------- A non-text attachment was scrubbed... Name: Negotiation_AR=MI_2PC.png Type: image/png Size: 40629 bytes Desc: not available Url : http://www.ogf.org/pipermail/graap-wg/attachments/20080304/c1c119a8/attachment-0002.png -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2093 bytes Desc: S/MIME Cryptographic Signature Url : http://www.ogf.org/pipermail/graap-wg/attachments/20080304/c1c119a8/attachment.bin