Web Infrastructure Design Principles Classic paper "Architecture style and web-based Software Architecture Design" guide

1. Overview

Dr. Roy Fielding (see Personal homepage) is the main designer of the HTTP and URI protocol issued by the IETF. HTTP and Uri are the two most important web infrastructure protocols, so Dr. Fielding is one of the founders of the Web architecture.

In addition to academic excellence, Dr. Fielding has been involved in the design and development of many Open-source software. He was the developer of Libwww-perl, one of the world's earliest HTTP development libraries, and was responsible for the development of some code related to HTTP and URI protocols in the Apache HTTP server. Dr. Fielding also guides many other teams in the development of HTTP client and server-side software.

The http/1.1 Protocol (RFC 2616) was released in 1999, plus the URI Protocol (RFC 2396), published in 1998, where the web's underlying technology architecture is fully established. In order to give the world a detailed description of the design principles behind the Web infrastructure architecture, Fielding wrote his famous doctoral dissertation in 2000, "Architectural Styles and the" network-based Software Architectures ". The Chinese version of this paper, "Architecture style and web-based software architecture Design", can be downloaded from the Infoq Chinese station:

This paper is not easy to read, as the translator of the Chinese version of the thesis, the author tries to comb out a reading context for the reader in this guide. But I still hope that the reader can overcome the difficulties, to read this paper in person, because this paper is too wonderful. "The Analects of Confucius" has a lot of commentary version, but the reader is best to read "The Analects of Confucius," the original, to avoid the Chang of Zhu Xi. Let's get down to business.

2. Paper Guide

Fielding's thesis includes the introduction and the contents of Chapter 6. The introduction of the content is the 6 chapter of the text of the summary, do not need to say, the following respectively on the 6 chapter of each chapter of the text to guide.

2.1 1th chapter-Software Architecture

In chapter 1th, fielding redefined a set of terminology for studying software architecture, discusses the origins of each term definition, and compares these terms with related research. Fielding also reviews some of the relevant research on other software architecture researchers.

These software architecture terms include: Software architecture, schema elements, components, connectors, data, configuration, schema attributes, and architectural styles. The following is a fielding term definition:

A software architecture is an abstraction of a software system's Run-time (Run-time) element at a certain stage of its operation. A system may consist of many layers of abstraction and many operational phases, each of which has its own software architecture at each level of abstraction and operation.

The software architecture is defined by the configuration of some architectural elements (components, connectors, and data), and the relationships between these elements are constrained to obtain the desired set of schema attributes.

A component is an abstract unit of software directives and internal states that provides the ability to transform data through its interfaces.

Connectors are an abstract mechanism for arbitration between components for communication, coordination, or cooperation.

Data is an element of information that a component receives or sends through a connector.

Configuration is the structure of the schema relationship between components, connectors, and data during the system's run time.

The set of schema attributes for a software architecture includes all the attributes that result from selecting and arranging components, connectors, and data. Schema properties are caused by a set of constraints in the schema.

The architectural style is a set of mutually collaborative architectural constraints that limit the role and functionality of the schema element and the relationships between the elements that are allowed in any schema that follows that style.

In the process of comparing the definition of terms with the relevant research, Fielding has criticized some related research. For example:

"Some of the relevant research does not pay attention to the characteristics of the software at runtime, but only the structure of the software static source code." ”

Fielding the researchers ' research into "software architecture," which he does not consider to be a "software architecture" in the strictest sense. Fielding clearly points out that software architecture is a feature of the software at run time, he says:

"We separate the software architecture from the source structure in order to better focus on the run-time characteristics of the software, which do not depend on a particular component implementation." Therefore, although the design of the architecture is closely related to the design of the source code structure, they are actually separate design activities. ”

