- From: Champion, Mike <Mike.Champion@SoftwareAG-USA.com>
- Date: Thu, 9 Jan 2003 12:48:14 -0700
- 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