RE: "Marchitecture" text for stack diagram

I think that there is also some disagreement about whether a formal XML
mechanism for describing a Web service that is not WSDL (CPP/CPA, for
example) will qualify. 

-----Original Message-----
From: Mike Champion [mailto:mike.champion@softwareag-usa.com] 
Sent: Thursday, May 01, 2003 12:13 AM
To: www-ws-arch@w3.org
Subject: "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 12:39:17 UTC