Understanding WS-TX

[ruthbd]

Help me understand how WS-TX works (I have RTFM, at least scanned).

I have an application, it needs to call one or more web services and modify some local objects based on that, finally persisting those objects via Hibernate to Oracle. If anything goes wrong with a web service or persisting the local objects to Oracle, everything should roll-back. Let's assume that the web service(s) are doing some work and then updating Oracle.

The application is (now) using JTA via JBossTS on JBoss 4.0.3SP1. Seems to work fine (thank you Spring). To incorporate WS-TX, as I understand it, the following needs to happen.

1. before the first web service call is made, a transaction context needs to be requested
2. web service calls are made, adding transaction info to the soap headers

At this point, everything is tied into a single transaction, correct? The transaction context created & passed to the remote services is tied to the JTA transaction being used for Oracle? Also, is JTA used on the remote services to link the remote Oracle transaction to the Transaction Context? Finally - does the application then have to do something to allow all the transactions to commit, outside of committing the original JTA transaction? Or is that handled automagically?

Once I can get my head around the general architecture/sequence of WS-TX communication, and what parts are in play on the local & remote sides, I'll be well off.

Thanks for any tips.

Cheers,
Brice

[ruthbd]

OK, I'm looking through the samples for xts and I see something called a UserTransaction. I have come across the UserTransaction in the docs, but what I am not clear on is how the UserTransaction is related to the JTA transaction. Same thing? If not, what's the difference and how does the JTA transaction relate to the UserTransaction?

Also, I see that there's a separate JaxRPCHeaderContextProcessor for the service and the client, which makes sense - one accesses the client transaction and inserts the transaction context into the SOAP header, one extracts the transaction context from the SOAP header and associates a local (to the remote service) transaction with it.

I am still not clear with where these things fall into place with JTA - in our application, Spring manages transactions declaratively on our business controllers - so when our code is running, a transaction has already been started (with respect to Oracle) - that transaction context would somehow need to be connected to the UserTransaction, right?

There's some visuals in the docs (HTML) that look like they'd be awfully useful to get a big-picture grip on this, but they're reproduced soooo tiny that its hard to see what's going on.

Cheers
Brice

[marklittle]

"ruthbd" wrote:
Help me understand how WS-TX works (I have RTFM, at least scanned).

I have an application, it needs to call one or more web services and modify some local objects based on that, finally persisting those objects via Hibernate to Oracle. If anything goes wrong with a web service or persisting the local objects to Oracle, everything should roll-back. Let's assume that the web service(s) are doing some work and then updating Oracle.

The first thing you need to remember is that the Web Services transactions specifications say nothing about what happens behind the service endpoint. That's the same as any Web Service specification. So issues such as interacting with an Oracle db are not covered and definitely out of scope of the specifications.

The application is (now) using JTA via JBossTS on JBoss 4.0.3SP1. Seems to work fine (thank you Spring). To incorporate WS-TX, as I understand it, the following needs to happen.

1. before the first web service call is made, a transaction context needs to be requested
2. web service calls are made, adding transaction info to the soap headers

At this point, everything is tied into a single transaction, correct?

No. At this point you have a Web Service transaction that can span multiple addresses/processes and, diving into implementation details for a second, the context is propagated implicitly between the sender and receiver. At the receiver, when the service logic gets invoked, the thread doing the work will be associated with the propagated transaction, but that's as far as it goes. If you then do work that is in the scope of another transaction (JTA or Oracle local transaction) then it is up to you to ensure those transactions are somehow controlled by the propagated transaction - assuming this is what you want to do. That is, as far as the WS-TX specifications go. As far as the product goes, we want to go further and take the "you" out of the loop as much as possible, i.e., do this bridging automatically. It's something called end-to-end transactions and is unfortunately not in the 4.2.2 release.

The transaction context created & passed to the remote services is tied to the JTA transaction being used for Oracle?

No.

Also, is JTA used on the remote services to link the remote Oracle transaction to the Transaction Context?

No. However, if you look at the trailmap you'll see how you can mix the different transactions manually.

Finally - does the application then have to do something to allow all the transactions to commit, outside of committing the original JTA transaction? Or is that handled automagically?

