- From: Roy T. Fielding <fielding@apache.org>
- Date: Thu, 29 Aug 2002 18:30:15 -0700
- To: www-tag@w3.org
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