A Parallel Methodology for Reduction of Coupling in Distributed Business-to-Business E-Commerce Transactions

Introduction

The Internet boom of the last decade has led to the realization that business automation is possible on a wider scale than ever before. Prior to the B2B push of the 1990s, electronic data interchange (EDI) was the industry standard for business automation across organizational boundaries. EDI provided a standard set of messages that business partners used to pass data between their respective applications. The EDI solution suffered from limited reusability due to the high degree of coupling required between applications and a high cost of implementation (Weigand, Heuvel, & Dignum, 1998), which translates to a higher cost per transaction. These factors prohibited smaller businesses from implementing EDI-based solutions (Weigand et al., 1998). A key benefit of the research in business automation is a lower transaction cost; the lowered transaction cost has been the impetus that has driven the latest B2B e-commerce research. The result of early B2B automation was the development of several proprietary B2B frameworks1 that defined a set of services to provide pairwise interoperability between two companies for integration of their enterprise applications (Ariba Inc., 2006). However, the pairwise interoperability was limited by the development of many competing frameworks and a lack of interoperability between the competing frameworks.

There are many examples of B2B e-commerce transactions that parallel logistics management problems that require coordination of multiple interactions between many trading partners. These logistic management problems require distributed transaction support on relational database management systems (Riccardi, 2001) not provided in these B2B frameworks. Therefore, front-end applications provide the distributed transaction support required for many B2B and logistics management problems. If these front-end applications use traditional distributed transaction techniques, the possibility of extended record locking across organizational boundaries exists. In long-running transactions, these extended record locks may not be desirable and must be considered as a component in the cost of a B2B e-commerce transaction. Extended record locking can be illustrated with the following example: Suppose company A is building widgetA. In order to build widgetA, company A needs widgetB from company B and widgetC from company C. Suppose company B possesses exactly five widgetBs at the current time. Also, suppose company C has just sold its last widgetC and must receive a shipment from the factory before it has new widgetCs available for purchase. A transaction goes out from company A to both companies B and C. This transaction asks to purchase a widgetB from company B and a widget C from company C. The database in company B locks the record corresponding to one of its five widgetBs. This widget will be held until the overall transaction is complete. Meanwhile, company C is unable to complete its part of the transaction, because it has not received its shipment of widgetCs. The record in company B could be locked for hours or days, until the overall transaction completes. In the meantime, several hours or a day later, another transaction request from a different customer arrives at company B. This request is for five widgetBs. Company B is unable to satisfy this request, due to the locked record for one of its widgetBs.