There are two aspects to supporting a new web services stack. If you only need the business logic calls to run on the new stack, you just modify the header context processors, which is easy even by the standards of programmers who think thedailywtf is a handy archive of reusable code snippets. If you need the transaction control messages to run over the new stack too it's a whole different ballgame, but stay tuned as Andrew is hard at work on that bit of the problem. Or at least he will be once we are back from JavaOne.
The txbridge is basically a proof of concept at this time. You definitely don't want to let it anywhere near a production environment, unless you have secretly been hired by your employer's competitors to do a little business sabotage.
You can use the same tx for multiple web services, including chains, loops and other interesting shapes. You can't always use the tx bridge in such cases though. It's smart enough to map calls in the same WS-T tx to a given JTA tx, but each instance does its own independent mapping. meaning two web services using the bridge will map the same WS-T tx to two different subordinate JTA tx, so the resource manager e.g. db/JMS, will see two transactions instead of one. That's fine if the web services don't need to read or write the same db/JMS, but if they need a consistent view you are out of luck. Globally consistent bridging of transactions is on the roadmap for a future release of the bridge.
What do you mean by reliable messaging? The transaction control messaging has timeout/retry behaviour that makes it pretty robust. No recovery right now, but Coordinator side recovery is almost ready to go, we are just waiting on some JBossAS changes before we can move to the new recovery model. Participant recovery is much harder due to interesting classloader issues and is still some way off.
If you intend to take a transactional app into production within the next six months you probably need to stick with JTA/EJB3. XTS will most likely have production support as part of JBossEAP 5.0 but not before.
Thanks for the info jhalliday. Have to stick to EJB3 in this case - at least until the release of JBossEAP 5.0.