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

On Sun, Mar 02, 2003 at 10:42:25AM -0700, Champion, Mike wrote:
> > "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

I'm glad.

> qualifications, e.g. "firewalls" would refer to "firewalls that are aware of
> TCP/IP and HTTP but not XML and SOAP" or whatever.

I disagree, but I suppose I could live with it because most firewalls
won't know about XML/SOAP for quite some time.

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

Well, the last sentence of my proposal says ".. pass messages whose
semantics are not as visibile.." whereas the two points you raise there
relate to visibility of syntax.  "Visibility", as an architectural
property, refers primarily to semantics, and only to syntax insofar as
you need to understand the syntax in order to be able to associate
semantics with it.

So I don't think those additions are necessary, and moreover take away
from the important point about visibility of semantics.  Sorry, I
couldn't live with those.

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

Ok, let's not go there. 8-)

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

I was hoping it would be settled here, because I believe that the
framework for the study of software architecture provided to us by the
likes of Shaw, Perry, Wolf, Fielding, etc.. allows us to evaluate
architectural styles without the expense of actually deploying them.
But you're right that the real world will have the final say.

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis

Received on Sunday, 2 March 2003 15:21:20 UTC