Currently the implementation of WS-AT depends on some features not standardized
by JTA/JTS spec, like the JNDI name of transaction manager and contract
represented by com.sun.enterprise.TransactionImport. If there is a SPI
reprensenting all these requirement, the integration of the WSIT transaction
with other JEE5 container will be much easier.
Here is the eamil thread:
> Hi Joseph,
> Looks like WS-AT sample can only run with Glassfish. Because WS-AT
> in WSIT depends on internal API from Glassfish Transaction Manager.
WSIT WS-TX implementatino depends on JTA 1.0.1 API as much as it can.
It also needed to depend on methods used to implement the Transaction Inflow
contract from Java Connector API 1.5. The SPI contract represented by
com.sun.enterprise.TransactionImport interface is all that required to
be implemented above
and beyond JTA 1.0.1 API.
TransactionImport interface represents exposing methods used to
implement Transaction Inflow
contract in JCA 1.5.
> impossible to deploy the sample into Tomcat integrated a third-party
> manager like JTOM. Is there any plan to make the underlying
> Transaction Manager
> pluggable so WS-AT sample can run out of Glassfish?
The initial WSIT WS-TX design center was to work with an Application
Server having a JTA Transaction Manager.
Any Java EE application server implementing JCA 1.5 can trivially
implement the TransactionImport interface
Please file an enhancement request in wsit issue tracker if this a
functionality that you would like to see considered for
a future release. As I stated above, The WSIT WS-TX code dependencies on
a Transaction Manager are
mostly on JTA 1.0.1 API. Note that there is a WS-AT coordinator service
deployed as a system level service in
Glassfish v2 App Server that would have to be deployed into Tomcat.