[GRAAP-WG] Re-negotiation Protocol Proposal

[Karl Czajkowski]

[Apologies for the delay, I've been away from the office...]


On Feb 18, Michael Parkin modulated:

> We are not claiming that the responder in the re-negotiation protocol
> should always be the service provider. This is because the service
> provider can send quote messages to the customer to initiate
> re-negotiation. As described in the paper, we can map the service
> provider onto the WS-Agreement "responder" role and we provided this
> example because of the audience the proposal was intended for, but
> these two roles are different.
> 

OK, I think I missed your distinction between "renegotiation
responder" and "WS-Agreement responder" on my initial reading. So, if
you are saying each round of renegotiation can be offered by either
party of the existing agreement, I think I could accept this
flexibility... it is more general than I had expected.

As for the other topic of labeling roles, I think we are actually
saying the same thing and just having a terminology clash.  My
perspective is perhaps best illustrated by this example:

  -  Consider an agreement domain where agreements represent the
     execution of compute jobs.

  -  Traditionally HPC practitioners would say that the the party
     defining a job to run is "consuming computer time" and the the
     compute resource operating party is "providing computer time".
     Because of this, most people would agree also with having the
     job-defining party be the initiator (offerer) in the agreement
     process.

  -  In a multi-level brokering extension to this environment,
     multiple compute resource operating parties might be fighting for
     the same jobs and it makes sense to think of a broker/reseller as
     "providing jobs" and a compute resource operator as "consuming
     jobs".  In this environment, the resource operators may need to
     be the agreement initiators (offerers) because it is better to
     "waste" some of their time on offered-but-not-committed
     agreements rather than to let the (scarce) jobs in the broker get
     live-locked.

Where I keep getting stuck in terminology is that the agreement
protocol roles of initiator and responder do not always map to the
same operational roles in these job execution scenarios. There are
always the same two domain-specific operational roles of "job defining
party" and "job executing party", but they associate with different
signalling roles.  Consistent (I think) with your earlier statements
about avoiding resource waste, the negotiation protocol roles should
be associated with an abstract sense of who is providing the scarce or
less fungible resource/service.  But, to identify who is providing
this resource would require reference to domain-specific roles, since
it is not a static property of all job agreements.

So, in my view we should have two "party-to-role" mappings to
specify:

   1. Which signaling party serves each agreement role

   2. Which domain-specific party serves each service providing role

I don't think either of these can be implied via the other.  I also
don't think the situation differs for the first agreement versus the
re-negotiated agreement.  It is my belief that (1) should be addressed
in the negotiation protocol message envelope, while (2) should be left
completely to the domain-specific service language.  I think we made
mistakes previously in attempting to encode (2) in the WS-Agreement
envelope.

I'm still struggling to feel confident that I understand your
statements in this area with respect to contract law, etc.  How would
contract law look upon my brokering scenario, where a reversal of the
offer/accept signalling roles is desired?


> 
>     2. Has any thought been given to the concrete rendering of this
>       protocol?  I immediately have the following ideas upon reading
>     the
>       message definitions:
> 
> 
> By "rendering" do you mean implementation? If so, then yes we have a
> proof-of-concept implementation. As we wrote in the proposal, we're
> currently producing a paper on this which will also be circulated to
> the group.
> 

By rendering I mean concrete protocol designs which would be the
subject of standardization, e.g. XML/SOAP "bytes on the wire".
Implementation would be various software providers writing software
which complies with this standard.

I'll be surprised if there is much (any?) working group debate of the
abstract offer/accept renegotiation protocol, as it seems quite
natural, simple, and general to me.  But, where we've seen most of the
debates previously has been in how these abstract concepts appear in
actual concrete message schema...


> a) About "the responding party (who chooses to accept)": the service
> provider (who always chooses to accept an offer) may be the initiator
> of the re-negotiation as we described above.
> 

Sorry for the confusion of terms again. Every time I've said
"initiator" I meant "offerer" in your terms I think.  I meant
WS-Agreement "Initiator" who performs the first step of the
offer/accept exchange.


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.

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

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.


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