How can you effectively use web services in an enterprise environment if you can't use transactions?

Question

The place I'm working at is trying to establish some ground rules, and the debate we're having now is local libraries vs web services for code reuse. Web services seem to be the popular pick in most companies, and that's what most of the developers here are leaning toward.

I just can't see how you can effectively use web services for any serious work. How can I safely execute multiple service calls if I can't use a transaction?

Let's say I have a cron job that grabs customers from our database who meet a certain condition that they need to be notified of. They are sent a fax, an email, and a ticket is created to track the issue internally. That is 3 different service calls that would happen for each customer in a for loop.

If an error occurs anywhere in there, it's possible that, for example, a fax and email is sent to the customer, but a ticket is not created. Or worse, this cron job could contain a bug on that causes it to fail at the same point every time, and it repeatedly emails the same customer. If the libraries were all local, everything could just be wrapped in a transaction, and none of that would happen. But we're using web services in this example.

Note that the email and fax methods actually insert the data into an email queue and a fax queue, which in turn are handled with a cron job. So the call to the "send email" and "send fax" service methods would be safe to rollback.

An option is to put this entire chunk of code in the web service itself, so the web service itself would call the email, fax, and ticket creating methods in a transaction. But then we're creating a web service method just for the use of a transaction; there is no valid reason we would ever actually need to call this method from anywhere except this one cron script.

How would you generally handle this method?

Answer 1

I would handle it by building a SAGA, an abstraction over a long running business process that has internal state, responds to external events, and interacts with external systems.

I would do this because your problem statement is incomplete: what happens when you can't send the email because the server is down? What if the fax system isn't working, but the other two aren't?

When you can't invoke one, should you retry? For how long? What happens if you can't raise a ticket for four hours, should you escalate to someone? Should this get a response, so something needs to track ticket status and escalate after some time? Should you email the original submitter some time, if you can't carry out any notification actions?

Using a saga is a model for when you can't just have a transaction, because it might potentially span hours of real time before the actions are complete - and holding a database lock that long, ouch.

Moving to a SOA means moving away from some of your older assumptions. One of those is that you should write methods and invoke them, to one where you encapsulate the behaviour of the system at a higher level and expose that as services.

If you try and build a web service that is like a local library, your life is going to suck. Approach this from the view that you want services that own data, and own behaviour related to that data, and encapsulate the details inside that.

(As an aside, I suspect that sending those things off from cron is actually part of a bigger business process, right, where cron does stuff, and sends notification as a consequence of that. Your service might well want to expose that entire sequence as a saga instead.)

Anyway, point is: you don't encapsulate things in a service because you want a transaction, and you don't put things in a transaction just to make them atomic. Those are separate concerns, and should be treated separately.

PS: if you use a transaction, don't you email twice if the email sent but the ticket wasn't created? You actually need a finer grained set of updates anyhow.