[JBoss JIRA] Created: (JBTM-776) Enable XTS client deployments without the need for a JaxWS endpoint
10:11 a.m.
Enable XTS client deployments without the need for a JaxWS endpoint
-------------------------------------------------------------------
Key: JBTM-776
URL: https://jira.jboss.org/browse/JBTM-776
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: XTS
Affects Versions: 4.12.0
Reporter: Andrew Dinn
Assignee: Andrew Dinn
It would be very useful if the XTS client code could be deployed embedded with JBossTS
without the need to deploy any JaxWS endpoints i.e. so that it only required httpclient
capability. This would allow development of, say, CXF-based clients running on a simple
desktop system which use embedded TS/XTS to provide transactional access to web services.
Removal of the JaxWS endpoints avoids the need to expose the desktop machine with a public
IP address, open up fire walls etc which are serious barriers to such deployments.
At present implementing this change is stopped by two factors:
- the XTS code cannot be built and configured as a client only deployment
- the Completion protocols used by WS-AT and WS-BA to terminate transactions employ one
way messages
the latter requirement forces the client to expose an endpoint for delivery of the message
confirming and identifying the outcome of a termination request.
The first problem will be addressed by a related issue.
Solving the second problem requires implementing an alternative version of the Completion
services employing protocol messages with an RPC message exchange pattern. For WS-BA this
raises no serious issues since the BA standard does not specify the details of the
Completion protocol -- we can do what we like in this regard.
In the case of WS-AT the spec does define the protocol. So, any alternative we provide
will be non-standard i.e. it willl only work if the client is talking to a JBoss
coordinator (this is already the situation for our or anyone else's BA client
implementation, mind you). While this does not invalidate adding this feature it does
qualify its utility since clients developed using this extension will not be portable.
If this feature works and is useful it woudl be worth lobbying to get it adopted as part
of the standard.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:25 a.m.
New subject: [JBoss JIRA] Commented: (JBTM-776) Enable XTS client deployments without the need for a JaxWS endpoint
[
https://jira.jboss.org/browse/JBTM-776?page=com.atlassian.jira.plugin.sys...
]
Andrew Dinn commented on JBTM-776:
----------------------------------
This is now working. The coordinator side now includes two extra endpoints which handle AT
and BA termination requests using an RPC MEP. These are declared in the ws-t11-coordinator
web-app.xml and are initialised by CoordinatroSideInitialisation. The assumption is that
both the RPC-based and OneWay based services will run on the coordinator side allowing
both types of client to be served.
The client side can be configured to use the RPC based termination protocol simply by
switching to a different implementation of the UserTransaction and UserBusinessActivity
classes. The implementation classes specified in the xts-properties.xml or jboss-beans.xml
needs to be modified from
com.arjuna.mwlabs.wst11.at.remote.UserTransactionImple
com.arjuna.mwlabs.wst11.ba.remote.UserBusinessActivityImple
to
com.arjuna.mwlabs.wst11.at.remote.UserTransactionStandaloneImple
com.arjuna.mwlabs.wst11.ba.remote.UserBusinessActivityStandaloneImple
Currently, this is all the only configuration change needed on the client side. The
associated manager classes do not need to be redefined. The client deployment can drop the
ws-t11-client war because the endpoint is no longer needed.
Strictly, the client side initialisation class should be changed to drop the calls to
CompletionInitiatorInitialisation.startup() and
TerminationParticipantInitialisation.startup() and just call WSTXInitialisation.startup().
However, these calls do no harm. This can be addressed in a later patch by providing an
alternative client side init routine which only does WSTX initialistaion.
Enable XTS client deployments without the need for a JaxWS endpoint
-------------------------------------------------------------------
Key: JBTM-776
URL: https://jira.jboss.org/browse/JBTM-776
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: XTS
Affects Versions: 4.12.0
Reporter: Andrew Dinn
Assignee: Andrew Dinn
It would be very useful if the XTS client code could be deployed embedded with JBossTS
without the need to deploy any JaxWS endpoints i.e. so that it only required httpclient
capability. This would allow development of, say, CXF-based clients running on a simple
desktop system which use embedded TS/XTS to provide transactional access to web services.
Removal of the JaxWS endpoints avoids the need to expose the desktop machine with a public
IP address, open up fire walls etc which are serious barriers to such deployments.
At present implementing this change is stopped by two factors:
- the XTS code cannot be built and configured as a client only deployment
- the Completion protocols used by WS-AT and WS-BA to terminate transactions employ one
way messages
the latter requirement forces the client to expose an endpoint for delivery of the
message confirming and identifying the outcome of a termination request.
The first problem will be addressed by a related issue.
Solving the second problem requires implementing an alternative version of the Completion
services employing protocol messages with an RPC message exchange pattern. For WS-BA this
raises no serious issues since the BA standard does not specify the details of the
Completion protocol -- we can do what we like in this regard.
In the case of WS-AT the spec does define the protocol. So, any alternative we provide
will be non-standard i.e. it willl only work if the client is talking to a JBoss
coordinator (this is already the situation for our or anyone else's BA client
implementation, mind you). While this does not invalidate adding this feature it does
qualify its utility since clients developed using this extension will not be portable.
If this feature works and is useful it woudl be worth lobbying to get it adopted as part
of the standard.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:37 a.m.
New subject: [JBoss JIRA] Commented: (JBTM-776) Enable XTS client deployments without the need for a JaxWS endpoint
[
https://jira.jboss.org/browse/JBTM-776?page=com.atlassian.jira.plugin.sys...
]
Andrew Dinn commented on JBTM-776:
----------------------------------
Ok, you can now initialise the standalone client correctly by switching the entry in the
xts Initialisation list from org.jboss.jbossts.xts.initialisation.ClientSideInitialisation
to org.jboss.jbossts.xts.initialisation.ClientSideStandaloneInitialisation. The latter
routine only does WSTX initialisation.
In the xts-properties file this is configured by setting a property with prefix
org.jboss.jbossts.xts.initialisation.xtsInitialisation to have value
org.jboss.jbossts.xts.initialisation.ClientSideStandaloneInitialisation instead
oforg.jboss.jbossts.xts.initialisation.ClientSideInitialisation . In the jboss-beans file
this is done by editing the list value injected into the xtsInitialisations property of
the XTSEnvironmentBean.
Enable XTS client deployments without the need for a JaxWS endpoint
-------------------------------------------------------------------
Key: JBTM-776
URL: https://jira.jboss.org/browse/JBTM-776
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: XTS
Affects Versions: 4.12.0
Reporter: Andrew Dinn
Assignee: Andrew Dinn
It would be very useful if the XTS client code could be deployed embedded with JBossTS
without the need to deploy any JaxWS endpoints i.e. so that it only required httpclient
capability. This would allow development of, say, CXF-based clients running on a simple
desktop system which use embedded TS/XTS to provide transactional access to web services.
Removal of the JaxWS endpoints avoids the need to expose the desktop machine with a public
IP address, open up fire walls etc which are serious barriers to such deployments.
At present implementing this change is stopped by two factors:
- the XTS code cannot be built and configured as a client only deployment
- the Completion protocols used by WS-AT and WS-BA to terminate transactions employ one
way messages
the latter requirement forces the client to expose an endpoint for delivery of the
message confirming and identifying the outcome of a termination request.
The first problem will be addressed by a related issue.
Solving the second problem requires implementing an alternative version of the Completion
services employing protocol messages with an RPC message exchange pattern. For WS-BA this
raises no serious issues since the BA standard does not specify the details of the
Completion protocol -- we can do what we like in this regard.
In the case of WS-AT the spec does define the protocol. So, any alternative we provide
will be non-standard i.e. it willl only work if the client is talking to a JBoss
coordinator (this is already the situation for our or anyone else's BA client
implementation, mind you). While this does not invalidate adding this feature it does
qualify its utility since clients developed using this extension will not be portable.
If this feature works and is useful it woudl be worth lobbying to get it adopted as part
of the standard.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:07 a.m.
New subject: [JBoss JIRA] Commented: (JBTM-776) Enable XTS client deployments without the need for a JaxWS endpoint
[
https://jira.jboss.org/browse/JBTM-776?page=com.atlassian.jira.plugin.sys...
]
Andrew Dinn commented on JBTM-776:
----------------------------------
Ok, this is essentially complete but there is one wrinkle left outstanding.
The old client implementation of the Completion protocol would wait forever after sending
a Commit message for a Committed or Aborted message to be returned. So, there was
effectively no client timeout once the initial one way request was delivered. By contrast,
the RPC based exchange is at the mercy of the JaxWS code as far as timeouts are concerned.
If the JaxWS client decides to stop waitign for a response from the server it can drop the
connection and return early.
With JBossWS-CXF the default appears to be for the RPC-based commit request to time out
after somewhere between 80 and 100 seconds. So, if a commit operation takes a very very
long time because, say, one of the web servers is slow to respond or because, maybe, there
are a lot of web service participants to contact, the client may give up and claim that
the commit request timed out. Note that this is not because the HTTP connection has been
lost -- it's just that when the service request takes too long the client will return
early.
At present there is no simple way to configure this timeout in a stack independent way. A
JIRA has been raised to provide a generic way to do this and we also intend to submit a
proposal for this to be included as standard in JaxWS.
This will be dealt with in a later JIRA as will documentation of the new config options
raised by this change.
Enable XTS client deployments without the need for a JaxWS endpoint
-------------------------------------------------------------------
Key: JBTM-776
URL: https://jira.jboss.org/browse/JBTM-776
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: XTS
Affects Versions: 4.12.0
Reporter: Andrew Dinn
Assignee: Andrew Dinn
It would be very useful if the XTS client code could be deployed embedded with JBossTS
without the need to deploy any JaxWS endpoints i.e. so that it only required httpclient
capability. This would allow development of, say, CXF-based clients running on a simple
desktop system which use embedded TS/XTS to provide transactional access to web services.
Removal of the JaxWS endpoints avoids the need to expose the desktop machine with a public
IP address, open up fire walls etc which are serious barriers to such deployments.
At present implementing this change is stopped by two factors:
- the XTS code cannot be built and configured as a client only deployment
- the Completion protocols used by WS-AT and WS-BA to terminate transactions employ one
way messages
the latter requirement forces the client to expose an endpoint for delivery of the
message confirming and identifying the outcome of a termination request.
The first problem will be addressed by a related issue.
Solving the second problem requires implementing an alternative version of the Completion
services employing protocol messages with an RPC message exchange pattern. For WS-BA this
raises no serious issues since the BA standard does not specify the details of the
Completion protocol -- we can do what we like in this regard.
In the case of WS-AT the spec does define the protocol. So, any alternative we provide
will be non-standard i.e. it willl only work if the client is talking to a JBoss
coordinator (this is already the situation for our or anyone else's BA client
implementation, mind you). While this does not invalidate adding this feature it does
qualify its utility since clients developed using this extension will not be portable.
If this feature works and is useful it woudl be worth lobbying to get it adopted as part
of the standard.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:09 a.m.
New subject: [JBoss JIRA] Closed: (JBTM-776) Enable XTS client deployments without the need for a JaxWS endpoint
[
https://jira.jboss.org/browse/JBTM-776?page=com.atlassian.jira.plugin.sys...
]
Andrew Dinn closed JBTM-776.
----------------------------
Fix Version/s: 4.13.0
Resolution: Done
Enable XTS client deployments without the need for a JaxWS endpoint
-------------------------------------------------------------------
Key: JBTM-776
URL: https://jira.jboss.org/browse/JBTM-776
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: XTS
Affects Versions: 4.12.0
Reporter: Andrew Dinn
Assignee: Andrew Dinn
Fix For: 4.13.0
It would be very useful if the XTS client code could be deployed embedded with JBossTS
without the need to deploy any JaxWS endpoints i.e. so that it only required httpclient
capability. This would allow development of, say, CXF-based clients running on a simple
desktop system which use embedded TS/XTS to provide transactional access to web services.
Removal of the JaxWS endpoints avoids the need to expose the desktop machine with a public
IP address, open up fire walls etc which are serious barriers to such deployments.
At present implementing this change is stopped by two factors:
- the XTS code cannot be built and configured as a client only deployment
- the Completion protocols used by WS-AT and WS-BA to terminate transactions employ one
way messages
the latter requirement forces the client to expose an endpoint for delivery of the
message confirming and identifying the outcome of a termination request.
The first problem will be addressed by a related issue.
Solving the second problem requires implementing an alternative version of the Completion
services employing protocol messages with an RPC message exchange pattern. For WS-BA this
raises no serious issues since the BA standard does not specify the details of the
Completion protocol -- we can do what we like in this regard.
In the case of WS-AT the spec does define the protocol. So, any alternative we provide
will be non-standard i.e. it willl only work if the client is talking to a JBoss
coordinator (this is already the situation for our or anyone else's BA client
implementation, mind you). While this does not invalidate adding this feature it does
qualify its utility since clients developed using this extension will not be portable.
If this feature works and is useful it woudl be worth lobbying to get it adopted as part
of the standard.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5205
days inactive
5218
days old
jbossts-issues@lists.jboss.org
4 comments
1 participants
participants (1)
-
Andrew Dinn (JIRA)