Re: working draft on architectural principles

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