Focusing on the characteristics of software at runtime is the obvious difference between Fielding's software architecture research method and other researchers. In the discussion of the definition of the schema element, fielding further explains the difference. According to him, software architecture is like the architecture of a building, and the software structure is like a design drawing of a building. If the design drawings of the building are lost, the building will not collapse immediately, so the design drawings of the building cannot be considered as the structure of the building itself. Similarly, you should not think of a box line diagram drawn on paper (such as a common ER diagram) as the software architecture itself, that can lead to serious rhetoric, that is, to study the software architecture based on the box-line graph drawn on paper, which represents only the static software structure that exists in the source code of the software.

Fielding criticized that:

"In this process, the software architecture is simplified to what is usually seen in most informal architectural diagrams: Boxes (assemblies) and lines (connectors). The dynamic aspects of data elements and many other real-world software architectures have been overlooked. Such a model is not sufficient to describe a web-based software architecture, because the location and movement of data elements in the system is often the only critical determinant of system behavior for web-based applications. ”

(Translator Note: In UML, in addition to the static class diagram, there are time series diagrams, state diagrams, activity diagrams and so on to represent a variety of dynamic behavior.) However, during the study of Fielding's doctoral dissertation, the UML specification has not been completely stabilized. ）

Among all the software architecture researchers, fielding first proposed a very important concept of the architecture style of the software, and considered the software architecture style as "a mechanism for classifying and defining the common features of the architecture." ”

Architecture style is a new concept for domestic software architecture researchers. There are very few software architecture researchers in China who think about the architecture design of software from such a high abstraction level as architecture style, almost all of which are discussed for a particular architecture. So what is the relationship between architectural style and specific architecture?

In simple terms, the architectural style is a higher abstraction than a particular architecture. Make an analogy that is not quite appropriate: If you view architectural style as an interface in object-oriented design, then a particular architecture is the implementation class of the interface. For example, "distributed objects" is an architectural style, while CORBA, DCOM, EJB,. NET remoting are architectural examples of this architectural style of distributed objects. Although there are many differences between the four, they actually belong to the same architectural style.

An architectural style is composed of a set of schema constraints that, when applied to a particular schema, produce some architectural attributes. These architectural constraints and architectural attributes are key to determining whether a certain architectural style is appropriate for a particular operating environment.

After discussing these software architecture terms, fielding next discusses the schema and schema language, and the Schema view, both of which are interesting.

In the discussion of patterns and schema languages, fielding points out:

"As with the architectural style of software, the study of software patterns deviates from its origins in architecture," he said. ”

He traced his roots to the creator of the schema language in architecture, Alexander (Jeffrey Charles Alexander), who invented the model language. Fielding said:

"In fact, the core of the Alexander model concept is not the arrangement of recurring architectural elements, but the pattern of recurring events (human activities and emotions) in a space." Alexander also understands that the pattern of events cannot be separated from the space in which these events occur. ”

The schema view represents different viewing angles for a particular architecture, fielding says:

"The observation of a schema, in addition to the multiple architectures in the system and the multiple architectural styles that make up these architectures, is likely to be observed from many other perspectives." Perry and Wolf describe three important views of software Architecture: processing, data, and connectivity. The processing view focuses on the data flow through the component and on the data-related aspects of the connection between components. The data view focuses on processes that are processed, not connectors. The connection view focuses on the relationship between components and the state of communication. ”

Fielding in the 5th chapter of the later paper, it is using these three views to describe the rest architecture style. However, in the 5th chapter, the names of the three views change slightly, and the processing (processing) view becomes the process view, the connection (connection) view becomes the connector (connector) view.

In the remainder of the 1th chapter, fielding reviews some of the relevant research work of other software architecture researchers and reviews them. The author notes that this section does not mention UML-related research work. In my opinion, although UML is really very important for software architecture research, UML is just a communication tool, UML graphics itself does not teach designers how to design software architecture (UML diagram!= will design complex software architecture). In addition, the research work of UML and fielding research work is parallel, fielding may not understand the progress of UML at the same time.