On Wednesday 21 July 2010 5:53:13 am Anto wrote: > Daniel Kulp wrote: > > WS-* stuff is always "on the roadmap", but whether they get implemented > > or not > > really depend on if someone steps up to do it (or if one of the companies > > that > > supports CXF has a paying customer that requires it). > > Just curious, why no paying customers are not demanding it? Is it that > there are other ways to implement transactions other than WS-* specs? Or > is it not a practical solution for transaction management?
As Andrew and Oliver kind of alluded to, the WS Transaction spec is a relatively poorly written and specified spec. It exposes a lot of transactional requirements to the web service client developers which, in general, ends up not being a good idea. It's also relatively chatty causing extra performance issues and such. 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. 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. -- Daniel Kulp [email protected] http://dankulp.com/blog
