Hi Anto I know customers which use Web Services for about 9 years. They never had the requirement for WS-Transaction support because you could sort this out by the design of the service (WSDL) or they came to the conclusion that transaction support would have been a nice feature but not really required.
Instead of calling for instance two operations of a service(s) (transaction context) you design a less fine grained service which does the work in one operation you wanted to seperate in two seperate operations. The webservice is deployed in a application runtime which supports local transactions like J2EE/EJB. For instance, you define the stateless session bean to create a new transaction for each incoming request. The above approach fits well as long as you don't combine (and tightly couple) different business components. In such a case, I would have some objections from an enterprise architecture point of view. Thanks Oliver ________________________________________ From: Anto [[email protected]] Sent: 21 July 2010 11:53 To: [email protected] Subject: Re: WS-* specification for transaction 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? Anto -- View this message in context: http://cxf.547215.n5.nabble.com/WS-specification-for-transaction-tp1618539p1698737.html Sent from the cxf-user mailing list archive at Nabble.com.
