The Architecture of Service
May 28, 2003
I confess: when it comes to XML and web services, I am a Big Picture person. There are hundreds of angle-bracket jockeys in the XML development community, to whom we can all look for the ins and outs of particular XML technologies. But the job of the XML-Deviant column, as I understand and practice it, is to focus the collective intelligence of the XML development community on the Big Picture. Toward that end I have often written about the W3C's Technical Architecture Group, describing it as the Web's court of last appeal, and in particular about the TAG's Architectural Principles of the World Wide Web (for example, see my "TAG and the Web's Architecture" and "Identity Crisis") -- an ongoing project to define the first principles of Web architecture.
Why are first principles so important? For a general answer to this question, I refer the eager reader to Aristotle. (I refer the eager but busy reader to two articles in the Stanford Encyclopedia of Philosophy: one on Aristotle's logic, the other on his metaphysics.) General arguments aside, why are the first principles of the Web's architecture important, especially since the Web has grown up rather nicely without them? Or, put another way, since the Web developed without its first principles being explicitly set down in a systematic, public way? My intuition -- which means I don't really have much of a backing argument for this claim -- is that as the Web evolves, especially under the dual pressure of web services and the Semantic Web, we get closer and closer to operating within sight of its fundamental limits. And here I don't just mean the fundamental performance limits but its conceptual ones, too. In short, as we try to do more and more with or on the Web, it becomes more crucial to have a very keen sense of basic constraints, limits, resources, and so on.
Web services push us to discover the fundamental limits of the Web; hence the need, more than at any other time in the Web's history, to map those limits. But we should think of the Web's first principles as constraints, not necessarily as design pointers. In other words, web services are not the Web itself. What counts as a first principle of the Web is not necessarily a first principle of any and every kind of Web application. Generally considered, web services ought not to violate any of the Web's fundamental constraints. But that doesn't mean that every principle of the Web is necessarily a rational design principle of, say, a web services architecture. Whether those principles apply in both areas will be a contingent, not a necessary fact.
What does all of this mean in practice? Among other things, I think it means that the W3C's Web Services Architecture Working Group's (hereafter, WS-Arch) relationship to the W3C's TAG will necessarily be a tricky one. That is, the Web needs a court of last appeal, but the W3C's Web Services Activity also needs an architecture group which is specifically concerned with web services.
In this and in the next XML-Deviant column I want to introduce the general XML.com readership to WS-Arch. I hope this introduction will offer our readership whatever motivation it needs to become engaged with the work of WS-Arch, even if only as interested onlookers. In this column I will discuss WS-Arch's charter, some of its neighbor Working Groups, and give a brief overview of some of its documents. In the next column I will examine its documents in more detail as well as delve into its discussion archives.
The WS-Arch charter suggests, albeit in a not inappropriately elliptical fashion, a familiar line of argument. Much of the value of web services will come from their ability to be combined in novel, complex ways. Because of the potential complexity of these interactions (coordination of which with regard to the W3C falls under the Web Services Choreography Working Group), the "architecture of [w]eb services needs to be better understood". And so the "goal of the Web Services Architecture Working Group is to lay out a coherent architecture, by producing architectural documents and advising W3C regarding work in the Web services area". Thus, as I argued above, the work of WS-Arch is related to the W3C's TAG but cannot be subsumed by it.
The charter further identifies a set of goals and constraints for its work. The goals include modularity (important enough to be mentioned twice among the set of goals), extensibility and decentralization (which is also mentioned twice), and coherent integration with the Web itself. The primary WS-Arch deliverable will be a Web Services Architecture document, a recent draft of which is available and to which I will turn in the next column. WS-Arch has also released drafts of ancillary documents, including "Web Services Architecture Requirements", "Web Services Glossary", and "Web Services Architecture Usage Scenarios".
The relationship between WS-Arch and the Web Services Coordination Group is an interesting one. WS-Arch is developing an architectural design which will serve as input to the Coordination Group's efforts to see that the various pieces of that design are implemented by other WGs. The Coordination Group is composed of the technical leads or chairs of the relevant WGs or Activities or Domains: XML Protocol, Architecture Domain, Web Services Activity, WS-Arch, Web Services Description WG (i.e., the WSDL people), Web Services Choreography, and Semantic Web Activity.
Also in XML-Deviant
A few institutional notes are worth making: WS-Arch will liaise with the W3C's Semantic Web Activity in some unspecified way; it will specify an architecture but other WGs will be created to implement the required technologies; and, though this isn't explicitly stated anywhere, you should not blame WS-Arch for SOAP! Or, put more charitably, WS-Arch appears to have inherited SOAP, and there are signs -- more about this in the next column -- that WS-Arch is making a real attempt to mediate carefully between the SOAP and REST-centric approaches to building web services. As a fan of the REST approach, I find that to be welcome news, especially since REST is well supported by the W3C's technical core, but its vendor members are universally fans of SOAP.
The industry-wide web services effort is an exceedingly complex thing, both technically and institutionally. The W3C is not the only standards body which is working on web services specifications. For a complete picture one must consider, at a bare minimum, OASIS, DAML, and WS-I. Of course competing, overlapping, and redundant standardization efforts are nothing new, but since one of the chief virtues of web services will be integration of heterogeneous systems, the inter- and intra-institutional cacophony gives ample reason for concern.