[jbossts-issues] [JBoss JIRA] (JBTM-981) Annotation support for transaction bridging

[Paul Robinson (Updated) (JIRA)]

     [ https://issues.jboss.org/browse/JBTM-981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Robinson updated JBTM-981:
-------------------------------

    Description: 
h2.Vision
The grand plan for this feature is to support near transparent bridging, end-to-end irrespective of what transport and component technology is used. The only caveat being that the transport and component technologies support a compatible transaction model. The basic case would be to always bridge when possible and for this scenario the absolute bare-minimum number of annotations should be used. More specific bridging requirements should be specified through annotations. 

h2.Example
# A JSF managed bean has a client to Service1 injected.
# The managed bean begins a transaction.
# Service1 uses WSPolicy to state that it requires a WSAT transaction to be in place.
# Somehow (maybe during injection or when CXF handles the PolicyAssertion) the injected client stub for Service1 has the TXBridge and XTS interceptors configured.
# The managed bean invokes a method on Service1.
# The JTA transaction is bridged to a WS-AT transaction and the Web service request is made. 
# Service1 specified by an annotation that it requires a transaction (this was how the WS-Policy assertion was placed in the WSDL) and thus the XTS and TXBridge interceptors are inserted.
# The incoming WS-AT context is detected and bridged onto a JTA transaction.
# Service1 updates a DB and the associated XAResource is enlisted with the JTA transaction.
# Service1 then invokes the client of Service2.
# Service2 does not specify that it requires a WS-AT transaction, via a WS-Policy assertion. Therefore the client to Service2 must be annotated to specify that it requires WS-AT transaction out-flow.
# When invoking a method on the Service2 client it is detected that a WS-AT transaction is already in-place and this is used, rather than bridging again from JTA back to WS-AT.

Similar behaviour should occur for REST and JTS transactions also. 


  was:
!!Vision
The grand plan for this feature is to support near transparent bridging, end-to-end irrespective of what transport and component technology is used. The only caveat being that the transport and component technologies support a compatible transaction model. The basic case would be to always bridge when possible and for this scenario the absolute bare-minimum number of annotations should be used. More specific bridging requirements should be specified through annotations. 

!!Example
# A JSF managed bean has a client to Service1 injected.
# The managed bean begins a transaction.
# Service1 uses WSPolicy to state that it requires a WSAT transaction to be in place.
# Somehow (maybe during injection or when CXF handles the PolicyAssertion) the injected client stub for Service1 has the TXBridge and XTS interceptors configured.
# The managed bean invokes a method on Service1.
# The JTA transaction is bridged to a WS-AT transaction and the Web service request is made. 
# Service1 specified by an annotation that it requires a transaction (this was how the WS-Policy assertion was placed in the WSDL) and thus the XTS and TXBridge interceptors are inserted.
# 



    
> Annotation support for transaction bridging
> -------------------------------------------
>
>                 Key: JBTM-981
>                 URL: https://issues.jboss.org/browse/JBTM-981
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Paul Robinson
>            Assignee: Paul Robinson
>              Labels: TXFramework
>             Fix For: 5.0.0.M2
>
>
> h2.Vision
> The grand plan for this feature is to support near transparent bridging, end-to-end irrespective of what transport and component technology is used. The only caveat being that the transport and component technologies support a compatible transaction model. The basic case would be to always bridge when possible and for this scenario the absolute bare-minimum number of annotations should be used. More specific bridging requirements should be specified through annotations. 
> h2.Example
> # A JSF managed bean has a client to Service1 injected.
> # The managed bean begins a transaction.
> # Service1 uses WSPolicy to state that it requires a WSAT transaction to be in place.
> # Somehow (maybe during injection or when CXF handles the PolicyAssertion) the injected client stub for Service1 has the TXBridge and XTS interceptors configured.
> # The managed bean invokes a method on Service1.
> # The JTA transaction is bridged to a WS-AT transaction and the Web service request is made. 
> # Service1 specified by an annotation that it requires a transaction (this was how the WS-Policy assertion was placed in the WSDL) and thus the XTS and TXBridge interceptors are inserted.
> # The incoming WS-AT context is detected and bridged onto a JTA transaction.
> # Service1 updates a DB and the associated XAResource is enlisted with the JTA transaction.
> # Service1 then invokes the client of Service2.
> # Service2 does not specify that it requires a WS-AT transaction, via a WS-Policy assertion. Therefore the client to Service2 must be annotated to specify that it requires WS-AT transaction out-flow.
> # When invoking a method on the Service2 client it is detected that a WS-AT transaction is already in-place and this is used, rather than bridging again from JTA back to WS-AT.
> Similar behaviour should occur for REST and JTS transactions also. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira