XTS + XA Transactions + XFire - some general questions

[hoschi]

Hi together,

as my brain constantly throws InformationFilteringExceptions, I am currently a bit confused about XTS in general.

We are currently using XFire to expose webservices and are looking for possibilities for using distributed transactions over some of the exposed services. So I got some questions about it:

-) XTS does not support XFire - however, as I read in a post ([1]) and if I understood it correctly, it should be pretty easy implement support for XFire by extending the header context processors of XTS. Is it really that easy (I'm sure it is from a JBossTS-developer point of view ;-)) and which classes would that be?

-) Enlistment of XA-Ressources (DB, JMS-Sessions, ...) is not supported currently. However, there is a Tx-Bridge available ([2]) which enables enlistment of XA-Ressources and JTA-Transactions to WS-Transactions. Is it stable/tested enough to use it within a production environment?

-) Is it possible to use the same transaction over more than one webservice? Something like: an application A starts a transaction and calls webservice B, B calls webservice C. A+B+C are in the same transaction, including the transactional ressources (DB, JMS-Sessions, ;)) of B+C.

-) Reliable messaging and/or recovery is not supportet by XTS. Correct?

-) At the current state, would it be better to use EJB3 if possible? We don't want to use two different technologies for exposing webservices if not nessecary.

Thanks in advance

Regards
Johannes

[1] http://www.jboss.com/index.html?module=bb&op=viewtopic&t=131025
[2] http://anonsvn.labs.jboss.com/labs/jbosstm/workspace/jhalliday/txbridge/

[jhalliday]

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.

[hoschi]

Thanks for the info jhalliday. Have to stick to EJB3 in this case - at least until the release of JBossEAP 5.0.

Regards
Johannes