Re: Firewall sample application and requirements

On Wed, May 29, 2002 at 08:51:38AM -0400, Champion, Mike wrote:
> If SOAP is widely deployed, firewalls will adapt to deal with it.
> http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2864540,00.html

That article was soundly thrashed on the decentralization mailing list.
It has nothing at all to do with reality.  Firewalls are already
"application level".

Firewalls cannot adapt to RPC.  They never have, and I see no evidence
that they've suddenly learned how to keep track of what an endless number
of methods mean.

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

Firewalls most definitely *are* a fundamental architectural component
of the Web, the same way that any HTTP intermediary is.

Like all other intermediaries, they get their job done by having
visibility into the transaction in progress.  If you reduce visibility,
by tunneling or other means, then they cannot do their job, and it is
*you* that is breaking them by doing this.

> essentially rapidly evolving stopgaps to plug the Web's intrinsic lack of
> security features.

Sigh.

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

I'm quite sure that firewalls will soon be happily blocking SOAP,
because of its expectation that it is RPC.  This is a shame for those
of us who don't want to use it that way.

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

Then where does SOAP go?  If you're spending the time to insert new
software in there, then why not do it properly?

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

I'm arguing that the WSA should primarily accomodate SOAP request/
response applications in the REST style.

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

No, it's not bizarre at all.  It's actually quite easy, once you do it
a couple of times.

If you don't believe me, show me a Web services example that you feel
can't be done as hypertext, and I'll convert it for you.  I've already
showed a couple of examples of this.

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

As I see it, you and David seem to believe that while REST is useful for
some things, that there are things (substantial things, that are worth
worrying about) that Web services can do that can't be reasonably done
within the constraints of REST.  Is that true?

I believe that there are some kinds of applications which are not
suitable for REST.  I believe the same thing about Web services.  If I
had a whiteboard right now, I would draw two big circles, one
representing those applications that are suitably styled with REST, and
another circle representing those are best fit within what is currently
understood to be Web services (OO-RPC).

My view on the radius of these circles, is that the one for Web
services is very slightly larger, because it is a less constraining
architecture (note; "less constraining" is a bad thing in architecture).
I also believe that the circles are roughly concentric.

In other words, the benefit of Web services over REST is negligable,
and I have personally yet to see a Web services example that could not
be reasonably styled with REST.  The bulk of what people are doing with
Web services - where the circles overlap - can be done with the Web.

>  What exactly do you want the
> WSA WG to do, or the WSA requirements to state?

I want us to meet our charter directive, to integrate cleanly with Web
architecture.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@acm.org
http://www.markbaker.ca        http://www.idokorro.com

Received on Wednesday, 29 May 2002 09:58:16 UTC