[GRAAP-WG] Re-negotiation Protocol Proposal

[Karl Czajkowski]

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.