At IBM’s annual Impact SOA bash this week, software group head Steve Mills stated that the next frontier for SOA is really not a frontier at all: it’s the basic blocking and tackling of getting Enterprise Service Bus (ESB) backbones to deliver the high levels of ACID reliability and fault recovery now taken for granted with OLTP transaction systems. In other words, when you start thinking about enterprise SOA, you’d better expect rollback, compensation, and high availability features that are taken for granted with online transaction systems.

By comparison, IBM’s message last year was that it was time for SOA to graduate from IT and get driven by the business.

No matter, when we sat down with Mills afterward, we asked him if this meant that SOA was getting, well, kind of humdrum. No more quibbling about whose standard for federated identity to latch onto, what’s most important are the basics of enterprise systems. Replying tongue in cheek that SOA’s always been boring, Mills added that now, the question no longer centers over whether SOA will work. But he notes that with more moving parts, delivering that reliability presents more of a challenge.

Of course, it took about 20 years for enterprise databases to achieve that kind of rock solid assurance, but applying the lessons learned should make that journey quicker today. Nonetheless, compared to database transactions, SOA could involve a far more complicated use case. For starters, there’s the architecture, which calls for a middle tier abstraction layer that separates the service from whatever physical systems implement it. Of course, you could argue that the golden age of transaction processing introduced its own middleware: transaction monitors.

Nonetheless, the dynamic nature of SOA, where services could be orchestrated and service providers swapped at run time, could make delivering ACID reliability for run-of-the-mill OLTP systems appear almost like child’s play. Troubleshooting could require serious detective work. For instance, when a customer history service that is composited from order history and account identifiers in ERP, and interaction history from CRM, where do you start looking when the service fails to execute?