Re: Thoughts on TAG issue EndpointsRef47

+0.9! 8-)  A couple of clarifications, including a tie-back to why
I raised this issue in the first place ...

On Fri, Feb 18, 2005 at 12:23:52PM -0800, David Orchard wrote:
> > 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.

Actually, it's that the protocol defines application layer
semantics.

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

Yes, exactly.  And in order to do (most of) these things, it also needs
an identifier (e.g. for the cache key).  But HTTP infrastructure only
knows to look for the identifier in the HTTP request line and not the
wsa:To header, therefore, for the sake of reuse, the target address
needs to go in the request line.

And that, in a nutshell, is why I raised the issue... and also why I've
been so opposed to anything else premised on the concept of "protocol
independence".

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

Just to clarify (since I assume we agree), "send" isn't an operation in
the same way that GET and POST or getStockQuote are operations.
Transport protocols don't have application operations.  If they did
they'd be called, well, application protocols! 8-)

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

That's how most folks use SOAP, but this use actually isn't licensed by
the 1.1 or 1.2 specifications, except in the RPC sections.

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

Oh well, can't win 'em all. 8-)

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

Received on Saturday, 19 February 2005 04:38:42 UTC