Many folks out there are no doubt dabbling with building real service-oriented infrastructures for their organization. Quite frequently these days, I run across enterprise architects, technologists, and even the occasional CIO that are seriously looking at building this layer into their architectures.
But as many of us are finding out, there is often a sense of cognitive dissonance when trying to formulate reliable, meaningful, stable applications out of a myriad of web services, which can be distributed locally or anywhere over the Internet. Those building sophisticated, useful SOA applications find the Internet, and the entities which operate over it, very non-deterministic and frequently built on top of what ultimately amounts to shifting sands.
A truly brilliant blog entry I came across earlier today did a magnificent job summarizing the huge tension between the need for us to construct meaningful functionality out of SOA services while at the same time dealing with the buffeting winds that make up the Internet. Written and posted yesterday by Mark Little, Chief Transaction Architect over at Arjuna Technologies, the piece does a remarkable job of painting a clear mental picture of our challenges:
"Thus we are presented with a paradox. The Web services platform provides a service-oriented, loosely coupled, and potentially asynchronous means of propagating information between parties, whilst in the background we have traditional transaction processing infrastructures whose behavior is neither or mutually interoperable. Furthermore, the fact that transactions in these systems are assumed to exhibit ACID properties potentially leads to problems when exposing resources to third parties, since it presents opportunities to those parties to tie up resources and prevent transactions from making progress."
Expectedly, Mark presents the solution as a technical one, with the traditional alphabet soup of standards (namely by invoking OASIS's WS-CAF and it's related standards WS-Context, WS-CF, WS-TXM) but makes a truly compelling case, unlike some proposed additions to the web services stack that I've seen.
Figure 1: The Web Services Stack with WS-CAF
The traditional transaction processing systems that we all cut our teeth on were designed in a naive world, a world where designers believed that applications might have to talk to only one or two other systems to do transaction coordination. Now, with service-oriented architectures pushing us to build long-running transaction-based systems that can span a dozen service-based applications and a similar number of days, that world-view is just not sustainable. WS-CAF provides an entire suite of powerful technologies that can be put to bear to solve these problems and do things that technologies like XA could never dream of attempting.
Mark has does the web service industry a huge service by writing his in-depth blog entry, I encourage you to study it with care.