Re: working draft on architectural principles

Roy T. Fielding wrote:

> Let's look at some of the definitions in my dissertation [1], since
> those at least have been peer reviewed by the software engineering
> community and are currently being used as definitive within many
> Universities.  Besides, it represents six years of my thinking on
> this very same subject, and I am unlikely to come up with better
> prose on the fly.
> 
>    A software architecture is

I think Roy is fighting uphill on this one.  What I do for a living 
(mostly) is design and code software and I've been doing that since 
around 1980.  In the community of people who design and code software, 
it is common to bandy the term "architecture" about.  When we 
(engineering geeks in the trenches) talk about architecture, we're 
talking about

(a) the high-level decomposition of a system and the interfaces between 
the components in that decomposition.
(b) overriding principles that we want the components and interfaces to 
follow

In this conventional industry parlance the web arch doc fits right in 
and would be found pretty unsurprising in its organization and contents 
(the parts of it that are finished anyhow).

> Where does that fit in our document?  Well, for one, our document
> claims that there is one WWW architecture.  Bah humbug.  We've already
> defined two:
> 
>    1) agent-level interaction with Internet protocols; and
>    2) information processing via separation of content and
>       presentation.
> 
> I am sure there are a few other Web architectures worth studying.

I'm not.  I'm comfortable with thinking about the Web as one system with 
some architectural principles that hold true across all the parts of the 
system.  I haven't seen any evidence yet that this isn't a good idea.

> There is no reason to lump them all together.  We should start by
> identifying the abstractions we are interested in constraining.

OK, but we're not lumping them all together except for claiming that the 
things we're talking about are essential to the correct functioning and 
scaling of the Web.  Which, by the way, I think is an excellent 
definition for what is Web architecture and what isn't; it has the 
advantage of being operational and testable.

> Instead, we start talking about "agents".  Why?  Components,
> connectors, and data are terms that offer a means of defining the
> purpose of elements within an architecture being studied without
> implying a particular purpose.

I also am more than a little uncomfortable with our usage of the term 
"agents" if only because that word has been overloaded by elements of 
the AI community.  I'd be prepared to be convinced that adopting Roy's 
terminology here would produce a better arch doc.  A good first step 
would be to rewrite some piece using these terms and see if we like the 
flavor.  Where would be a good place to start?

>  what are the properties
> of the architecture under study?  What properties do we want/need/expect
> the Web to have when implemented according to the architectural design?

Are you arguing that we need to say a lot more about the properties of 
the Web that we want to protect/optimize before we launch on the 
assertions of principle?  To some small degree, we already do this with 
the motivating text that surrounds the principle.  At the moment, I'm 
comfortable with the highly-qualitative observations that the Web is 
open to all comers, works robustly, and scales well, and that these 
things are worth preserving.  What would you change in the archdoc here?

> So, given a desired set of properties, how do want to constrain the
> interaction between elements such that the desired properties are
> obtained?  That should be the focus of our architecture document.
> The constraints are the normative aspects of Web architecture -- those
> things we expect W3C working groups to obey whether they like them
> or not.  They are not wishes, suggestions, or good practice -- they
> are commands.

This is what we're doing, isn't it, with our list of numbered, labeled, 
typographically-emphasized dicta?

> I don't expect these thoughts to make it into the first public draft
> of the architecture document.  However, I'd like for folks who are
> reviewing the next draft to think about these terms and break down
> the draft into separable architectures (those that should be discussed
> in parallel) and then further separate the "principles" into those
> that are truly constraints and those that are better described as
> desired properties.

OK, to launch this discussion in a more concrete way, I claim (on a 
strawman basis) that the items enumerated in

     http://www.w3.org/TR/webarch/#all-principles

are all architectural constraints.  -Tim

Received on Sunday, 1 September 2002 12:18:27 UTC