On 07/21/2010 02:30 PM, Daniel Kulp wrote:
In general, most people that are familiar with it generally recommend refactoring the services to avoid the need for the distributed transactions entirely (coarser grained services work well). It generally simplifies things quite a bit, but also helps with performance as it's really just the real data going across. Internally, the service uses transactions, but it's not really exposed outside the service. Using things like transactional beans or using JMS with it's transactions or even the spring transactional things all work quite well.
Yes, that's true for WSAT. It's not a great deal of use for integrating services across multiple company domains because your web services can become hostage to failures or performance lags in the ones they are yoked too. Alternatively, if you have control of all the services then you can usually implement them locally within one JVM/database and have no real need to use distributed transaction coordination.
The shame is that there is no great take up of WSBA which attempts to resolve these problems with integrating disparate web services, providing a basis for more workflow oriented transactions. In particular, it's relaxed isolation model allows participants to commit early and compensate in case of failure by sluggish partner services, thus boosting throughput. But WSBA, even more so than raw WSAT, requires the web service programmer to manage the transaction lifecycle (cancel, complete, close, compensate) as well as adding the need to conjure with failure or read-only situations (exit, fail, cannotComplete). It's much more complicated than WS-AT, especially WS-AT combined with JTA bridging which can easily be reduced to a more simple programming model. WSBA transactions don't easily map to JTA so you cannot easily implement WSBA services using XA resources for the underlying data management. There's probably a big opportunity out there for anyone who can simplify WSBA (or equivalent protocol) enough to make it usable by non-transaction heads while still benefiting from the ability to coordinate distributed web services.
In the few cases I've seen where they really needed to expose transactional things, most developers actually find it easier to just add methods like: TransactionId startTransaction(...); void commit(TransactionId ...); void rollback(TransactionId ...); to the service and just add the TransactionId to each method that requires the transaction, either as a param or soap header or something. Yes, it's not a full transaction API, but for simple cases, it may be enough and it would be completely interopable between stacks and such.
This is all very well but the key to any _real_ transaction implementation is 'durability'. Implementing this sort of protocol so that it can hanlde crash recovery and still guarantee atomicity, consistency and isolation is _very_ hard. Most programmers get it wrong many times before it is bullet-proof (speaking from experience here :-).
regards, Andrew Dinn -----------
