Transaction rollback and web services

Question

Given an example of calling two web services methods from a session bean, what if an exception is thrown between the calls to two methods? In the case of not calling the web services the transaction will rollback and no harm done. However, the web service will not rollback. Of course, even with a single web service there is a problem. While this is a generic question I am interested in solutions having to do with EJB session beans.

An easy and customized answer would be to add a special "rollback method" to the web service for each "real functionality" method. What I am asking for is some standardized way to do so.

Answer 1

Wikipedia article on distributed transactions may be helpful.

Answer 2

The article describes the C# exception handling in a web service. Their is a lot of code inside where the hadling is described. The handling for Java shoul dbe simiular Exception Handling in Web Services

Answer 3

A number of techniques are evolving, but the problem is still sufficiently cutting edge that the standardization process has not yet provided us with a totally portable solution.

Option one, you can make the web services transaction aware. This of course assumes you have control over them, although writing a transaction aware proxy for non-transactional services is also an option in some cases.

The WS-AT and WS-BA protocols are the leading standards for transactional web services. Unfortunately they specify the protocol only, not the language bindings. In other words, there is no standard API at the programming language level. For Java the nearest thing is JSR-156, but it's not ready yet.

Then the problem becomes: how to tie the EJB (i.e. JTA/XA) transaction to the WS one. Since the models used by the WS-AT and XA protocols are closely related, this can be achieved by means of a protocol bridge. Several app servers provide something alone these lines. JBoss presented theirs at JavaOne - see http://anonsvn.jboss.org/repos/labs/labs/jbosstm/workspace/jhalliday/txbridge/BOF-4182.odp

Note that the protocol bridging technique can also be used the other way around, to allow an EJB that uses e.g. an XA database backend, to be exposed as a transactional web service.

However, the locking model used by two phase commit transactions is really only suitable for short lived transactions in the same domain of control. If your services run in the same company datacenter you'll probably get away with it. For wider distribution, be it geographical or administrative, you probably want to look at WS-BA, a web service transactions protocol specifically designed for such use.

WS-BA uses a compensation based model that is harder to program. It's essentially based on the technique you mention: the effect of service methods is undone by calling a compensation method. This can be tricky to get right, but a JBoss intern did a rather nice annotation framework that allows you to define compensation methods with minimal effort and have them driven automatically. It's not standardized, but well worth checking out if you choose this approach: http://www.jboss.org/jbosstm/baframework/index.html

Answer 4

Web Services-Coordination (WS-C) and Web Services-Transaction (WS-T) specifications developed by Microsoft, BEA Systems and IBM are used in such cases as I know. You can start from reading Web services transactions and A comparison of Web services transaction protocols articles provided by IBM to make it clear.

Answer 5

Hi,

Actually, you usually don't just need a custom rollback method but also a custom commit method. Otherwise, you get into problems like those found in the WS-BA standard.

Just check out http://www.atomikos.com/Publications/TryCancelConfirm for a detailed article. The features mentioned there are available in Atomikos ExtremeTransactions... That product also supports classical 'ACID' style web service transactions.

HTH

Guy

Disclaimer: I work for Atomikos