|
Comments
Did you read today's front page stories & breaking news?
SYS-CON.TV
|
Industry Commentary Transactions in Business Processes - A New Model
Transactions in Business Processes - A New Model
By: Richard Rollman
Sep. 26, 2003 10:22 AM
Transactions are a common, everyday occurrence in our lives. When you buy something at the grocery store, transfer funds between bank accounts, or simply make a phone call you are executing a transaction. In general terms, a transaction involves one or more changes in state. For example, purchasing groceries involves many state changes. You debit your credit card while the grocery store reduces their inventory. Together, these changes represent a transaction. The together part is important since you wouldn't want to pay unless you actually got to take the groceries home. So, we can define a transaction as a group of state changes (or activities) that must be completed as a unit - all activities succeed or fail together.
ACID Transactions Databases aren't the only systems that implement transactions. Enterprise systems, including parts of J2EE such as EJBs and JMS, use ACID transactions. The Java Transaction API (JTA) and Java Transaction Service (JTS) implement them. Client/server systems also require transactions but add the special wrinkle that the activities and state changes that compose the transaction span multiple machines, networks, and enterprises. Like transactions in a database, distributed transactions are ACID transactions where resources are locked until all activities complete successfully.
Business Processes and Transactions Business processes use transactions to ensure that all activities complete as a unit. But because activities in a business process utilize resources from many business partners and can execute for hours, days, or longer, the transactions must be managed differently. Consider a purchasing business process. It might solicit quotes, reserve inventory, issue purchase orders, confirm receipt of items, and transfer funds. For scenarios like this, using a single ACID transaction for the entire business process is impractical. Business processes require a new kind of transaction. Long-running transactions avoid locks on non-local resources, use compensation to handle failures, potentially aggregate smaller ACID transactions, and typically use a coordinator to complete or abort the transaction. In contrast to rollback in ACID transactions, compensation restores the original state, or an equivalent, and is business-specific. The compensating action for making a hotel reservation is canceling that reservation, possibly with a penalty. A number of protocols have been specified for long-running transactions using Web services within business processes. WS-Transaction with WS-Coordination, OASIS Business Transaction Processing, and WS-CAF are examples. These protocols use a coordinator to mediate the successful completion or use of compensation in a long-running transaction.
The Future Reproduced with permission from BEA Systems Reader Feedback: Page 1 of 1
SOA World Latest Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
|
SYS-CON Featured Whitepapers
Most Read This Week |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||