Hi Karl, Thanks for taking the time to read our paper. On Aug 27 2007, Karl Czajkowski wrote:
Michael, I just read "Challenges in EU Grid Contracts" for the first time after seeing it linked from Toshi's wiki page updates. I thought it might be useful to address several topics in the paper regarding WS-Agreement, though I have a suspicion that some of these issues may have been addressed long ago by others...
Maybe they have been addressed long ago, but they aren't clear (to me anyway) from the spec and as someone who wasn't involved in the specification process.
1. There is an assertion that WS-Agreement does not support acknowledgement of receipt of an offer independent of the acceptance decision. This is incorrect, as the PendingAgreement construct is specifically defined for this purpose: the CreatePendingAgreement factory pattern returns an EPR to a PendingAgreement which is yet to be accepted or rejected.
This feature was motivated by a different observation that a decision process might be too slow to perform during a SOAP-over-HTTP in/out message, but it equally addresses your concern of knowing that the offer was received before the decision process is complete. (A WS-* purist position could be that message acknowledgement is a transport-level problem rather than a SOAP problem, but we had to bow to the practical use of SOAP-over-HTTP...)
Yes, I agree. The pending state (though personally I think 'received offer' is clearer) can be used to run tasks scheduling algorithms, for instance, like our paper says. However, I don't think a message acknowledgement (in its most general sense) is "a transport-level problem" (I'm not sure if you were agreeing or disagreeing to this point and what your reference to SOAP/HTTP means - it isn't clear). For example, how do I know that a service didn't crash between the transport-level message being accepted and the application processing it? Therefore in this scenario the application-level - not the network-level - must acknowledge message receipt (when acknowledgements are used).
2. There is an allowance for external acceptance notification channels, though I admit this is not emphasized in the text. Present in the base protocol are the Acceptance port type and the agreement state resource property, both of which may be used simultaneously on the same agreement. It is the state model which allows for transitions to accepted state independent of the other protocol operations. There is nothing to disallow other notification paths such as email, facsimile, registered mail, etc. (but, see next issue).
3. A significant difference between WS-Agreement and the contract law model described in the paper is the moment of acceptance: in WS-Agreement, acceptance is defined as the moment the responder chooses to accept, and is not dependent on sending an acceptance message to the initiator. This difference becomes clear in unusual asynchronous/lossy message environments and/or contested agreements.
Yes, and since the publication of this paper we have learnt that this model of acceptance is also valid in contract law. It is called the 'mailbox rule' and (in a nutshell) says that as soon as the offeree 'posts' their acceptance the contract is made. Though it must be stated in advance that this is being used and not the traditional method we described in our paper. The protocol we are writing up uses the 'mailbox rule' model because (if the offeree was the service provider) it leads to the resources the contract is being made for being 'locked' - which I think we agree is an unacceptable situation - until the service provider knows the accept message has been received.
This is a crucial technical point in WS-Agreement. In order to define the acceptance moment as when the acceptance is delivered to the initiator (as in your contract law discussion) would require a reliable delivery model where some trustworthy (third-party) observer can witness the delivery.
No, not necessarily. Note that business (generally) operates quite well without third-parties and often uses unreliable messaging to form contracts. There is also a well-known example (in legal circles, anyway) used to illustrate the loss of acceptance messages where the mailbox rule is not being applied, i.e. when acceptance is delivered to the offeror. It does not require a "reliable delivery model" or "a trustworthy observer" to be in place. The legal example, using the more correct terminology of 'offeror' and 'offeree' in place of initiator and responder, is as follows and should be understandable when applied to a distributed computing environment. The offeree shouts an acceptance message to the offeror. Just the offeree does so a plane passes overhead and the offeror does not hear the acceptance message (i.e. it is lost). The legal position is that it is upto the sender of the message to make sure the acceptance message gets through. Thus, the offeree keeps sending the message until they know it is understood. But, as you point out below, the offeror may choose to ignore (or claim not to receive) the accept message. However, because of the semantics of an offer, the offeror is bound to its contents if accepted so there is also an responsibility on the offeror to make sure they know the status of any offer that they make (and not make offers they do not intend to fulfil). The semantics of the message are critical in this protocol - hence my question to Dominic in my original email about the meaning of his 'offer' message. There are also other rules in contract law that help deal with this situation. The meaning of an offer (along with the experience gained over many years of forming contracts in distributed environments gathered by the legal community) makes the protocol inherent in contract law 'work': once an offer is made the offeror cannot walk away or choose not to take part if the offeree accepts that offer - even if they don't get the accept message. An offer is binding, unless it has been revoked. Therefore the offeror should always want to receive the accept so they can plan/reserve funds/do whatever they need to do - even if it is to ask that the contract is terminated immediately - as part of their side of the contract. If they don't then they will be at risk of breaking the contract and liable to the penalties therein.
At risk of confusing the terminology, a way to characterize such a variant of our protocol might be:
1. initiator sends offer to responder.
2. responder chooses to accept.
3. responder attempts to send acceptance notice.
4. reliable message channel observes delivery of (3) and acceptance is now true.
Given our presumption of an Internet-like environment without any secure, third-party channel to "serve" notices, this does nothing more than "rotate" the participant roles by one unidirectional message. In effect, it is really the "initiator" in step (4) who decides acceptance by choosing to receive the acceptance notice or not, because it is not possible to prove that he received a message unless he acknowledges it!
I agree, this is why we use the 'mail box' rule as otherwise we get into evidential issues about how many times the accept was attempted to be delivered, etc. But the offeror is still contracted whether they like it or not.
Thus, his offer is not really obligating, as he can shirk his responsibilities by choosing not to acknowledge the acceptance.
About "his offer is not really obligating". How so? An offer is binding/obligating once made (again, unless revoked) therefore by "shirking their responsibilities" they may be breaking the contract and open to recourse. If it's not an offer then the offeree cannot accept it. The message must be an offer/not be an offer. It can't be a non-obligating offer, in that case it would be something else.
Thus, I would say the above "contract law"-style sequence of:
offer/accept/receipt-as-decision
is indistinguishable in practice from:
invite/offer/accept-as-decision
As there must be some party in the system that first knows the decision before this information is distributed asynchronously to all parties, we make the responder be the observer!
Yes, contract law has an inherent bias towards the offeree who knows the decision first and is what (I think) you're saying. In a distributed system there will always be a lack of consistency somewhere (unless you sacrifice availability). A side question: what do you mean by "this information is distributed asynchronously to all parties". I thought WS-Agreement was 1:1 and the acceptance by the offeree only had to se sent (or made available) to the offeror? (i.e. one party). What "other parties" do you mean?
Finally, as I described it in a previous email. WS-Agreement supports this through the slightly more general:
advertise/offer/accept-as-decision
where you could restrict or otherwise optimize access to advertisements in order to effect a directed invitation. (It is considered somewhat out of scope for WS-Agreement to define how advertisements are retrieved, e.g. what sort of publishing or information dispersal architecture is used for discovery.)
I hope this helps clarify the technical solution embodied in WS-Agreement.
Thanks for taking the time to privide these clarifications. However they don't address the other question of the resource provider having to 'lock' it's resources in a 2PC-style when it makes an offer, as was also discussed (and a solution proposed) in our paper. Thanks again, Michael.