Sorry, but there's no short cut: you need to read the manuals to understand the capabilities of the core, the jts, the jta and the ws-t layers which build on it, if you want to go this route. It would take a lot of effort in the forum to simply duplicate what's already written in the manuals.
The alternative is to consider coordinating your transactions via a different communication mechanism than the one you use for normal client/service interactions. There's precedent for this approach, so don't worry at first glance. If you can, then simply use the JTS implementation and interfaces for this: it's more powerful/flexible than JTA and would make it easier to wrap your transactional endpoints.
First: Thanks for the info.
Regarding the API, I was leaning towards the "Core" API as it seems simpler/cleaner, but I may be wrong - however, I didn't find a lot on distributed transactions in the core programmer's guide, but I'll look at the other Core-documents... or should I really choose JTS? It seems much more complex, however - why did you recommend it?
On the "transport" issue: I found a bit on "explicit" and "implicit" transaction context propagation, in JTS there the ExplicitInterposition is mentiond, but I guess that is not what I seek... is there even a pluggable transport layer I can plug my own into?
A thought: Does the "Core" even support distributed transactions? I thought JTS maps to OTS which uses CORBA-ORB machinery for distributed transactions, what would "Core" use, or doesn't it support distributed transactions over multiple nodes (regarding this, I only found the "single" and "multiple" models and in chapter 6, "Constructing a Transactional Objects for Java application" it simply says "In the rest of this chapter we shall assume that the application is not distributed. If this is not the case, then context information must be propagated either implicitly or explicitly." - I don't kn ow what this means exactly).
Last: Whatever API I use, I'll need to understand the "core" to plug my own transport, right? So if I also use the "Core" API, can I stay only within "Core"? Or do I misunderstand the whole core-JTS-JTA relationship completely?
You know, I search for a as-quick-as-possible way to test the concepts, although this test should of course be "real", not something completely different than the "real" implementation. In general, I couldn't find too much regarding "overview" of Jboss Tx...
Thanks again for your help and kind regards,
You won't find anything about distribution in the core: as it says here ArjunaCore knows nothing about distribution at all - the idea is you layer whatever veneer you need (IIOP, XML/SOAP, JMS, ...) over it.
JTS is all about distribibuted transactions, but using IIOP. So it includes things like automatic distributed failure recovery: one of the most important things you'd have to write if you were to go back to using ArjunaCore alone. It's all possible and if you really need/want to go that route, you will have to understand the core and jts documents.
The reason I mentioned JTS is that it's all done for you. If you can live with using IIOP for transaction coordination, there's very little else you need to do. You wouldn't plug into this (or plug it in to your pluggable transport): what I'm suggesting is that you have two transports that sit in parallel: your own for application use (basically anything that's not transaction related) and the IIOP stack for transaction coordination. There would be some cross over (and maybe this is what you mean by plugging in?): in your transport you would need to convey the transaction context between distributed endpoints. That context is represented as an OTS hierarchy, which you can serialize and deserialize when sending/receiving.
Thanks again for your reply - although I haven't decided yet, thanks to your help and the "What is ArjunaCore" (How would I get there normally, i.e. without your help?) document I have an overview now.
"plugging into" was meant like implementing a "Transport" class or sth. alike and telling Arjuna to use it for inter-node comm, i.e. a "pluggable" transport, like JBoss Remoting offers - somehow you need to do this too, as I saw in JIRA: http://jira.jboss.com/jira/browse/JBTM-14
It seems I rather need to create a whole layer "above" Core, i.e. duplicate JTS (part of it), somehow, right? I rather expected Arjuna to have, above the core, a common "distributed Tx" layer which I could plug my transport into... just to clarify.
Using two different transports (esp. IIOP) could be difficult, for the usual reasons...
Thanks much for your help!
Check out the Additional Material links on the labs.jboss.com JBossTS page.
JBossTS doesn't have an abstract comms layer, because there is very little commonality at that level: JTS is different to WST is different to JMS. The commonality exists at the transaction core layer. What someone want to do (or needs to do) in a distributed environment will depend heavily on that environment, failure semantics, recovery requirements, etc.