Hi Omer and Michael, Maybe late, but here is my 2 ct. contribution to the discussion of the 2 phase commit protocol used in our extended WS-Agreement implementation. I agree with Michael's analysis of the fundamental problems with 2PC in its blocking behaviour. Indeed, the cited references give a good overview of the problems with 2PC. The other argument of missing revenue when two offers arrive just after each other: while processing the 10 euro offer, the 10,000 offer might be rejected (by short of resources), and eventually the 10 euro offer is not committed. I think this problem is not specific to our approach, with any negotiation/obligation you can miss revenues if better offers, while engaged with a partner who might bail-out. Do you know of other negotiation strategies/policies that does not suffer from this? We can solve this in our framework by supporting re-negotiation, if a better offer arrives, the resource owner can start a re-negotiation with the current resource users. The problem of a denial-of-service attack (by proxy) is serious in any system where resources are allocated to the (un-) successful negotiation process (either by reserving resources or the use of computing resources by the protocol itself). In the paper, we did not include the details of authentication and trust, but this is included in the implementation of the framework. Repeated malicious behaviour will be punished and requests will not be considered. We chose to use 2PC, as it is a simple extension to the WS-Agreement protocol (and can be made compatible/interoperable by just skipping the last two steps). We did not want to redesign the WS-Agreement protocol, but include some primitive means for negotiation other than one-shot negotiaton (think of contractNet), and both parties commit to an agreement for legal purposes (as Omer explained). I will definitely look into your work with Dean Kuo. On Aug 24, 2007, at 1:09 PM, Omer F. Rana wrote:
Hi Michael,
Yes, I off course agree with your statement that all three must be taken into consideration. In practice, many implementations do not follow this line however -- but they should.
I guess there is a trade off between making the protocol too complex -- so much so that no one will actually use it -- vs. making it complete -- so that it takes account of everything that is useful. But you are right.
Thanks also for the additional links. Seems like I have my reading set out for this w/end.
regards Omer
Michael Parkin wrote:
Hi Omer,
Thanks for your reply.
On 24 Aug 2007, at 10:53, Omer F Rana wrote:
My undersstanding of the Mobach et al. paper -- and the reason the 2PC approach was chosen was to satisfy legal constraints that they were working on. Their aim was more to ensure that legally both parties were covered, more than looking into the specifics of constraints of a distributed implementation.
I believe that the legal, distributed computing _and_ business aspects of agreement must be considered together to design a successful contract negotiation and formation protocol - they cannot be considered separately. When all three aspects are taken into account together it is clear that 2PC-type protocols are inappropriate for cross-administrative domain negotiation because of the risk of blocking that is introduced, as I described in my previous email.
Work we have done [1] together with the School of Law at Manchester University investigates maintaining the legalities of contract negotiation and formation (including adhering to the EU's e-Commerce directive) whilst still allowing the entity supplying the resources/ services not to be blocked, thus satisfying the requirements of business. Section 4.1 of the linked paper discusses blocking.
Dean Kuo (who many of you know...[2]) and I are writing up and formally specifying the protocol we derived from this work and will be submitting this work for publication soon.
Michael.
[1] http://www2.cs.man.ac.uk/~parkinm/publications/ eChallenges_e2006_ref_235.pdf [2] http://www.cs.man.ac.uk/~dkuo/