Marketing documents from Web services vendors often contain a three-part diagram to show how the different Web services "standards" relate to one another: WSDL describes the format SOAP messages, and UDDI serves as a discovery service for the WSDL descriptions. The problem with such diagrams is that they don't convey the multiple dimensions of the Web services standards "space" and can't easily be extended to handle new standards, e.g. for security, management, choreography, and so on. In order to show the big picture of the Web services architecture as we envision it, the picture needs to be somewhat more complex.

First and foremost, XML is the "backplane" of the WSA. One can imagine Web services that don't depend on the SOAP envelope framework or processing model, or that don't employ WSDL to describe the interaction between a service and its consumers, but XML is much more fundamental. It provides the extensibility and vendor, platform, and language neutrality that is the key to loosely-coupled, standards-based interoperability that are the essence of the Web services value proposition. Furthermore, XML helps blur the distinction between "payload" data and "protocol" data, allowing easier mapping and bridging across different communications protocols, which is necessary in many enterprise IT infrastructures that are built on industrial-strength but proprietary components. Thus, the "base technology" of the WSA consists of some key XML specifications, including XML 1.x, XML Schema Description Language, the xml:base specification, [ed note: others? XPath?? Not DTD, unlike what the diagram shows, since DTDs are forbidden in SOAP messages, right?].

This leads to the next key concept in the WSA: services are invoked and provide results via messages that must be exchanged over some communications medium. The WSA encompasses a wide, almost infinite variety of communications mechanisms: HTTP (the dominant protocol of "the Web"), other internet protocols such as SMTP and FTP, generic interface APIs such as JMS, earlier distributed object protocols such as IIOP, and so on. In principle, Web services invocation and result messages could be passed around by "sneakernet", RFC 1149-compliant carrier pigeons, or mechanisms that have not yet been invented. WSA says almost nothing about this communication layer other than it exists -- it does not specificy 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.

WSA does have quite a bit to say about the messages themselves, if not about the mechanism by which they are communicated. SOAP is the key messaging technology in the WSA: While very simple information transfer services can be implemented without SOAP, secure, reliable,  multi-part, multi-party and/or multi-network applications are much easier to build if there is a standard way of packaging the messaging information in a protocol neutral way.  This also allows the messaging infrastructure (which may be specialized hardware, SOAP intermediaries, or code libraries called by the ultimate recipient of a SOAP message) to provide authentication, encryption, access control, transaction
processing, routing, delivery confirmation, etc. services. SOAP's envelope (and  attachment) structure and header / processing model have proven to be a very robust and  powerful framework within which to do this..

 Interoperability across heterogenous systems requires a mechanism to allow the precise structure and data types of the messages to be commonly understood by Web services producers and consumers. WSDL is the obvious choice today as the means by which the precise description of Web services messages can be exchanged. [Ed note: Obviously we have open issues with respect to whether description mechanisms such as shared code "qualify" here.] In the future, more sophisticated description languages that handle more of the *semantic* content of the messages are likely to become technologically viable, and such languages (perhaps based on RDF and OWL) will fit well in the WSA framework.

 Beyond the description of individual messages such as WSDL provides, the WSA envisions a variety process descriptions: the process of discovering service descriptions that meet specified criteria, the process of describing multi-part and stateful sequences of messages, the aggregation of processes into higher-level processes, and so on. This area is much much clearly defined than other parts of the WSA, but there is much work going on and the WSA incorporates them at an abstract level.

Two concepts cut across all these aspects of the WSA: Security and Management. These cannot be pigeonholed into the boxes of messaging, description, or process because they cut across all levels. [It's getting late and inspiration fails ... maybe someone can finish this paragraph for me.]