Transactions and Services
I haven't got a definitive answer on this, but I came up with a question today.
Q: Are transactions and services mutually exclusive?
This query is based upon the fact that a service is inherently self contained - that's why it's a service. On the other hand, a transaction in many ways implies containment. Now, I'm sure that technically we can implement a transaction object and mechanism that would allow Commits and Rollbacks across multiple services in a singular fashion. It's clearly achievable (Turing machines and all).
But, does that mean that we should do that? If we're calling a service, it's up to the service to figure out how long to take over executing; we can't assume anything about how much load it's under, what it's internal state is, etc. So how can we instruct one service to lock resources based upon the presumed state of another? With short-running (synchronous) calls this is a problem, but with long-running (asynchronous) calls it's a nightmare. It kind of implies that a service should have to take into consideration the context in which it's being used, and what other service-chain a consumer might be plumbing it into. Again, this would turn the typically introspective service on its head.
I toyed up with the idea of a separate transaction service that everything that's "enlisted" in a transaction calls down into to try and tip the balance back to the main service being in control again. It still doesn't solve this issue of containment, though.
I'm going to leave this topic for a while and see what others come up with. My personal opinion is that although SOA is the current buzz-word architecture, it's merely a step down the road, and that when certain things start getting shoe-horned into a technology, it's maybe time for a new TLA and a new paradigm. The generation N+1 replacement for SOA will probably get around the issue of data being disconnected and out of date. At this point the transaction problem will go away. And I'll be posting on that shortly... (I wonder how long it'll be before the term "serviceable object" comes into common use)