I implement a WCF payment service with methods like Deposit(amount) and Withdraw(amount). I want to garantee that payment transaction will not be performed if a service method call throws an exception on the client-side (in case of network-related problems leading to the lost or corrupted response).
Should service clients spawn a distributed transaction just to make single method call? Or there is a better approach?
With netTcpBinding, supporting DTC transactions accross the network is fairly trivial. Your clients won't even be aware that they're propagating a transaction for the service to enlist in as the WCF stack hides all this.
Doing it across the internet however is a huge difference, and you will be forced to expose your service across HTTPS and configure WS-Atomic Transaction support on your endpoints.
If you can avoid exposing the endpoint on the internet then that would be easier.
A better solution IMO than this would be to provide a non-transactional endpoint for Deposits and then a separate service where the client can request the deposit they just made.
Then the client can just call the Deposit operation again if they can't find their deposit. To support this model you would need to make sure your service could not process the same deposit more than once.
A further alternative (though more elaborate) is you expose a "callback service" on the client which the service can call with a acknowledgement. The minimum number of one way calls you require to guarantee delivery in this manner is 3:
