Are you Service-Oriented? Sign up for the
definitive event here!
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?
1
Print this article
Email this article
Talk Back!
Write to Editor
