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
