|
|
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 applications.
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 application programmers and application 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 application programmers. The J2EE specifications have tried to minimize programmatic transaction demarcation, making the UserTransaction interface the only JTA interface exposed to the application.
We recognize that coordinated, non-atomic transactions (e.g., cohesive BTP transactions and business transactions in the WS-Transaction specification) will require application logic to generate compensation transactions. We also recognize that in determining the subset of activities treated as atomic, the interface exposed to application 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 application layer. Therefore, we feel that "JAXTX" is misleading.
|
|
|