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... 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...) 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. 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. 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! Thus, his offer is not really obligating, as he can shirk his responsibilities by choosing not to acknowledge the acceptance. 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! 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. karl -- Karl Czajkowski Software Architect Univa Corporation 1001 Warrenville Road, Suite 550 Lisle, IL 60532 karlcz@univa.com www.univa.com ________________________________________________________________ www.univa.com. The Leaders of Open Source Cluster and Grid Software