RE: Visibility (was Re: Introducing the Service Oriented Architec tural style, and it's constraints and properties.

> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org]
> Sent: Sunday, March 02, 2003 12:07 AM
> To: Champion, Mike
> Cc: www-ws-arch@w3.org
> Subject: Re: Visibility (was Re: Introducing the Service Oriented
> Architec tural style, and it's constraints and properties.
> 
 

> 
> "When it is desirable for a service to be used over the Internet,
> serious consideration should be given to using the REST architectural
> style, or other architectural styles which have greater visibility
> than WSA/SOA (such as those styles used by Internet email, FTP, IRC,
> etc..).  This recommendation is being made because visibility is
> important to a firewall's ability to do its job, and firewall
> adminstrators may choose not to pass messages whose semantics are not
> as visible as they would like them to be."

I actually think that's a pretty reasonable statement, or at least a
starting point for something for the WSA document.  I would add a few
qualifications, e.g. "firewalls" would refer to "firewalls that are aware of
TCP/IP and HTTP but not XML and SOAP" or whatever.  I would also suggest an
additional sentence or so saying something like "As intermediaries that can
be configured to look into SOAP headers and XML message bodies become more
widely deployed, designers and administrators will have to weigh the
increased capablity, security, and flexibility that these offer against the
additional complexity, acquisition and configuration cost, and run-time
resource overhead they imply." I'd proably also suggest a sentence to
reiterate Roger's point that information that is visible to an intermediary
is also visible to competitors, spies, hackers, etc. and this must become
part of the cost-benefit equation.  If we close your "visiblity" issue on
this basis, can we move on?

So in my mind anyway, there are signficant benefits of RESTful visibility
for information-oriented services, that don't have onerous security or
privacy requirements, and have relatively simple choreographies that can be
easily modeled with URIs and sets of URIs (Google being the canonical
example), and that should be emphasized in the WSA docuemnt.  But while
SOAP, WSDL, and all the things they bring to the table may well be overkill
in such services, they also have significant benefits when things must be
more secure, private, flexible, and complex.  

As Roger said, this permathread has an Alice In Wonderland quality about it,
and I'm very tired of climbing in and out of its rabbit holes. We're NOT
going to say "REST is the hammer, pretend everything is a nail."  Hammers
and nails work well for simple woodworking, but for serious building you
need steel, drills, rivets, rivet guns, welding torches, etc.   Can't we
bring this permathread to a close by agreeing that neither extreme is
suitable for everything, rather than quibbling about where to draw the line
between "things that REST is good for" and "things that SOAP, WSDL,
XML-aware firewalls, WS-* standardized headers, etc. are necessary for?"
That's going to be settled out there in the real world, not on W3C mailing
lists.

Received on Sunday, 2 March 2003 12:42:59 UTC