[GRAAP-WG] Re-negotiation Protocol Proposal

[Karl Czajkowski]

[Sorry, this bounced the first time I tried to send to the list...]


In general I like the approach described in this proposal very
much. Since I won't be attending the meeting, I wanted to give a
little feedback here...

1. I am not sure I would agree with the claim that the responder role
   should _always_ be assigned to the "service provider", because the
   authors' arguments about avoiding denial of service only make sense
   if you assume service resource scarcity relative to consumer
   resource availability (assuming that an agreement is always a
   "trade" or contract of exchange between these two resource types).

   However, I believe that the entire notion of "provider" and
   "consumer" in inherently domain-specific, and therefore inseparable
   from the service term language.  So, I might advocate that the
   existing context fields to associate provider/consumer roles with
   initiator/responder be dropped, but only because I don't think the
   core messaging pattern can really say anything about these roles to
   begin with.  I think domain-specific concepts are necessary to
   really characterize these roles.

   Thus, I don't think there can be any normative statements in the
   standard for base agreement nor re-negotiation regarding the use of
   responder roles with providers or consumers. But, I think it would
   be fine to have some explanatory text about the various risks of
   reversing the signalling roles from the "natural" and asymmetric
   order that would exist in many domains.

2. Has any thought been given to the concrete rendering of this
   protocol?  I immediately have the following ideas upon reading the
   message definitions:

   a. RenegotiationQuoteRequest and RenegotiationQuote could be easily
      mapped to resource property queries with a custom "quote query
      dialect".  This was an expected use of extensibility in WSRF in
      the past, but I do not know how people view this today. The
      alternative, of course, is a new operation.  Is there any
      concern about preparation of quotes being a slow or laborious
      process, and requiring an asynchronous exchange pattern or a
      resource pattern to allow cancellation of quote requests?

   b. RenegotationOffer and RenegotiationAccept/RenegotiationReject
      map easily to the two alternate rendering styles in WS-Agreement:

      CreateRenegotiatedAgreement (in) and response (out) for
      synchronous exchanges, in this case merging
      RenegotiationOfferAck with the accept or reject response;

      CreatePendingRenegotiatedAgreement (in) and
      AcceptAgreement/RejectAgreement (also in messages in opposite
      direction) for asynchronous exchanges, in this case mapping
      RenegotiationOfferAck to the factory response with the new
      pending renegotiated agreement;

   c. RenegotiationNotPossible could be a fault response as described
      and could also be exposed as a resource property on some
      agreements? 

   In these renegotiation "factory" patterns, one approach would be to
   have the renegotiable Agreement resource support these additional
   patterns, i.e. to act as a factory for its superceding
   agreement. Or, a shared factory could take the existing agreement
   EPR as an input parameter.

3. I am assuming from my initial reading that the statement that
   acceptance of a renegotiation offer invalidates all other
   outstanding offers is also a point where loose consistency is
   desired.  In other words, it is the responding party (who chooses
   to accept) who also decides which offers are outstanding and which
   he hasn't seen yet, in the case that offers are "in flight" and
   acknowledgements have not been sent.  Is this the intention of the
   authors?  If not, then I think some sort of sequence numbering is
   necessary on offers to help resolve these cases for message loss or
   delay.

4. I am not sure I follow the purpose of the RenegotiationNotPossible
   message.  Is this a new terminal sub-state for Agreements?  Or, can
   an agreement have this non-renegotiable status at one time but then
   later be re-negotiable?  If the latter, I am not sure the meaning
   is well captured in the current discussion.  It sounds like two
   different messages: one has the same meaning as a reject message in
   response to an offer, but with an added hint that other offers will
   also be rejected, i.e. a transient "don't waste my time right now"
   message; the other form sounds like just the "don't waste my time
   right now" advisory without being coupled with a specific offer
   rejection.  Can the authors clarify the intent here?

In any case, I am looking forward to seeing more concrete rendering
proposals for this protocol extension.


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

---------------------------------------------------------------------

Notice from Univa UD Postmaster:


This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. This message has been content scanned by the Univa UD Tumbleweed MailGate.


---------------------------------------------------------------------