RE: Thoughts on TAG issue EndpointsRef47

Digging through emails as I get back, I thought I'd focus on one
particular question that Jonathan asked.  I should again restate that I
think that WS-A has done the right things wrt EPRs and URIs.

> -----Original Message-----
> From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-
> request@w3.org] On Behalf Of Jonathan Marsh
> Sent: Friday, February 04, 2005 7:19 PM
> To: public-ws-addressing@w3.org
> Subject: Thoughts on TAG issue EndpointsRef47

<snip/>

> 
> However Mark ups the discussion to the architectural level in his next
> thread [6], returning to a familiar theme of "HTTP is not a transport
> protocol, it's an application protocol!"  Perhaps somebody could
explain
> to me that while HTTP is layered on top of the underlying TCP/IP
> protocol, it is dangerous to layer another protocol on top of HTTP
> itself.  The nature of the danger in practical terms is a subtle point
> that is well beyond the comprehension of mere mortals like myself
> despite years spent on the fringe of this discussion.

This feels like a blog entry

Re-use my friend.  When an application ignores the transfer protocol
aspects of HTTP, there is little re-use of the HTTP operations or
infrastructure.  If an application could use "GET" operations at the
application level, and then use HTTP "GET" operations, then the HTTP
infrastructure can be re-used.  That is obviously things like browsers,
caches, firewalls, intermediaries.  The danger is the lack of re-use and
the cost of deploying another protocol stack.  It also means that the
application can be simpler because it can just re-use the GET verb
rather than defining n "getXYZ" verbs.

What is meant by "application" protocol is that the applications
including intermediaries fully utilize the operations defined by the
protocol.  Intermediaries "know" what is going on with the HTTP GET
request and can do useful things, like get things from cache or deny
access.  The distinction is that an application protocol means that the
intermediary software can do application level things, ie security
caching.  In a transport protocol, there isn't enough visibility into
what's going on for a protocol intermediary to do useful things.  For
example, with HTTP POST, a firewall intermediary has to have some extra
config information to do firewall things.  This is easier with HTTP GET
because an HTTP firewall will "know" what the operation (GET) is.  

>From the applications perspective, it "knows" that it is doing HTTP GET
operations and re-uses those semantics and syntax (safety, URIs, etc.).


The alternative is that the application and infrastructure does not
"know" what is going on at the protocol level.  Using TCP is a good
example, where the application only has the "send" operation.  There's
no chance for the infrastructure to do efficient things like caching or
firewalling with the subsets of the messages.  Tcp can obviously be
firewalled, but that's at the registered port level.  By having http as
an application protocol, the firewall can look inside the http messages
and be configured what to allow/deny (that's because of the crucial REST
property of visibility).  

SOAP is kind of the opposite, in that it provides extensibility points
for parties to define operations.  Therefore there is no re-use per-se
because there are no operations.  Most WS-* specs typically provide a
protocol that can provide for re-use, but it seems a stretch to say that
the WS-* protocol stack is-an application protocol itself.  

I think there is very little use in the PUT/DELETE side of HTTP as I've
blogged about the problems of generic Writes, so my re-use beliefs focus
solely on GET and generic vs specific Reads.  

Cheers,
Dave

Received on Friday, 18 February 2005 20:23:54 UTC