Set Home Page Add Favorite Hello, Welcome to BtoB B2B  [Login] [Register] Help Center Free Post

BtoB B2B

Your current location: BtoB B2B » Industry Info » B2B News » Business transactions

Business transactions

Source:BtoB B2B(2010-12-30)Categories:[B2B News] Keyword: B2B

A business transaction consists of exchange of messages resulting in a consistent change in the state of the business. Business processes can be composed of one or several business transactions. B2B transactions involve multiple enterprises and resources (such as databases, transactional objects and queues for persistent messages) that are managed and operated independently by each enterprise. Successful outcome of a transaction is dependent on the coordination of workflows, which drive business transactions, across multiple organizations.

B2B transactions can be completed within a few seconds or can last over days. Transactions that are long-lasting pose a unique challenge to the design and run-time execution of B2B applications. Consider an example where the buyer has placed an order with a supplier for shipment of some goods. This transaction will not be completed until the buyer actually receives the final delivery of the goods.

A coordinated, flat transaction model requires maintaining full atomicity, consistency, isolation, durability and integrity of a transaction. It requires a two-phase-commit protocol in order to enable distributed transaction coordination and provides an all-or-nothing guarantee by assuring that all participants of the transaction agree to either complete the transaction or abort it. There is usually only a single layer of control required by the flat transaction model.

But this approach does not always fit long-lasting B2B transactions. In such cases it is not practical to achieve isolation, as it requires enterprises to lock their databases while waiting for others to finish their part of the transaction. The extended transaction model, also known as open nested transaction model, fits well in such scenarios as it allows the main transaction to be broken into independent and logical sub-transactions. The outcome of the sub-transactions is tied to the main transaction. If the main 'transaction aborts' all sub-transactions must abort. This model does not impose the isolation requirement, but maintains the all-or-nothing nature of transactions by using the process level forward and backward recovery approach.

[Close Window] [Print Page] Views:475