Resolution of Web Services Architecture Issues 27 and 28

Mark,

This is in response to your comments [1] and [2] concerning  the Web
Services Architecture working draft(s), which were noted as Issues 27 and 28
in our issues list [3]

We discussed them at our March F2F meeting and concluded that they raise
closely related topics that we will address together. To summarize briefly:

"I request that Web services network stack model be described (and layers &
terms defined) and that this description be related to the IETF and/or OSI
network stack models." [1]

"I'd like to point out that the architecture document misuses the term
"transport protocol" in places, at least with respect to what it's
generally understood to mean outside of the Web services community.  In
particular, it refers to HTTP and other application protocols as
transport protocols" [2]

First, there is no consensus in the WG as to exactly how the Web services
"stack(s)" relate to the OSI reference model.  On the other hand, there *is*
a consensus that this question does not need to be answered in order for the
WS Architecture to meet its requirements.  One might say that most
implementations of SOAP are clearly at the OSI "application" layer; does
that mean that the underlying protocol used to move SOAP messages around
should be something other than an "application" protocol?  We believe that
time devoted to addressing this murky question would not be well-spent.  In
any event, the OSI reference model is *not* a normative input to this WG,
and we consider its applicability to be mainly heuristic rather than formal.

This leads to the question of what a "transport protocol" is and whether the
WSA document misuses the term.  Again, the members of the WG have different
opinions, but no one expressed agreement with your oft-stated position that
the distinction between "application protocol" and "transport protocol" is
central to the Web and Web services architecture(s).  One position that
seems to beheld by several of us is that since a primary requirement of Web
services is
to be protocol-neutral, the question is moot.  Perhaps we should explicitly
state that sometimes messages are "tunneled" (or "smuggled") over a protocol
that was designed for another purpose, and this has its plusses and minuses
from an architectural viewpoint.  We are unlikely to state that this is a
Bad Thing, however.  Someone noted that the phone network was not designed
for data, and the IP network was not designed for voice, but people very
successfully "tunnel" data over voice lines and voice over IP. Indeed,
architectural components that may be used in ways unanticipated by their
designers is generally something to be encouraged. 

Nevertheless, we believe that there is no point in confusing those who *do*
find this a critical distinction and we will direct the editors to look for
a more neutral term to describe the mechanism by which Web services messages
are exchanged among Web services producers, intermediaries, and consumers.
The term "underlying protocol" seems to have been used in the SOAP
community, and it may suffice.  

To summarize:

-  we will not follow your request to relate the WSA "stack model" with the
OSI reference model, because we do not believe this is necessary or useful.

- we have directed the editors to avoid the term "transport protocol" when
it  can cause confusion, and to note that some Web services implementations
"tunnel" HTTP.  More generally, we will be adding a section to the WSA
document that summarizes the discussions on our mailing list and at the W3C
Technical Plenary about the alternative Web service architectural styles and
their relationship to that of the hypertext Web.  Drafts of that section
will be presented to the public mailing list and we look forward to your
input and comments.

Best regards,

Mike Champion
co-chair, W3C Web Services Architecture Working Group

[1] http://lists.w3.org/Archives/Public/www-wsa-comments/2003Feb/0010.html
[2] http://lists.w3.org/Archives/Public/www-wsa-comments/2003Mar/0002.html
[3] http://www.w3.org/2002/ws/arch/2/issues/wsa-issues.html

Received on Wednesday, 2 April 2003 20:53:49 UTC