RE: Firewall sample application and requirements

Mark,
well said

+1

abbie


> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org]
> Sent: Wednesday, May 29, 2002 10:06 AM
> To: Champion, Mike
> Cc: www-ws-arch@w3.org
> Subject: 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,28
> 64540,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
> 
>