I'm an academic, with more experience in looking at other people's systems than in building my own, and with more experience with patterns and frameworks than with business transaction processing. Nevertheless, I came by my interest in business transaction processing honestly. During graduate school I supported myself by consulting at the Cornell Campus Store. I worked on the sales processing system, three different inventory systems, accounts payable, accounts receivable, and accounting. After graduation, I got interested in object-oriented design, frameworks, and eventually patterns. It was natural to think about the system at the store, and that lead to Accounts, a framework for business transaction processing, and some patterns for business transactions.
Business transactions correspond to the pieces of paper that people and organizations send to each other, such as checks, time-cards, or invoices. They represent changes in the state of the parties involved in the transaction. They are different from database transactions, which represent operations (including reads) on the state of the database. There is obviously a close relationship between these different kinds of transactions, but they are not the same, and it is high time someone studied the business transactions from a computer science point of view, and not just the database transactions.
Conventional business transaction processing systems usually emphasize accounts, and deemphasize transactions. This is natural, because most reports are in terms of the state of the business, which is described by the accounts. What is the total sales made by John Smith? How many Beany Babies do we have in stock? How big is our bank account? Although we can define each "state variable" as a function of the transactions that have occurred, we do not want to compute them this way. Instead, we want posting a transaction to update the state of the system. The usual way to do this leads to big, complex update programs that encode the rules of the system.
Accounts changes all this. It provides a declarative language for specifing the effect of a transaction. The rules for processing a transaction are objects whose state can be tracked over time. I believe the system will be scaleable, easy for business people to understand, and easy to evolve. Of course, I've only tested it on toy applications, so I do not yet know whether it will be as easy to understand as I think it will be, or whether it will be powerful enough and efficient enough. I am hoping that one of the effects of this workshop will be to help me find weakness in Accounts and to get ideas how to fix them.