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

[Wolfgang Ziegler]

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