A Tour of the Web Services Architecture
June 18, 2003
In a previous column, "The Architecture of Service", I introduced the W3C's Web Services Architecture Working Group (WS-Arch), examining its charter, its role in the W3C, and its relation to some other groups, particularly the W3C's Technical Architecture Group and the Web Services Coordination Group.
Like it or not, the web services part of the Web's future is being developed by the largest computer corporations almost entirely in terms of standards bodies. So, in addition to everything else web service developers must learn, some basic familiarity with the major players and their venues is a helpful thing to have. If you don't understand the institutional context of relevant standards, it's harder to enact or to judge standards compliance than if you do understand.
According to the WS-Arch's charter, "the goal ... is to lay out a coherent architecture, by producing architectural documents and advising W3C regarding work in the Web services area." It is on this basis, then, that I'm going to examine the latest draft of the Web Services Architecture document. I have found this document to be both helpful and strange: helpful, because it certainly reveals what the members of the WS-Arch think of as a "coherent architecture" and includes some helpful definitions and clarifications; strange, because in some respect the document is nothing more than an elucidation upon a single infographic -- an elucidation which I find less enlightening than it should or could be.
Relevant Technologies
Since the WS-Arch hasn't yet settled on an explicit definition of "web service," let's take a look at what it says about the relevant technologies that it claims will be involved in building web services.
XML, according to section 1.7 of the WSA document, is the "backplane" of a web services architecture and is "much more fundamental" than either SOAP or WSDL. That's true, if for no other reason than both SOAP and WSDL are dependent on XML. Further, XML "provides the extensibility and vendor, platform, and language neutrality that is (sic) the key to loosely-coupled, standards-based interoperability that are (sic) the essence of the Web services value proposition." Setting aside the verbal confusion of this sentence, it expresses a set of claims I'd like to linger upon. The obvious question is whether -- if another technology could claim to do all these things as well as or better than XML -- XML is exclusively essential to web services?
Consider YAML. Let's assume that it eventually becomes roughly equivalent to XML in extensibility and (vendor, platform, language) neutrality. Would it be possible to use YAML as a message exchange format in a coherent web services architecture? Certainly it would be possible. Would it be legal, in the sense of standards compliance? If not, why not? I, for one, don't see why it shouldn't be.
For my money, the web services architecture specified by the WS-Arch will be maximally coherent and forward-compatible only if it avoids tying too many specific technologies together unnecessarily. The same point goes equally well for, say, this claim: "the 'base technology' of the WSA consists of some key XML specifications, including XML 1.x, XML Schema Description Language and the xml:base specification." So RELAX NG and the forthcoming ISO validation standards have no role to play in a web services architecture? It is W3C XML Schema or bust?
It's interesting to compare this seeming narrowness with the "wide, almost infinite variety of communication mechanisms" which the WS-Arch envisions for a web services architecture: HTTP, SMTP, FTP, JMS, IIOP, "sneakernet", RFC 1140-compliant carrier pigeons, "or mechanisms that have not yet been invented." (That's rather a lot of "communication mechanisms", but seven hardly suggests an "almost infinite variety"...) In fact, the WS-Arch's agnosticism about communications mechanisms is very robust. The web services architecture ...
says almost nothing about this communication layer other than it exists -- it does not specificy (sic) that it be at any particular level of the OSI reference architecture protocol stack, and allows Web services messages to be "tunnelled" over protocols designed for another purpose.
I wonder why this agnosticism, which is so robustly deployed in this part of the architecture, fails to make even the smallest appearance in the message and interface description part of the architecture, where XML is said to reign supreme and supremely alone. This imbalance is very curious. At the very least the imbalance demands an explanation, one which I don't find in the document as it is presently constituted.
Interoperability
The important bit here is the universality of the web services architecture. The point is to say which states of affairs must or must not be the case, and to say upon which points there must or may not be agreement, in order for web services to work together universally. A double sense of "universal" is at work here: first, the conceptual universe of relevant standards; second, the universe of deployed services.
The web services architecture is concerned with making sure that all of the relevant standards are conceptually coherent, so that actually existing, deployed web services may work together. If the relevant standards cohere with each other, and if deployed services comply with those standards, interoperability may be a more likely outcome.
I state this conclusion in a very weak form because it's not clear that coherence and compliance are sufficient or necessary conditions of interoperability. I don't have space here to argue for that claim; email me privately if you're curious about it.
A Coherent Architecture
Let me say a few words about what I understand a "coherent architecture" to be, minimally. There are three elements which I am concerned with: concepts, concept relationships, and conditions. To present a collection of words as a coherent architecture, they need to be arranged in such a way that
- some of the words define concepts;
- other of the words specify the interrelations of these concepts, both which each other and with other relevant concepts in the problem domain; and
- yet other of the words describe the conditions and contexts whereby and wherein these concepts are related in the specified ways.
That is to say, a coherent architecture defines a body of concepts, relates the constituent parts of that body to each other systematically, and specifies under which conditions and in what contexts the relations between concepts hold or fail to hold. So, judging by that rough and ready standard, how well has the WS-Arch done so far?
As near as I can tell, and I hope that I am wrong about this, the web coherent services architecture is to be specified in terms of an infographic and then a list of term definitions arranged alphabetically. First, let's look at the infographic:
With all due respect to the WS-Arch, that's a stew, the visual equivalent of extreme spaghetti code. While I have reduced the size of this image (so that it will fit the XML.com site better), even at its original size it has several problems. I don't intend to provide an Tufte-like analysis, but it is overcrowded, there's no obvious "path" through the information it's meant to convey, the relationships between the terms are hard to discern and to understand, and it's so visually cluttered and busy that it doesn't even suggest a coherent, balanced, well-ordered architecture.
Section 2.2 of the document seems to be meant as an explication of this infographic, but it goes about that explication, at least in my view, in the wrong way. Rather than systematically explaining the relations between these core concepts, the editors of the document have chosen to define each concept in a long alphabetical list. While such a list may belong in the final document, the list and the infographic are insufficient systematic explanation. They provide neither a synoptic overview of the architecture, nor a careful, systematic rendering of the relations of its parts.
The document addresses the issue of the presentation of the concepts:
The reason for choosing an alphabetical ordering is that, inevitably, there is a large amount of cross-referencing between the concepts. As a result, it is very difficult, if not misleading, to choose a non-alphabetic ordering that reflects some sense of priority between the concepts. Furthermore, the "optimal ordering" depends very much on the point of view of the reader. Hence, we devote the Stakeholders perspectives section to a number of prioriterized (sic) readings of the architecture.
Insofar as this statement is the result of disagreement among the members of WS-Arch about this form of presentation, I suspect I would have sided with the person or persons who opposed this presentation. Perhaps the felicities of this approach will become more clear as the "Stakeholders perspectives" section is more fully developed. I have my doubts about this approach in general. Although I acknowledge that it is unfair to criticize a rough draft, it is fair to suggest that the structural organization of a draft does not meet one's needs or expectations.
Web Services and REST
Finally, I want to discuss briefly the relationship of web services and the REST architectural style. This relationship is one that has been the focus of a great deal of discussion and debate in the relevant technical communities. While that relationship has often been cast as adversarial, I commend WS-Arch for including a discussion of the relationship in the web services architecture document and for seeing past what is, in my view, the adversarial red herring.
|
|
|
Also in XML-Deviant |
|
Section 1.6.3 ("SOA and REST architectures") attempts a rapprochement between the advocates of REST and the advocates of RPC- or SOAP-centric web services. That is yeoman's work and the WG should be publicly commended by all interested parties for undertaking it. According to the WS-Arch, the relationship between web services and REST is as follows:
The scope of "Web services" ... encompasses not only the Web and REST Web services whose purpose is to create, retrieve, update, and delete information resources but extends the scope to consider services that perform an arbitrarily complex set of operations on resources that may not be "on the Web." Although the distrinctions (sic) here are murky and controversial, a "Web service" invocation may lead to services being performed by people, physical objects being moved around (e.g. books delivered).
It's not clear to me that that is the way to distinguish between REST and non-REST services: after all, is it the case that one cannot build a REST service which results in a physical object being moved around in the real world? But it is a start. The document also distinguishes between what it calls "REST-compliant" and "distributed object" or "Web-mediated operation" services. That is, "'direct' services are implemented by web servers that manipulate data directly, and 'mediated' services are external code resources that are invoked via messages to web servers". I recognize this distinction, but it doesn't seem to map onto REST and non-REST services very neatly. In any event, sometimes the value of working group documents isn't primarily in what they say but that they say it, and this may be one of those cases. Even if so, I think this material about REST needs considerably review and tightening.
Conclusion
Technical journalists who cover emerging standards and specification work have to walk a tightrope between fairness and unfairness. On the one hand, premature criticism is just tacky; but, on the other, early feedback and serious engagement can provide insight, motivation, and support to an effort when it's needed most.
Or, more to the point, at its best, technical journalism can help to focus the interests and attentions of a technical community on engagement with a specification effort. In addressing the WS-Arch and its deliverables at this point, perhaps a bit too early in its life cycle, I have tried to accomplish the former, rather than the latter. It is clear that, as with most working groups, WS-Arch could use feedback and interaction from the very developers it is attempting to represent.