Hi!

In this post, I will examine several different approaches to work properly against web services. I will explain the question (or problem, you can define it however you want) from the real life: You are working on an HR registration application and you want to register a new employee to the system, but the DB that holds all the employees details is located in remoted server. The actions that the application need to do are:

1. Check if the username is already exist in the repository of contents (first WS).
2. Register the user and save her details to the system DB (second WS).
3. Send a registration information to the user that all her details has been feed (third WS).

As we saw, every WS will do a single action, and the last 2 ones are dependent each other.

Now, the question that is being asked is how to handle those actions in exceptions cases, should I want to roll back or to complete the whole bunch of actions.

The approaches are:

1. Repeated requests handling: This way handles the situation that the request is already has been sent to the remote server (by web service ofcourse), and we will want to know if the request handling is over. The way is to attach transaction indetifier to the request. By that, if the server is still busy (while processing the resuest), it will send an appropriate message to the client (status ID). This solution comes to prevent duplicates mesaages requests to the server. One more thing... when implementing this sulotion, you need to consider and to support large number of transcactions (for further cases). By that, the client needs to know the ID of the transaction before sending the request to the server.
2. Two-Phase commit: Before I start speaking the solution, I will explain this term: The two-phase-commit protocol is a distributed algorithm which lets all nodes in a distributed system agree to commit a transaction. The protocol results in either all nodes committing the transaction or aborting, even in the case of network failures or node failures. Now, the common approach, claims that algorithm is not "healthy" to use when working over web services, because if the web service is fails (or shuts down) in a middle of a transcation, there is a chance that the remote server won't know to send a message regarding the transaction state. The solution recommended here is to devide BIG transaction(s) to small transactions, when every small transaction will be handled by one web service. One more important thing is to plan properly the transactions flow, to prevent as much as minimum loss of data (if accured). I recommend to execute each action over one web service, and to call to a transaction manager web service that will be responsable to all the web services actions.
3. Queued Processing: This approach claims that as long as the request is OK (no exception has been received), we will assume that action has been completed properly. To implement this approach you need to create a requests' queue (the requests that we will want to execute). Now, if no exception has been received, the queue will continue executing the further ones. If an exception has been received, the mechanism will roll back the related requests.
4. Transaction Locking: When calling a web service (which is a part of a transaction), all its related resources will be locked in purpose not to allow other users to execute it. Real life example is withdrawaling cash from an ATM. When the user withdrawals the money from the machine, the transaction and his related data in the database is being locked, to prevent mismatch.

In summary, I spread here 4 different approaches to handle transactions over web services. I will be glad to have some comments if you have some.

Wellness untill next time, see you...