Action RF: rewrite of a principle

>     3. 29 Oct 2002 Architecture document
>          1. Action RF 2002/09/25: Propose a rewrite of a
>             principle (rationale -> principle ->
>             constraint) to see whether the TAG prefers
>             this approach. It was suggested that the
>             example be about HTTP/REST, as part of
>             section 4.

I give up.  I've spent most of the last week trying to come up with
words that fit within the webarch document, and I simply cannot do
it without rewriting the whole thing, and I have no time for that
given that I have to give three presentations in the next six weeks
(requiring trips to Vienna, Las Vegas, and Switzerland) on a technology
that hasn't even been finished yet, let alone summarized in the form
of presentation slides.

After burning another full day with nothing to show for it, I'll
burn the night by sticking my thoughts in an e-mail message that
Ian can play with later.  Hopefully, this will be sufficient to
help with the document's progress, since I really need to focus
on other things for the next six weeks.


1) "Architectural Principles of the Web" -->
    "Architecture of the Web"

This falls down to basic definitions of architecture.  If we are going
to talk about the Web architecture in a useful sense (as in useful to
the readers), then we have to discuss the requirements (desired
properties), principles, constraints, and resultant properties.
Combine that with the protocols (which includes use of identifiers
and formats, BTW) and we have an architecture description.
The protocols can be included by reference.

The biggest problem that I have with the current document is that
it conflates everything under the general notion of "principle", which
is just plain wrong.  Principles are fundamental laws that apply to a
large number of situations/variables -- I can pretty much guarantee
that any sentence including the acronym URI is not a principle.
It may be representative of a general principle, but principles
are never defined in terms of implementations.

Architectural principles include "separation of concerns",
"generic interface", "self-descriptive syntax", "visible semantics",
"network effect" (Metcalfe's Law), Amdahl's Law: "The speed of a
system is determined by its slowest components", etc.  They don't
make much sense without the accompanying prose that explains the
rationale behind the principle.

Architectural properties include both the functional properties
achieved by the system, such as accessibility and global scope,
and non-functional properties, such as relative ease of evolution,
reusability of components, efficiency, and dynamic extensibility.

Architectural constraints are restrictions in behavior or interaction
that (hopefully) are motivated by a requirement, associated with
principles that guide us toward a suitable design, and have the
effect of inducing architectural properties.


2) Categorization

Here is what we currently list as principles, and what I think
they actually are, with motivating principle in parentheses:

    Use URIs                 --> constraint (network effect)
    URI ambiguity            --> good practice (???)
    Resource descriptions    --> good practice (network effect)
    Safe retrieval           --> principle (visible semantics)
    new URI schemes          --> good practice (simplicity)
    unregistered URI schemes --> false constraint

I don't care how many people think the last one is a good idea,
it simply isn't a constraint in the existing architecture.
Unregistered URI schemes are not only usable on the Web, but the
technology we deployed (that still works) is specifically designed
not to be dependent on registrars.  It would only qualify as a
constraint if we changed the software to look up the registry.
The same applies to unregistered media types.


3) Structure

Protocols are the rules for interaction among components of an
architecture.  However, that assumes we are talking about one
level of abstraction within one phase of operation, not all of them
at the same time.  URI is data at most levels, but a protocol for
the phase of name resolution within a client.  XML is data for the
exchange of a representation, but a protocol for the phase of
rendering within a browser's view.  Likewise, messages come in
formats, as do URI schemes.

At any level of abstraction, there exist components (actors, agents,
whatever), data (e.g., URI, metadata, control data, representations),
and connectors (mechanisms for moving data from one component
interface to another without change).  That is one structure for
architectural description, but it wasn't very satisfying for REST
when I used it in my dissertation.

The current document structure falls into three orthogonal concerns
of the architecture at the global level: identification, representation,
and interaction.  Maybe just fixing the titles would help.


4) Example rewrite of a principle

Well, actually it is a new constraint that we haven't documented yet,
other than in private communication.  I call it the constraint of
"Orthogonal protocols deserve orthogonal specifications."  [TimBL
refers to it as the "information hiding" principle, but it is really
only one constraint motivated by that principle.]

Requirements:
    The Web as a system must exist at the operational scale of
    entire societies: there is no "on" or "off" switch -- the system
    must evolve in-situ (while in use).

    Change is inevitable, and therefore evolution should be planned.

    The Web spans multiple organizations, which means that changes
    cannot be deployed all at once -- there must be an expectation
    of gradual and fragmented change.

Principles:
    Information hiding: A component's visibility into the implementation
    of another component should be limited to what is necessary to
    interoperate with its interface, since that prevents other components
    from making unintended assumptions about that component's behavior
    which may not hold true in the future when its implementation changes.
      --> applied to improve property of evolvability -- independent
          evolution of technology over time.

    Separation of concerns: A component that performs two or more
    separate activities is better implemented as two or more components
    if doing so increases cohesion and reduces coupling.
      --> applied to improve properties of simplicity and evolvability

Constraint:
    Orthogonal protocols deserve orthogonal specifications.
    If one protocol uses another as data, it must not restrict
    the content of that data other than as defined by that protocol,
    including future compatible revisions of that protocol.  Likewise,
    a specification that attempts to define two orthogonal protocols
    (incl. data formats) must be split into two specifications, since
    otherwise the independent evolution of those protocols will be
    hindered.  The result is simpler protocols that are able to
    evolve independently over time, which in turn enables the system
    to continue operating through gradual and fragmented change.

For extra credit, combine the above with "self-descriptive syntax"
within the protocol parameters and we get the property of extensibility.

I hope that is useful for some progress.  I need to focus on other
things for the next six weeks.


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

Meet me at ApacheCon 2002, Nov. 18-21: http://www.apachecon.com/

Received on Monday, 4 November 2002 07:35:13 UTC