[
https://issues.jboss.org/browse/JBTM-981?page=com.atlassian.jira.plugin.s...
]
Paul Robinson updated JBTM-981:
-------------------------------
Description:
!!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.
#
was:
Currently the developer specifies the type of transaction that the service and any
lifecycle callbacks expect to participate in. For example, via @WSBA or @RESTJDI class
level annotation. However, the participation requirements for these protocols is very
similar. It would be better if the developer could simply specify that the service can
participate in any forward compensation style transaction (such as REST-JDI or WS-BA)
using a @BA annotation. The type of transaction is determined by the inflowed TX context.
To take this a step further, by leaving off the transaction type annotation altogether,
the service could participate in any transaction type. Of course, this would require a mix
of ACID and forward compensation lifecycle callbacks to be present. Again, the inflow TX
context would decide the actual TX type used.
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
!!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.
#
--
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