Suggested wording for message protocol layers comment (was RE: Me ssaging Service Layer)

 
> Protocol independance/neutrality can be achieved in two ways; 
> by treating application protocols as a transport protocol 
> (the preferred approach, apparently), or by extending 
> application protocols (the "chameleon" approach).  Failing to 
> make this distinction, while using the existence of the 
> requirement to justify ignoring a proven model that may help 
> to explain it, is a nasty catch-22.

[here's some strawman wording ... Not that I want to close Mark's issue,
just that I want to make sure we capture the outlines of a position in the
WSA document for the next release]

The WSA attempts to be neutral with respect to the underlying mechanisms by
which messages that invoke a service and return the results are delivered.
[I could go along with something like "access a web service resource and
return a representation" if we can get agreement on those terminological
issues with the other WGs].

The W3C WSA builds on the foundations of SOAP, WSDL, and XML and has very
little to say about the underlying data transfer or transport protocols. Web
services messages may be communicated over raw TCP/IP connections, HTTP or
SMTP messages, BEEP conversations [not sure if that's the right term], over
proprietary messaging technologies, or over any of these technologies that
might be encapsulated by a generic messaging interface such as JMS. Since
these technologies exist at different "levels" in frameworks such as the OSI
reference model, the question of how SOAP maps onto other reference models
is essentially unanswerable.  

[We might also want to say something to the effect that SOAP's header
extension model operates by composition rather than layering.  This point is
still fuzzy to me, but seemed to come out of the "message layering" thread:
each new SOAP header doesn/t add new  a new layer to the protocol stack, it
provides new information that a SOAP-aware application may use (and if
mustUnderstand = true, MUST use or generate a fault). ]

This is just a strawman proposal, but reflects my sense that this is *not* a
Catch-22, but a question whose answer is "mu."  [See Goedel, Escher, Bach
:-) ]

Received on Wednesday, 19 February 2003 08:43:26 UTC