6 Replies Latest reply on Jul 12, 2007 6:14 PM by Brice Ruth

    JTA + WS-TX on client

    Brice Ruth Novice

      When the client of a transactional web-service is using JTA locally to manage transactions to say an Oracle DS, is it necessary/advisable/possible/etc. to "automagically" tie in the establishment of the CoordinationContext with the overall JTA transaction, outside of the business logic of the client itself?

      So, if I have something like:

      @Transactional
      void doSomethingImportant() {
       ...
      }
      


      And the advice that's attached to @Transactional currently does something like:

       Session sess = sf.getCurrentSession();
       sess.beginTransaction();
       method.invoke();
       sess.getTransaction().commit();
      


      Should the WS-TX stuff get incorporated in the advice? Should something be registered with the local JTA to get things setup when sess.beginTransaction() is invoked? Should the WS-TX stuff just be in doSomethingImportant() (or a sub-method of that)?

      I'm still reading through the programmers guide - if this is clearly addressed in there, just let me know.

      Thanks,
      Brice

        • 1. Re: JTA + WS-TX on client
          Jonathan Halliday Master

          Transaction bridging is not discussed in the programmer's guides yet, because it's not part of the product. For the usage patterns you need to look at the JavaOne presentation.

          I'm afraid your example above does not give me enough context to understand your use case. Is the code above EJB, Web service or both?

          • 2. Re: JTA + WS-TX on client
            Brice Ruth Novice

             

            "jhalliday" wrote:
            Transaction bridging is not discussed in the programmer's guides yet, because it's not part of the product. For the usage patterns you need to look at the JavaOne presentation.


            Right, I have the JavaOne presentation and if I'm understanding it right, its targeting the WS-TX -> JTA bridge (JTA on the service end).

            This use case is the mirror of that, I suppose, where the client that is making the WS-TX call and has a local JTA transaction. Essentially, the web service client is also doing some local transactional work with a DataSource (say, Oracle) and needs to tie the success/failure of all of that together.

            Instead of the client purely calling remote web services and wanting to tie all the web services invocations together in one transaction, the client is a bit of a hybrid, invoking web services but also manipulating his own data store.

            Here's a concrete example. We receive a document via MQ. Our message handler then processes the document data and looks up some business rules from Oracle (readOnly). Based on the business rule values, we may need to send a message to System A via MQ and/or send a message to System B via MQ. We will also need to persist meta-data from the document in Oracle and invoke a web service one or more times, depending on the type of document we're receiving. The web service invocations will launch business processes or resume suspended tasks (yes, we're talking to jBPM here).

            1. The execution of the business processes on the remote web service will be contained within that web service's JTA transaction.

            2. The reading and insertion of document data (business rules / meta-data) will be done in the client's JTA transaction to Oracle

            3. The pushing of messages to MQ may need to be in the context of an XA transaction (if our infrastructure supports it and its important to the business).

            Does that help more?

            • 3. Re: JTA + WS-TX on client
              Jonathan Halliday Master

              > Does that help more?

              Yes it does. This actually matches a use case from another client I came across recently. It's essentially a case of propagating a JTA transaction using a Web Service transaction as a carrier.

              The client begins a JTA transaction and calls a web service. The bridge needs to transform the JTA transaction into a WS-AT transaction and send the context to the web service.

              The web service then needs to turn it back into a JTA transaction, since that's what the jBPM (or more exactly the persistence system behind it) expects.

              When the client calls commit (or rollback) on the JTA interface, the call needs to be transformed into a WS-AT prepare/commit message exchange sequence, which the bridge on the remote end turns back into JTA (well XA really) prepare/commit calls.

              To achieve this you'll need to roll your own bridge for transforming JTA->WS-AT since, as you have identified, the current prototype only goes the other way. Or you could just wait a few week for me to get around to doing it.

              • 4. Re: JTA + WS-TX on client
                Brice Ruth Novice

                 

                "jhalliday" wrote:
                To achieve this you'll need to roll your own bridge for transforming JTA->WS-AT since, as you have identified, the current prototype only goes the other way. Or you could just wait a few week for me to get around to doing it.


                At this point, we're just trying to get our heads around everything. I think we're understanding things more and more now. So, from what you write, it seems that JTA (via hooks) should be managing the WS-AT transaction semantics, not the client's business layer code, correct?

                That being the case, is the "first" web service call made by the client going to invoke an outhandler (or something in the processing chain) that contacts the transaction manager which will cause a coordination context to be created & associated with the local JTA transaction? Then subsequent web service calls would simply participate in the same context and finally when commit() is called on the local JTA transaction, the transaction manager will notify the coordinator to drive the WS-AT transaction to completion, right?

                We're just looking to figure out at what layer we're going to be plugging into the WS processing chain and which hooks into JTA are used. This will help us get a clear picture of what's going on, which we'll need, because our service stack isn't JBossWS (or any other JAXRPC-based stack), but rather XFire. A while back we already adapted the JAXRPC in/out handlers shipping with XTS to XFire's in/out handler syntax & JDOM manipulations. We're trying to expand our understanding of the interactions since it seems we may be needing to do quite a bit more XFire/JTA integration work to support this cleanly. (Btw, does a coordinator service come packaged w/ XTS? - I haven't gotten this far yet in my reading/analysis)

                Thanks again for all your time in explaining this. It is truly appreciated.

                Cheers,
                Brice

                • 5. Re: JTA + WS-TX on client
                  Jonathan Halliday Master

                  If we consider the bridging to be implemented as a Handler in the web services stack, then outbound from the client (JTA->WS-AT) it will run before the Handler that serializes the WS-AT transaction on the Thread into a chunk of xml. On the inbound side (WS-AT->JTA) on the web service host the ordering of the handlers is reversed. The context serialization handler needs to mess with the xml, the bridge does not, hence the bridge is actually fairly easy to move between WS stacks.

                  So much for the propagation of transaction context on business method calls. Transport of the transaction control messages is a different issue. Right now XTS uses its own WS stack for that, so you'll need to run it on each end too.

                  Note that's well be supporting XTS on JBossWS 2.1, which is essentially an integration layer over JBossWS native, CFX and Metro. See http://www.jboss.com/index.html?module=bb&op=viewtopic&t=112417 I can't promise any particular timeline on this though.

                  • 6. Re: JTA + WS-TX on client
                    Brice Ruth Novice

                     

                    "jhalliday" wrote:
                    If we consider the bridging to be implemented as a Handler in the web services stack, then outbound from the client (JTA->WS-AT) it will run before the Handler that serializes the WS-AT transaction on the Thread into a chunk of xml. On the inbound side (WS-AT->JTA) on the web service host the ordering of the handlers is reversed. The context serialization handler needs to mess with the xml, the bridge does not, hence the bridge is actually fairly easy to move between WS stacks.

                    Right, OK.

                    So much for the propagation of transaction context on business method calls. Transport of the transaction control messages is a different issue. Right now XTS uses its own WS stack for that, so you'll need to run it on each end too.

                    Ah, OK - so besides the handlers, XTS also provides services to do the various things needed for transaction control. Cool.

                    Note that's well be supporting XTS on JBossWS 2.1, which is essentially an integration layer over JBossWS native, CFX and Metro. See http://www.jboss.com/index.html?module=bb&op=viewtopic&t=112417 I can't promise any particular timeline on this though.


                    OK, so that's nothing short of awesome. Wow. I was a bit skeptical when the new JBossWS was launched (still being based on JAX-RPC, in 2006), but this is sweet. We will definitely be tracking this. Thanks!