How to implement long-running transactions over a web service, like unit of work

Question

I'm designing a web service and a desktop client application that uses the web service. The interface has a requirement that you need to be able to perform multiple operations and commit them all at once. The operations are basic CRUD operations (create, read, update, delete).

Here's a rough, and Car-ified example of what the workflow would be:

The problem is that the service calls could be spread out over time. I originally had created a REST web service, but REST by definition shouldn't be transactional. The interface has to be able to commit all operations to the database in one go (upon a Save button click).

Edit: An important stipulation is that given the example above, a Car must exist in the database on the server in order to add seats to it. Within a transaction, that car should only be available to the person (session) who is working within that transaction. That limits the ability to send all the operations to the web service at one time at the end of the workflow.

The options I have considered so far are:

1) Implement distributed transactions using SOAP (WCF) and only commit when Save is clicked on the GUI. Is this possible/a good idea for longer transaction lifetimes?

2) Create a unit of work 'service' that takes operations and executes them all within one transaction on the server.

My question is, is 1) possible, or a good/bad idea? Is 2) a good idea, and are there any patterns/tools for implementing this across a web service (REST or SOAP)? Or is there a different way to handle this problem?

Answer 1

I would try this:

POST /unit-of-work 
   create with response 200
POST /car
   create with response 202
POST /seat
   create with response 202
etc.
PUT /unit-of-work
   set "execute" bit, or somesuch

In this case, car, seat, etc have the unit-of-work specified when they're posted. When the unit-of-work is updated to be "done", all the items are executed.

Another approach would be:

POST /car
   create with response 202
POST /seat
   create with response 202
etc.
POST /unit-of-work response 200

In this case, car, seat, etc have a bit set saying they're not created yet. The unit-of-work should specify what resources belong to it, and then the back end can flip the bit on the other resources so they're created.