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?