7 Replies Latest reply on Aug 31, 2007 8:10 AM by marklittle

    Distributed transactions using JBossESB

    sl4ve

      Do you know a way to handle distrubuted transaction using ESB?
      What I want to do is to start a transaction, do some work and than send a message to the queue and let the application terminate. Another one should receive that message and also do some work in the scope of the same transaction. Nextly it calls back the first application (which would start in the same state it has been before terminating - we got a state manager ready to handle this) and the first application decides either to commit or roll back the whole transaction.

      Or maybe there is some third-party application which manages the transactions on behalf of the others applications?

        • 1. Re: Distributed transactions using JBossESB
          marklittle

          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?

          • 2. Re: Distributed transactions using JBossESB
            sl4ve

            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.

            • 3. Re: Distributed transactions using JBossESB
              marklittle

              Can you draw a diagram of your proposed system, showing where the clients and services are along with the databases?

              • 4. Re: Distributed transactions using JBossESB
                sl4ve

                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.

                [img]http://slave.dinhz.eu/esb.jpg[/img]

                I can draw a sequence diagram which would show how services are going to call each other.

                • 5. Re: Distributed transactions using JBossESB
                  marklittle

                  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.

                  • 6. Re: Distributed transactions using JBossESB
                    sl4ve

                    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

                    • 7. Re: Distributed transactions using JBossESB
                      marklittle

                      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.