On 16 Feb 2008, at 06:35, Karl Czajkowski wrote:
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).
Yes, we do assume that a contract is formed between the provider and the customer for some exchange, but what that contract is for and what is exchanged is, like contract law, outside the scope of the protocol.
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.
However, I believe that the entire notion of "provider" and
"consumer" in inherently domain-specific, and therefore inseparable
from the service term language.
We believe the opposite is true: providers or customers can supply and consume anything, and these roles are inherently domain-independent. In short, the messages and the content of those messages (or "service term language") are separable and have to be in order for the protocol to be used across different domains, like the protocol inherent in contract law is.
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.
a) About "the existing context fields". Can you explain what you mean by this as we don't use this phrase in our paper. Do you mean the protocol roles?
b) You're right - the protocol cannot and does not say anything about the roles of supplier and customer apart from that they are suppliers and customers of something.
c) If you think domain-specific concepts are necessary to characterise these roles, can you give us some examples where you feel this would help?
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.
I'm sorry, I don't understand the argument here. Please can you clarify.
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.
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?
This is jumping ahead to considering how this can be mapped onto a WS (particularly WSRF) implementation. Our first step is to define and agree on the abstract protocol, then provide a mapping to WS (and other stacks), though, as stated above, we will give an example implementation in a following paper. This is why we give an explanation of the protocol behaviour and not interface definitions, although we included some explanation of how it could be mapped to WS-Agreement because of the audience the proposal was intended for. As I'm sure you're aware, not detailing implementation is common in protocols - for example, see Lamport's description of the Paxos algorithm [1] that doesn't talk at all about actual implementation.
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;
Again, these are considerations for an implementation.
However, in the abstract protocol there is nothing to stop the provider sending the RenegotiationOfferAck with the Accept or Reject message. We make the distinction because there may be cases when there will be a delay between the provider sending the acknowledgement and deciding whether it can accept or reject the offer. (Note that his is how Amazon works, they send an email acknowledgement initially but then accept your offer and form the contract when they tell you they're shipping your goods).
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?
Of course, but see the above answers above about not wanting to tie this to any implementation at the moment.
</snip>
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?
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.
b) Yes, this is because in contract law the offeree (the service provider) always gets the final say.
</snip>
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?
You're right in that RenegotiationNotPossible is a type of advisory message. But, if sent in response to an offer it has the same effect as a Reject message. Re-reading the proposal we agree that this is not captured well and will update the document accordingly.