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

RE: Summing up on visibility(?)

From: Champion, Mike <Mike.Champion@SoftwareAG-USA.com>
Date: Thu, 9 Jan 2003 12:48:14 -0700
Message-ID: <9A4FC925410C024792B85198DF1E97E404B6E115@usmsg03.sagus.com>
To: www-ws-arch@w3.org

> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org]
> Sent: Thursday, January 09, 2003 1:17 PM
> To: Champion, Mike
> Cc: www-ws-arch@w3.org
> Subject: Re: Summing up on visibility(?)
> I'd like to phrase it this way, but I doubt the group would 
> ever agree,
> because I'd have to say things like "If you want to cross firewalls,
> don't put methods in the body", which clearly people disagree with.
> That's why I decoupled the description/identification of 
> visilibity from
> the conclusions about its role and value.

Hmm, now I recall some previous threads. I understood the visibility issue
when it was presented concretely (e.g., "firewalls can't filter messages
unless the information needed to filter is in the IP or HTTP headers").  As
you imply, I disagree -- <flamebait>saying that web services have to respect
1996-vintage firewall technology reminds me of the laws that require
"horseless carriage" owners to have a man with a red flag walking 100 feet
ahead to warn pedestrians to stay out of the way :-) </flamebait>. Firewall
vendors are developting technology that understands the contents of XML and
SOAP, such is the way of the world.  I can understand why one who doesn't
have an XML-aware firewall would want to stay away from all SOAP messages
with methods encoded in the body, but I don't think this is a good
architectural principle.

I guess I need to know why I should care about visibility other than as an
abstract property that REST has that other approaches don't in order to care
about it.
Received on Thursday, 9 January 2003 14:48:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:02 UTC