|
|
As described earlier, JTA- and JTS-based transaction managers are limited, in that they are meant to manage and coordinate distributed, ACID transactions. A new specification is needed to address the complex distributed transactions prevalent in Web service and workflow apps.
JSR-95, J2EE Activity Service for Extended Transactions, proposes a low-level API for J2EE containers and transaction managers. JSR-95 borrows from the OMG Activity Service submission and leverages concepts defined by JTA and EJB specifications. JSR-156, XML Transactions for Java (JAXTX), also proposes support for extended transaction support in J2EE systems. Unlike JSR-95, JSR-156 proposes a closer relationship to the BTP specification, using XML messaging for transaction management and coordination. This proposed Java API also has a loftier long-term goal: to isolate app programmers and app servers from the underlying transaction manager implementation (BTP, WS-Transaction, and Activity Service).
 |
The acronym "JAXTX," in an attempt at consistency with other JAX* APIs, is, in our opinion, misleading. The other JAX* APIs (e.g., JAXM) are meant to be used primarily by app programmers. The J2EE specifications have tried to minimize programmatic transaction demarcation, making the UserTransaction interface the only JTA interface exposed to the app.
We recognize that coordinated, non-atomic transactions (e.g., cohesive BTP transactions and business transactions in the WS-Transaction specification) will require app logic to generate compensation transactions. We also recognize that in determining the subset of activities treated as atomic, the interface exposed to app programmers must be expanded beyond the current JTA UserTransaction interface. But the vast majority of transaction coordination messages are meant to be exchanged by components below the app layer. Therefore, we feel that "JAXTX" is misleading.
|
|
|