working draft on architectural principles

I am having a really hard time providing anything constructive
in the way of text for this document.  We have had dozens of
conversations and it doesn't seem to be any closer to what I
might consider an architecture document -- it doesn't even use
the right terminology.

What are Architectural Principles?  Did somebody make that up?

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 an abstraction of the run-time
    elements of a software system during some phase of its operation.
    A system may be composed of many levels of abstraction and many
    phases of operation, each with its own software architecture.

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.
There is no reason to lump them all together.  We should start by
identifying the abstractions we are interested in constraining.

Speaking of which...

    A software architecture is defined by a configuration of
    architectural elements--components, connectors, and data--
    constrained in their relationships in order to achieve a
    desired set of architectural properties.

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.

    The set of architectural properties of a software architecture
    includes all properties that derive from the selection and
    arrangement of components, connectors, and data within the system.
    Examples include both the functional properties achieved by the
    system and non-functional properties, such as relative ease of
    evolution, reusability of components, efficiency, and dynamic
    extensibility, often referred to as quality attributes.

That definition is intended to beg the question: 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?

    Properties are induced by the set of constraints within an
    architecture. Constraints are often motivated by the application
    of a software engineering principle to an aspect of the
    architectural elements.

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.

    The goal of architectural design is to create an architecture
    with a set of architectural properties that form a superset of
    the system requirements.

The goal is defined by the desired architectural properties.  That is
our measure for completion -- have we defined the architectural
constraints sufficiently to induce those properties?  Of course not,
we haven't even defined the desired properties yet.

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.

Finally, I'd like to point out again that the description of REST
is completely out of place in the current draft.

    An architectural style is a coordinated set of architectural
    constraints that restricts the roles/features of architectural
    elements and the allowed relationships among those elements
    within any architecture that conforms to that style.

REST only talks about the first architecture listed above, but
its constraints encompass identification, formats, and protocols,
not just protocols as is implied by the draft.

[1] http://www.apache.org/~fielding/pubs/dissertation/software_arch.htm

Cheers,

Roy T. Fielding, Chief Scientist, Day Software
                  (roy.fielding@day.com) <http://www.day.com/>

                  Co-founder, The Apache Software Foundation
                  (fielding@apache.org)  <http://www.apache.org/>

Received on Thursday, 29 August 2002 21:29:52 UTC