[jbossts-issues] [JBoss JIRA] Commented: (JBTM-776) Enable XTS client deployments without the need for a JaxWS endpoint

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.