Hello again ;-)
As I said already, transactional delivery isn't something that will be supported until 4.2.1 and then only on JMS. Why not write this 3rd party application yourself?
It had been our idea before we got completly lost :).
Where should we start from? I got a strange feeling that we miss some required knowledge how the things work.
What mechanisms should we know? What can be really helpful for us to start with?
My first idea was something like that:
Let's say I get Xid from that 3rd party and associate it to XAResource. But what happens when the application with that resource terminates? Is my transaction manager (that 3rd party application) able to commit the operations performed on XAResource?
But I think this won't work and there's a better way to implement such application using classes and mechanisms already implemented.
Can you draw a diagram of your proposed system, showing where the clients and services are along with the databases?
I assume that each AS has JBossESB deployed and they are connected.
Number of services is not limited to three ;-). Neither does number of JBossASes.
I can draw a sequence diagram which would show how services are going to call each other.
Any particular reason you're using an ESB for this? From what I can see, this architecture could be easily supported on JBossAS as it stands, either using RMI/IIOP, JMS, or Web Services. While I fully understand the future proofing that you will gain from using JBossESB, there's a lot of work that needs to be done within the ESB to facilitate this kind of approach over anything other than the transports I've outlined above.
Plus, you definitely don't want to go for a big-bang approach to SOA: take it in small, easy to consume chunks and build up what you need as and when you need it. From that respect, I'd suggest using transactions on native JBossAS and tying in the ESB where (and when) it makes sense.
It was just an example.
We would like to integrate systems which work in different Application Servers (not only JBossAS) and in different environments.
We are responsible only for transactions support.
The product we're working at is a rather long-sighted one. We don't want to integrate one particular system, but to develop a universal transactional engine
Then you should definitely be looking at JBossTS first and ESB when/if needed at all. JBossTS supports Web Services transactions, which are the best way to date for doing heterogeneous transaction service interoperability. Plus they are also working on transaction bridging: end-to-end transactions allowing transactions to flow over different transports, such as IIOP.
When we do support transactions within JBossESB across anything other than JMS and SOAP, it will likely not incorporate heterogeneous transaction services, because that is a significant amount of work to get right. ESB will not be reinventing the wheel, but leveraging what it gets from things like JBossTS.