W3C home > Mailing lists > Public > www-ws@w3.org > May 2003

Re: Proposed issue; Visibility of Web services

From: Mark Baker <distobj@acm.org>
Date: Mon, 26 May 2003 10:26:17 -0400
To: www-ws@w3.org
Cc: noah_mendelsohn@us.ibm.com
Message-ID: <20030526102617.V9408@www.markbaker.ca>

Hi Mike,

On Mon, May 26, 2003 at 09:39:05AM -0400, Champion, Mike wrote:
>  For example, a "classic" firewall can
> look at the IP address, the TCP port, and the HTTP verb (and perhaps other
> HTTP headers, I don't know) to make a "let this through?" decision.  A
> modern firewall can look at WS-security (or other SOAP-based) headers to
> find/check authentication tokens, security assertions, digital signatures,
> etc.

Ok, there's a a critical difference between the two types of firewalls
in that paragraph.  You say "application-level semantics of the message
body"; in the case of a RESTful use of SOAP and/or HTTP, the semantics
of the message body simply *extend* the application semantics explicit
via the method and headers in the application protocol envelope.  So,
for example, the message might be;

PUT some-uri HTTP/1.1
Host: example.org
Content-Type: application/xml
[blank line]
<lightbulb xmlns="some-lightbulb-ns-uri">
  <state>on</state>
</lightbulb>

In contrast, a non-RESTful use of SOAP and HTTP might use a message such
as this;

POST some-other-uri HTTP/1.1
Host: example.org
Content-Type: application/soap+xml
[blank line]
<envelope xmlns="http://...">
 <body>
  <m:setLightbulbState>on</m:setLightbulbState>
 </body>
</envelope>

In the former case, the body simply specifies a state.  In other words,
it's like an argument to the PUT method that extends the meaning of the
request (or "completes" it, if you prefer).  In the latter, the
effective method (the one that is agreed upon by client and server) is
within the body of the message, as is the state ("on").

So in the former case, a generic HTTP intermediary, despite not knowing
what lightbulbs are, still knows that the request is a specific request
for a state change (because it knows what PUT means).  In the latter
case, a generic SOAP/XML intermediary, or even an HTTP intermediary,
doesn't know that, so therefore the semantics of the whole message are
less visibile to it than for the generic HTTP/RESTful case.

>  Neither type of firewall has to know anything about the
> application-level semantics of the message body, hence both have the
> "visibility" property.

That's not true, because a generic HTTP intermediary already knows
the difference between the PUT, POST, GET, DELETE, etc.. application
semantics.

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis
  Actively seeking contract work or employment
Received on Monday, 26 May 2003 10:23:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:42 GMT