Service-oriented architectures

Enterprises are leveraging the SOA model to lay the groundwork for a more efficient and flexible IT future

To understand and apply the principles of SOA, you’d think we would have to agree first on what we mean by a “service.” To a surprising degree, we haven’t, but this is hardly the first time a powerful idea has been tricky to nail down. Definitions of “objects’ and “components” -- the ideas that powered earlier phases of software’s evolution -- were just as elusive.

Writing recently for ACM Queue, ObjectWatch CEO Roger Sessions offered one useful way to think about these successive waves of technology. All three models are ways of packaging code for reuse, he suggests. They differ in terms of where and how the code runs. Objects share a common operating system process and execution environment -- for example, Linux, Windows, Java, or .Net. Components live in different processes but share an environment. Services cross both process and environment boundaries.

The environment for Web services and SOA is the global Internet. Of course, that’s been true for quite a while. A decade ago programmers began using the Web’s Common Gateway Interface to publish and consume services. When we build and deploy services today -- using REST (Representational State Transfer) and XML-over-HTTP on the one hand, or SOAP, WSDL, and the WS-* specs promoted by Microsoft and IBM on the other -- we build on that common heritage. SOA extends the tradition along two axes: data representation and data communication.

Everyone agrees XML is the lingua franca of data representation, but there’s lively debate about how to use it. XML Schema, for example, is an optional feature that sharply divides communities of practice. Do interoperable services require strict formal data definition or do they require fuzziness? The perplexing answer is both -- at different times, in different ways, for different purposes.

In the world of SOAP and WS-*, XML Schema typically governs the contracts between services. If the XML document that represents a purchase order isn’t a valid instance of the relevant schema, it’s time to throw down the warning flag. And with XML Schema, any process, running anywhere -- even offline -- can perform that validity check. Let’s say that while flying to Chicago you use an InfoPath form to create a purchase order and then e-mail it to the approver when you land. The approver can focus on the business aspects of the order, secure in the knowledge that he or she has received and will relay to the order processing service a document that will be acceptable to that service.

What about the stuff that won’t fit into the schema? Today this contextual data travels in e-mail, where we can’t do much with it. Defining parts of schemas that can carry arbitrary XML content, so people can “scribble in the margins,” is a key strategy. At the same time, don’t ignore the growing amounts of XML data flowing through your enterprise that is not, and may never be, schematized. The prime example is RSS. All kinds of useful services, done in the REST and XML-over-HTTP style, are coming up from the grassroots. We think of RSS mainly in terms of blogging, but it also affords us a lightweight and incredibly versatile way to exchange, route, and recombine all kinds of stuff. Nearly every application that today uses e-mail to connect people and processes can be recast as an RSS-oriented service. Easier and more robust integration, no spam -- what’s not to like?

In fact, this low-tech approach is so appealing that many people are now discounting the WS-* stack. That’s understandable and in many cases valid. While we argue about which WS-* standards will stick to the wall, a set of key capabilities is emerging. Broadly speaking, WS-* pushes aspects of data communication -- security, asynchrony, reliability, routing, and proxying -- up into the application layer where we can reason about these things as businesspeople rather than wrestle with them as network plumbers.

That’s a lofty statement, but here’s a concrete example to nail it down. Let’s say your order processing service is used by a dozen applications and by hundreds of people. Suddenly, one morning, it’s triple-witching time: You add a new application, you implement a mandated auditing rule, and then you have to reroute traffic because a server fails. On days like that it won’t ever be easy to get home by dinnertime. The set of principles embodied in an SOA, however, may at least make it possible.

Cynics will note that we’ve been enumerating those principles for a couple of years now. You’ve heard the litany: coarse-grained messages, loosely coupled processes, data-driven integration, self-describing data, programming-language and platform neutrality, pervasive intermediation. We call this cluster of ideas by different names -- grid, enterprise service bus, service-oriented architecture. It’s quite possible that next year’s favorite acronym won’t be SOA. But many if not most of the ideas will survive -- and will define the dominant style of enterprise software for years to come.