Re: Transactional Web Services (LONG)

["W. E. Perry" <wperry@fiduciary.com>]

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?