views:

295

answers:

4

Does anyone have any insight into transaction options available over web-service calls? 1.) There are two applications that we have that need transactional communication between them. 2.) App1 calls a web service on app 2 and then makes some changes to its own db. the call on app2 and the changes to it's own db need to be co-ordinated. How can we do this? what are the possible options ?

A: 

You make the webservice call and if its successful do change in your own DB. If changing your own DB fails then call the webservice to revert the changes done in earlier call. For this to happen the webservice must provide the revert functionality.

For example, the webservice have createUser function then they should have deleteUser function.

Bhushan
A: 

It depends what technology stack you are using. In .Net WCF offers transaction features, otherwise the only thing that you can do is minimize the timespan an error can occur.

In previous applications, I've given the service a token to the web service. When the service returns (sync or async) it returns the token. The token has an embedded timestamp. If the timestamp has expired then the transaction is aborted, if not I assume the web service call was successful.

After successful return of the webservice call, the NEXT method call is to record the transaction within your system. This creates a very small window where the system behind the web service and your system will be out of sync. It also lessens the chance that an unexpected error will occur that will prevent the update/insert on your side.

Chuck Conway
+1  A: 

see also transaction-rollback-and-web-services

A: 

Hi,

You could try Atomikos ExtremeTransactions. It includes support for WS/SOAP transactions whose rollback spans multiple sites.

Guy

Guy Pardon