Sagas vs. protocols

The basic WS protocols sprang out of a real concrete need for a simpler way to make two applications talk across the network. The lessons learned from DCOM, RMI, and CORBA have been learned and now, functionality wise, it provides what I had with sockets, similar to RPC but (preferrably) with a very different programming model). This is a great tool for integration.

Now I wonder about the WS-ReliableMessaging (+ queuing) and WS-AtomicTransaction protocols. They are designed to detect and recover from the problems you encounter in any distributed system. The goal is to hide a whole bunch of possible weird failure modes from the application programmer. This has been attempted before, most recently with COM+ and J2EE. The problem with this approach is that unless everything in your system understands these protocols, they can't protect you completely. For instance, imagine you have a Web service that saves data to disk in a temporary file. Message delivery to the service may be reliable and the WS may be transational, but if the file system is not those protocols don't help you very much. Similarly, imagine that your WS is a veneer on top of an existing legacy system that doesn't know anything about these protocols. I think of this as a variation of “the last mile problem”. Unless these protocols go everywhere, they don't really solve your problem. The trouble is that driving these protocols out to all of your legacy apps takes a lot of time, if it's possible at all.

Instead of pushing advanced protocols for failure detection and recovery out to all the things you have to talk to, what if you keep them centralized in a system that knows how to durably roll forward or backward using basic WS invocations? In other words, build a driver application that has the logic to detect errors, retry and, if necessary, rollback by invoking other application operations (a saga). Yes, this means that your apps have to support this sort of functionality, but it might well be easier to do this than to drive in deep support for durable protocols. The driver application could be an orchestration in Biztalk or something similar or it could be an app in C#, Java or VB.NET that uses a database to keep track of forward and reverse progress.

Would that model would get you where you want to go more easily or am I just slipping (further) off the deep end?