"Marchitecture" text for stack diagram

In fufullment of my action item to produce text that the "stack diagram" at 
http://lists.w3.org/Archives/Public/www-ws-arch/2003Apr/0254.html would 
support.

================================================================
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 
repository 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 it, secure, reliable, multi-part, 
multi-party and/or multi-network applications will require some 
standardized way of packaging and annotating messages so that 
"intermediaries" can provide authentication, encryption, access control, 
transaction processing, routing, delivery confirmation, etc. services at 
the infrastructure level rather than forcing the producer and consumer to 
handle all these features.  SOAP's envelope (and attachment) structure and 
its 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 
less technologically mature 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.]

====================================================================

If there's time on the agenda today, I'd like to get feedback on this in 
the context of our "stack diagram" discussion last week. Is the combination 
of this text and the diagram a good candidate for inclusion in the document 
[net some wordsmithing, of course] or do we need to approach this in 
another way?







-- 
Mike Champion

Received on Thursday, 1 May 2003 01:14:58 UTC