Re: Transactional Web Services (LONG)
What you say about the 2PC transaction protocol is correct and clearly illustrates the fundamental 'agency' basis of that model: "The transaction comprises a set of operations divided among the parties by the requester or an interpreter acting on behalf of all the parties. Each party may be told only about the operations it is expected to perform." That is, at a minimum, the interpreter shares an exact understanding of the content of a transaction with each of the parties, one by one, to which it delegates a commit. It is possible (though in my experience of transactional system implementations, unusual) that an interpreter might present different specific data instantiations to each of the parties with which it interacts in the distributed processing of a single logical transaction. However, the understanding between the interpreter and each of those parties individually is based on a specific data instantiation. Furthermore, the goal of the interpreter in dealing with each of those parties is to effect congruent outcomes from the individual commit which each of those parties performs, in order to maintain the system-wide consistency of data which is the 'C' of the ACID test. This is inherently a broker/facilitator/agent role. By contrast, the 'principal' form of transaction which I propose in the 'souk' model is a single commitment between autonomous peers whose individual instantiation of the the data substance of the transaction and subsequent further processing is beyond the reach of the other party. Such a transaction is concluded when one party agrees to the specifics as offered at that moment by the other party, which then accepts that agreement. There is no question of achieving a consistency of result. It is however generally necessary that further transactions be executed to satisfy the logistical demands crated by the original execution. Payment must be arranged, as well as delivery. The expectation of the souk model is that each such step will entail a further unique principal transaction between autonomous parties. The party accepting the terms of execution offered by the other will then need to effect a transaction versus its bank to arrange payment. The other party will need to effect a transaction to procure shipment. The shipper will then need to effect a transaction versus the purchaser in order to arrange a delivery. The purchaser's bank will need to effect a transaction versus the seller in order to arrange the transfer of funds. Each of these transactions is effected between principal parties: the purchaser's bank, for example does not mediate or broker between the purchaser and the seller. The execution of each of these transactions confirms the terms of the others. If the seller balks at the terms of payment offered by the purchaser's bank, it has the option of returning to the purchaser to cancel the original deal through an offsetting transaction. Otherwise, the seller's acceptance of the bank's terms corroborates the individual understanding of the original transaction's terms by each of those original parties. In the aggregate, the execution of a group of transactions, each of them by autonomous principal parties, achieves an equivalent business outcome to the propagation, by the agency of 2PC, of a single much more complex transaction to all of the interested parties. The advantages of the principal, rather than the agency, approach are a much greater simplicity and comprehensibility in the terms of each individual execution, and the ability for parties to execute what they understand, without having first to agree to the form and representation of data which is only ancillary to the transaction as they understand it, and at best tangential to their own role and expertise in the specific transaction which they understand and care about. Respectfully, Walter Perry Jeff Greif wrote: > Isn't the purpose of the 2PC model merely to ensure that all the parties in > the transaction complete it the same way, either committing or aborting as a > group the operations they have individually undertaken as their part of the > transaction? Once all the parties have agreed to commit (by replying to the > "prepare" message from the coordinator), all have the means to do so even if > they crash before the "commit" message from the coordinator reaches them, > and can recover correctly when they restart by asking the coordinator or one > of the other parties whether the transaction was actually committed. There > is not necessarily any common data shared by all parties or any common > understanding of some data structure. The transaction comprises a set of > operations divided among the parties by the requester or an interpreter > acting on behalf of all the parties. Each party may be told only about the > operations it is expected to perform. Only if it thinks it understands the > instructions (in its own way, which might not agree with what the requester > intended) and can carry them out in some sort of persistent scratch area > will it reply affirmatively to the "prepare" message. How does the souk > model remove the need for agreement to be reached among the parties about > how to complete the transaction, and how can this agreement be communicated > without the transaction monitor of the 2PC, whose purpose is to avoid race > conditions arising from other ways of attempting to communicate agreement?
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format