[GRAAP-WG] Re-negotiation Protocol Proposal

Sat Mar 1 05:08:19 CST 2008

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.