Re: Resolution of Web Services Architecture Issues 27 and 28

Champion, Mike wrote:

> 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.

Mike,

{IMHO}

Perhaps this needs to be said in a spec document, so that any number 
of distributed computing and networking specialists can come to the 
WS architecture and understand that the architecture has its own 
definitions of these terms.


> 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.  

Observing these threads, it seems the key issue is that some 
protocols used by webservices will be less neutral than others, 
becuase some protocols are optimized for a domain or a problem and 
those have further assumptions and/or semantics for a given domain.

Assume we treat TCP, UDP and HTTP as being on the same layer for the 
purposes of WS. The matter then is one of dissonance between a 
custom application protocol created from the elements of a protocol 
neutral WS architecture, while using a non netral application 
protocol as its underlying transport (the phrase 'off by one' comes 
to mind). That's to say that while protocol neutrality may be an 
important architectural characteristic to  WS, no-one is ever going 
to /use/ WS in a non-neutral way, and some people will end up using 
this stuff in a non-neutral way twice.


> 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. 

Someone is missing an important distinction. To say the the IP
network was not designed for voice isn't to say it was considered
and disregarded. It's to say it wasn't considered at all. That's a 
difference in intent. HTTP was not, by intent, designed for
other protocols to run over it. Ditto SMTP, FTP, NNTP. They're
designed to sit at the top of the Internet 5 layer stack and do
something quite specific - data transfer. They're exclusive by 
design. And they certainly were not intended to do some of the 
things a protocol neutral WS can do, such as RPC encoded SOAP. 
Making wrongheaded analogies like this is perhaps symptomatic of 
what Mark is concerned about; such analogies are certain to get 
carried into running systems and be baked into the software, as 
assumptions.

On the other hand, being able to move data across many protocols and 
transports is highly valuable thing; it's just that to /actually do 
so/ is not as simple or clean-cut as declaring away  underlying 
protocol semantics. It might well make the work harder; we'll know 
in two or three years whether the engineers can make this 
architecture cost-effective.

FIPA have used another term, rather than neutral: agnostic. Granted, 
it's subtle enough, but I think it reflects accurately what WS arch 
is trying to do.


> 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.  

Why not just say 'underlying transport or application protocol'?

Bill de hÓra
--
Propylon
www.propylon.com

Received on Thursday, 3 April 2003 16:30:07 UTC