Yes, carefully crafted transaction mgmt protocols may simply processing, especially in a inter-organisational setting, with a single point of control. However in a multi party situation with some level of distrust, the game still change. The common sense idea of "reach the desk" still applies, even in a situation where one party has a poorly executing system. The key is the balance of risk, who is responsible of case of failure? In most B2B scenarios parties does not like to assume the risk of others.
Its also discouraging that most (business) SOA design disciplines don't incorporate the balance (and cost) of risk. /anders w. tell On Apr 6, 2010, at 11:57 PM, Gregg Wonderly wrote: > Anders Tell wrote: > > In a legally relevant transaction-protocol there are more end states to > > consider such as dispute. So technically protocols and solution can be > > improved to be more business like an handle more scenarios. > > One the things that can happen, is that transaction participants can be added > that can check the things that are unimportant to the IT infrastructure, but > necessary for the business case. By using transaction participants, you avoid > layering logic in various places, and instead, you can provide a pluggable > API > in a software system which can allow additional logic to be implemented by > simply adding more participants that can "vote" on the validity of what is > happening. > > The use of transactional agreement is often viewed as a problematic step to > take > but, in the end, you'll end up writing transaction structured code for these > kinds of things anyway. Jini provides a simple to use transactional model and > because it standardized and setting at your finger tips, it's easy to just do > it > and thus guarantee the sanity of the operation. > > Yes, software can have bugs, and a transaction participant may not be > implemented correctly. But this is no different than any other bit of > software. > One must test and demonstrate fitness of the system at the appropriate level. > > Gregg Wonderly >
