RE: Firewall sample application and requirements

> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org]
> Sent: Tuesday, May 28, 2002 10:57 PM
> To: David Orchard
> Cc: www-ws-arch@w3.org
> Subject: Re: Firewall sample application and requirements
> 
> 
> I consider that a bug, not a feature, for the reasons given 
> below about firewalls.  Please explain to me why this is desirable, rather
than a
> security nightmare;
> 
> http://www.xmlhack.com/read.php?item=1541

If SOAP is widely deployed, firewalls will adapt to deal with it.
http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2864540,00.html

> 
> There's all sorts of things you can try to optimize for if you break
> the fundamental architectural principles of the system you're using.
> I've tried to highlight some of the costs of doing this.  In 
> the context of the Web, the biggest (which are *huge*) are; you're fooling
> firewalls,

Firewalls are not fundamental architectural principles of the Web; they are
essentially rapidly evolving stopgaps to plug the Web's intrinsic lack of
security features. See the article quoted above; firewalls will become both
SSL endpoints and SOAP-aware processors if there is a buck to be made
selling these features.

> you're making it impossible to communicate a priori (and
> while ignoring the existing contract already in place over the wire),
> and you don't integrate well with the rest of the Web.

Sigh.  One can accept (as I do) that REST is in general a good design
pattern, but still have a business need to support systems for which it is
not a practical solution, e.g., legacy procedural code at both ends,
non-HTTP intermediaries in the middle.  If you're arguing that as a general
rule, one-off application protocols based on SOAP are not a great way to
leverage the Web, and people should be educated against blindly exposing web
services as SOAP RPC, most of us agree.  If you're arguing that the WSA
should not accomodate SOAP request/response applications at all, there is no
possible way this group will go along with that, IMHO.  For me, it's like
the Google API situation in reverse:  just as it was a bit bizarre for
Google to take their essentially RESTful architecture and expose it via a
much more complicated SOAP RPC interface, it will be just as bizarre to take
an existing distributed object architecture and try to force it into a
RESTful form in order to communicate over the Web.   


> The question is, why do you believe that hypertext is 
> inappropriate for Web services?  You've repeatedly stated (as above) that
you 
> seem to feel that hypertext is somehow only good for browsers.  This is
not true.

Even bigger sigh.  David is saying nothing of the sort; he's saying (AFAIK)
that there are scenarios under which the concrete advantages of SOAP-based
application protocols outweigh the disadvantages, hence the WSA should not
deprecate or disparage this design pattern.  What exactly do you want the
WSA WG to do, or the WSA requirements to state?

Received on Wednesday, 29 May 2002 08:52:13 UTC