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

[Karl Czajkowski]

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.