Once I can get my head around the general architecture/sequence of WS-TX communication, and what parts are in play on the local & remote sides, I'll be well off.

Thanks for any tips.

Cheers,
Brice

[marklittle]

"ruthbd" wrote:
OK, I'm looking through the samples for xts and I see something called a UserTransaction. I have come across the UserTransaction in the docs, but what I am not clear on is how the UserTransaction is related to the JTA transaction. Same thing?

Same name, same concept, but different implementation: these are not JTA transactions you are creating through this API.

If not, what's the difference and how does the JTA transaction relate to the UserTransaction?

Hopefully my previous post explained that.

Also, I see that there's a separate JaxRPCHeaderContextProcessor for the service and the client, which makes sense - one accesses the client transaction and inserts the transaction context into the SOAP header, one extracts the transaction context from the SOAP header and associates a local (to the remote service) transaction with it.

I am still not clear with where these things fall into place with JTA - in our application, Spring manages transactions declaratively on our business controllers - so when our code is running, a transaction has already been started (with respect to Oracle) - that transaction context would somehow need to be connected to the UserTransaction, right?

Correct. If you have access to the transaction and can drive it directly through 2PC then you can simply wrap it in a WS-TX resource and enlist it directly.

There's some visuals in the docs (HTML) that look like they'd be awfully useful to get a big-picture grip on this, but they're reproduced soooo tiny that its hard to see what's going on.

Cheers
Brice

Check out the source, available from the same download site.

[bdruth]

OK, so the transaction context created locally in the client application and propagated to the remote application is not tied to JTA in any way, right? I think that's what I got from this.

Then, there's something called end-to-end transactions which would presumably do more of what I'm talking about, automatically tying all these different transactions together. Otherwise, I have a local JTA transaction in the client application, a UserTransaction that ties the WS invocations together, and however many different types of Transactions (JTA or otherwise) beyond the service endpoints of the services that are invoked, right?

And am I correct in understanding that it is possible to get things coordinated/tied together manually at this point, its just not handled automatically? And there's some info in the trail map on how to do this?

Cheers,
Brice

[marklittle]

"bdruth" wrote:
OK, so the transaction context created locally in the client application and propagated to the remote application is not tied to JTA in any way, right? I think that's what I got from this.

Then, there's something called end-to-end transactions which would presumably do more of what I'm talking about, automatically tying all these different transactions together. Otherwise, I have a local JTA transaction in the client application, a UserTransaction that ties the WS invocations together, and however many different types of Transactions (JTA or otherwise) beyond the service endpoints of the services that are invoked, right?

Yes.

And am I correct in understanding that it is possible to get things coordinated/tied together manually at this point, its just not handled automatically?

All of the hooks are there.

And there's some info in the trail map on how to do this?

Cheers,
Brice

I haven't looked at the trailmap code for a long time. Maybe Jonathan or Kevin can answer this one. However, the trailmap does demonstrate the use of WS-AT and WS-BA and I recall it does (or did) use backend datasources.

[ruthbd]

OK - I'm glad I'm getting a better understanding of this.

First, can you point me in the direction of which of the PDFs I should be looking in for more information on the "hooks" that I'll need to work with to tie things like JTA into the WS-TX UserTransaction, both on the local & remote sides?

Second, you mentioned that end-to-end wasn't available in 4.2.2 - is that something that's on the roadmap for a particular release/timeframe?

Thanks a ton for the quick responses, Mark - very much appreciated.

Cheers,
Brice

[kconner]

The trailmap doesn't include any external resources. The demo resources are backed by internal data structures only.

We do have the bridge on the roadmap but it is not scheduled until 4.6 at the moment.

http://jira.jboss.com/jira/browse/JBTM-44

[ruthbd]

The trailmap doesn't include any external resources. The demo resources are backed by internal data structures only.

We do have the bridge on the roadmap but it is not scheduled until 4.6 at the moment.

http://jira.jboss.com/jira/browse/JBTM-44

Good to know, Kevin - thanks.

So, 4.6 should be available Q1 of '07, right? :-) j/k!!