I have to say I greatly disagree with opinions previously expressed that say "just make you service more fine grained" so that you can do more in a single operation.
This will not even come close to solving the problems fixed by WS-Transaction in a real world setting. Take this example: I have a company that sells stuff and we maintain an inventory of the items as I have a limited supply. My company also has a subscription service they sell that is unrelated to the items themselves, but I still have to charge a customer for the services. I have a warehouse that has my supply of items and I have a system that manages that inventory. It was a prebought system that I have the source code for and it's written in .NET. Finally I have a system that stores my customers accounts and does billing written in Java. This system is utilized by other systems to bill customers for other services (such as the subscription service). My customers use my website written in ASP.NET to make their purchase. So one day one of my customers decides he would like to buy something from me. He visits my website, selects the product, enters his customer information and clicks "Purchase". Now my .NET web application has to contact the warehouse computer to first check availability and remove the item from inventory. I cannot process the payment first because if I processed the payment, then checked availability, the item may not be available again (because someone else bought it). Next I process the payment. If the payment is unsuccessful (mabye because their account doesn't have any money in it or because of some other business reason [maybe they've bought too much this month]), I want to roll back my transaction all together. That way the inventory system has the product back in inventory again. If you say "Well them make a call to the inventory system to put it back", but what if the reason the payment processor failed was because of an intermittent network issue which is still occuring, then I'll have an item that was taken out of inventory and never put back. I'd then have to write another process to check on inventory on some regular basis and put unused inventory back. And if inventory is tight, then that might prove to be costly and it's possible that the data in the system wouldn't even differentiate these items from ones that should be removed. Next step if the payment was successful is that I need to contact the warehouse system to tell them to ship the item. If for some reason when I went to contact the warehouse system, the transaction failed, I need to roll back the payment and put the item back into inventory again. Same problem as the previous issue. Finally I need to send an e-mail to them which I definitely cannot do if any part of the previous transaction failed. There is no option to "make coarser services" available as I already have systems that need to be integrated that are all separate and the functionality they provide can't be "inserted" into another application (many times because it's written in a different language all together). Since they're cross platform (some java some .NET), I have to use a platform independent protocol such as SOAP. If all of them supported WS-Transaction and WS-Coordinator (which IIS, Atomikos ExtremeTransactions, and JBoss AS will support) then the system would function perfectly without the need for additional application logic (which becomes extensive the more complex my system becomes) and even if I did add the additional application logic, I wouldn't get the disaster recovery I need in case of more extreme system failures. But yeah, let's make suggestions that violate the principals of SOA (i.e fined grained services) because "it's easier" than doing it the right way. Good luck making modifications to your 3000 "coarse grained services" when you need to add a single parameter across all of them when you could have wrote 6 fined grained services and integrated using distributed transactions. -- View this message in context: http://cxf.547215.n5.nabble.com/WS-specification-for-transaction-tp1618539p4366269.html Sent from the cxf-user mailing list archive at Nabble.com.
