- From: Chris Lilley <chris@w3.org>
- Date: Fri, 30 Aug 2002 15:21:47 +0200
- To: www-tag@w3.org, "Roy T. Fielding" <fielding@apache.org>
On Friday, August 30, 2002, 3:30:15 AM, Roy wrote: RTF> A software architecture is an abstraction of the run-time RTF> elements of a software system during some phase of its operation. RTF> A system may be composed of many levels of abstraction and many RTF> phases of operation, each with its own software architecture. RTF> Where does that fit in our document? Well, for one, our document RTF> claims that there is one WWW architecture. Bah humbug. We've RTF> already defined two: RTF> 1) agent-level interaction with Internet protocols; and RTF> 2) information processing via separation of content and RTF> presentation. RTF> I am sure there are a few other Web architectures worth studying. RTF> There is no reason to lump them all together. Your definition above seems to cover that very nicely. RTF> A software architecture is an abstraction of the run-time RTF> elements of a software system during some phase of its operation. This, once architecture document for the system call the World Wide Web. RTF> A system may be composed of many levels of abstraction and many RTF> phases of operation, each with its own software architecture. Thus, separate sections in that document for the 'levels of abstraction' or 'phases of operation' eg protocols, formats, etc. What is the conflict that you see here? RTF> We should start by RTF> identifying the abstractions we are interested in constraining. In a client-server system such as the Web it does not seem to much of a stretch that there may be some constraints on servers, constraints on clients and constraints on the protocol used to connect them and that, in some cases, the contraint will only apply to one of those 'phases of operation'. RTF> Speaking of which... RTF> A software architecture is defined by a configuration of RTF> architectural elements--components, connectors, and data-- RTF> constrained in their relationships in order to achieve a RTF> desired set of architectural properties. RTF> Instead, we start talking about "agents". Why? Because that is the common term used in describing the web. Its certainly possible to generalize to less specific terms, but thatalso risks diluting the import such that the architecture becomes a set of bland truisms with zero apparent practicval impact. RTF> Components, RTF> connectors, and data are terms that offer a means of defining the RTF> purpose of elements within an architecture being studied without RTF> implying a particular purpose. No, I would say that those are alternate terms that imply a particular focus on protocols and not to the whole system. RTF> So, given a desired set of properties, how do want to constrain the RTF> interaction between elements such that the desired properties are RTF> obtained? That should be the focus of our architecture document. RTF> The constraints are the normative aspects of Web architecture -- those RTF> things we expect W3C working groups to obey whether they like them RTF> or not. They are not wishes, suggestions, or good practice -- they RTF> are commands. That reass very like "MUST' is good, 'SHOULD and MAY' have no value. Is that what you are saying, because if so I disagree. RTF> I don't expect these thoughts to make it into the first public draft RTF> of the architecture document. However, I'd like for folks who are RTF> reviewing the next draft to think about these terms and break down RTF> the draft into separable architectures (those that should be discussed RTF> in parallel) and then further separate the "principles" into those RTF> that are truly constraints and those that are better described as RTF> desired properties. That sounds reasonable, for a top-down review. A bottom-up review is also desirable - some of the higher abstractions are emergent properties. RTF> Finally, I'd like to point out again that the description of REST RTF> is completely out of place in the current draft. RTF> An architectural style is a coordinated set of architectural RTF> constraints that restricts the roles/features of architectural RTF> elements and the allowed relationships among those elements RTF> within any architecture that conforms to that style. RTF> REST only talks about the first architecture listed above, but RTF> its constraints encompass identification, formats, and protocols, RTF> not just protocols as is implied by the draft. I would be interested in discussing with you further how ut applies to formats, and also whether and if so how, it applies to Web clients. -- Chris mailto:chris@w3.org
Received on Friday, 30 August 2002 09:22:02 UTC