[GRAAP-WG] Modification to the wiki Page on Renegotiating anestablished Agreement

[Karl Czajkowski]

Toshi, I have the following comments/observations after reviewing your
wiki page... sorry I have not been able to keep a close watch on the
recent activities of the group.

1. The idea of negotiation of alternatives is difficult and I think
   requires a better negotiation protocol.

   After much debate, as I recall, we limited WS-Agreement to simple
   acceptance of an offer.  If the offer has alternatives in it, then
   the responder is accepting to satisfy this compound expression in
   any way he sees fit, with no information about how, or indeed
   whether his solution might vary over time and be satisfied by
   different clauses in the compound rules!  It would take
   domain-specific interpretation of the SDTs to somehow fix this
   solution, as there is nothing in the protocol to communicate a
   "lowering" or simplification of the alternatives expression.  (For
   example, I anticipated that in a basic use of JSDL for a job term,
   the interpretation could be defined that the service terms are
   chosen at job-start time and frozen, as is a typical implementation
   requirement for HPC resources... you would know they are not
   time-varying, though there is still no facility to communicate
   which exact parameters were chosen.)

   What I would suggest is that you try to keep this aspect of
   negotiation protocol orthogonal to the underlying notion of
   renegotiation.  First, work on the semantics for renegotiation of
   an agreement as you have done, e.g. replacement/superceding of an
   agreement.  Then, admit that basic or advanced protocols could be
   used to negotiate either the initial or subsequent agreement.

   For example, a relatively simple renegotiation could adapt the
   existing factory pattern for both initial and subsequent
   negotiations.  If a future specification provides a multi-round
   negotiation to lower/simplify abstract agreement constraints to a
   more concrete solution, this could replace the basic factory
   pattern in both cases too.


2. I think the idea of superceding an agreement is fine, but I have
   trouble seeing a distinction between this and the general use of
   agreements in the context of other agreements.  For example, the
   advance reservation scenario allows "claiming" of a resource
   reservation, and you can interpret this as adjusting an initial
   resource agreement to include binding to an application, with the
   same results as if someone simply negotiated an application with
   the same QoS terms in one shot...

   What I would point out is that this claiming/context model allows
   many:many derivation of agreements in the general case.  E.g. I
   could reserve a large resource (in space-time) and consume it with
   multiple applications which either run serially or in parallel.  I
   could also combine several resources (in separate agreements) into
   a complex application.  Couldn't a renegotiation also be temporary,
   e.g. "boost this resource reservation for the next hour, but then
   fall back to the previous terms"?

   I am not sure how "supercededby" would be applicable here.  Is it
   worth having one more general metalanguage for discovery/navigation
   of agreements which are linked to other agreements?  We could use
   the extensibility of the wsag:Context to enumerate the actual
   claimed or superseded agreements, and it seems useful to have a
   dynamic resource property which could provide reverse-lookup of new
   agreements which list an agreement in the new wsag:Context too.


3. Also, a general concern I have is that the discussions are not
   crisp about the uses of the agreement.  The talk of race conditions
   makes me nervous, as it seems to combine denotation of service
   terms with the implementation of resource managers.  In my view,
   WS-Agreement is completely focused on the establishment of terms
   between the two parties, and says nothing about how one of the
   parties is implementing the protocol.  I do not see a necessary
   race condition for "supercededby" because I don't think the
   initiator (for example) needs to be aware of this state change in
   order to meaningfully express a claim against an agreement.  If an
   agreement is renegotiated, it could still be usable for claiming by
   name, while the actual resource manager has to take into account
   that there are now aliases to the newly revised delivery terms...


4. The question of having "responder initiated renegotiation" was
   foreseen in the optional symmetric protocol mode. In essence, if
   EPRs are exchanged so that both parties have an EPR representing
   the other party's view of the agreement, then they can switch roles
   and become initiator for further rounds of communication.  In order
   to use this feature, one would need to define an extension to the
   protocol, e.g. have the symmetric agreement resources support an
   extended protocol which includes the renegotiation operations as
   well as the basic monitoring/cancellation operations.

   I think it would be appropriate to define a new negotiation
   protocol as a profile on this feature, so that a specific SDT would
   demand the presence of a renegotiation facility which would then be
   available as extended operations and resource properties on the
   Agreement resource.

   Again, if we consider the fuzzy case of many:many renegotiations,
   the best approach might be a simple RP in the agreement that holds
   an EPR to the renegotiation service, thereby separating discovery
   (via lookup of this RP an existing agreement) from claiming/context
   references which might involve more than one agreement at a time.


karl


-- 
Karl Czajkowski
Software Architect

Univa Corporation
1001 Warrenville Road, Suite 550
Lisle, IL 60532

karlcz at univa.com
www.univa.com
________________________________________________________________
www.univa.com.

The Leaders of Open Source Cluster and Grid Software