[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@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. ---------------------------------------------------------------------