Architectural style and architecture design based on Web application software (i.)

Source: Internet
Author: User

Roy Thomas Fielding
Translator: Li Yu

Paper abstract

The success of the web (the World Wide Web, the English universal name, Wide, or web) is largely due to the design of its software architecture to meet the needs of a distributed hypermedia system with an Internet scale (Internet-scale). Over the past 10 years, the web has evolved iteratively through a series of modifications to the specification of the definition Web schema. To identify those aspects of the web that need to be improved and to avoid unnecessary modifications, a modern web architecture model is needed to guide the design, definition, and deployment of the Web.
The research in software architecture explores how to best divide a system, how to identify components, how to communicate between components, how information is expressed, how elements in the system evolve independently, and how all of the above can be described using formalized and non-formalized symbols. The motivation of my work is to understand and evaluate the architecture design based on Web application software (the architectural design of network-based application software), by using schema constraints in a principled way, This allows you to derive the desired functionality, performance, and social attributes from the architecture. An architectural style is a set of named, Collaborative schema constraints.
This paper defines a framework that is dedicated to understanding software architecture through architectural styles, and it shows how to use architectural styles to guide architecture design based on Web applications. This paper investigates architectural styles based on Web applications and classifies these architectural styles according to the architectural attributes generated in architectures designed for distributed hypermedia (distributed hypermedia) based on different architectural styles. I then introduced the architecture style of rest (representational state handover, the English full name representational-Transfer, short rest), and described how to use rest to guide the design and development of modern web architectures.
Rest emphasizes the scalability of component interactions, the commonality of interfaces, the independent deployment of components, and the intermediate components (intermediary component) used to reduce interaction latency, enhance security, and encapsulate legacy systems. I describe the software engineering principles that guide rest and the interaction constraints chosen to support these principles, and compare them to the constraints of other architectural styles. Finally, I describe the lessons learned from applying rest to HTTP (Hypertext Transfer Protocol) and URI (Uniform Resource Identifier) two specifications and further deploying both specifications to Web client and server software.

Introduction

I'm sorry...... Are you talking about "slaughter knives"? --excerpt from the architect satire (The architects Sketch)
As Perry and Wolf predicted, software architecture became the focus of software engineering research in the the 1990s. Due to the complexity of modern software systems, it is more necessary to emphasize a modular system whose implementation is divided into separate components that perform the tasks they want to accomplish by communicating with each other. The research in software architecture explores how to best divide a system, how to identify components, how communication between components, how information is expressed, how the elements that make up the system evolve independently, and how all of the above is described using formal and non-formal symbols.
A good architecture is not a figment of imagination. Each architecture-level design decision should be based on the functional, behavioral, and social requirements of the system being designed. This is a basic design principle that applies to both the software architecture and the traditional architectural architecture field. The "form following function" Guideline comes from experience gained from hundreds of years of failed construction projects, but it is often overlooked by software practitioners. The funny words quoted above come from the Monty Python series, which expresses the absurd ideas that an architect has in mind when confronted with the goal of designing an urban residential area. He wants to use all the parts of modern slaughterhouses to complete this design! This may be the best slaughterhouse he has ever conceived, but it is not comfortable for the prospective residents, who will have to walk through the corridors where the rotary slaughter knives are installed.
The hyperbole in the architect's satire may seem ridiculous, but given how often we see software projects start with the latest and most fashionable architecture design, it turns out that the need for satisfying systems doesn't really require such an architecture. Design-by-buzzword (designed according to fashionable vocabulary) is a common phenomenon. At least in the software industry, many of these behaviors occur because the designer doesn't understand why a specific set of schema constraints is useful. In other words, when choosing the best software architectures to use, the reasoning behind them (reasoning) is not obvious to the designer.
This paper explores the intersection of two research disciplines (software and network) boundaries in computer science. Software research has long focused on classifying and developing design methodologies for software design, but rarely objectively evaluates the impact of different design choices on system behavior. On the contrary, network research focuses on the details of common communication behavior between systems and improves the performance of special communication technologies, but often ignores the fact that changing the interactive style of an application (the interaction Style) has a greater impact on performance than the communication protocol used to alter the interaction. My motivation is to understand and evaluate the architecture design of Web-based applications by using schema constraints in a principled way to derive the desired functionality, performance, and social attributes from the architecture. This set of schema constraints becomes an architectural style when a name is given to a set of mutually collaborative schema constraints.
The first three chapters of this paper define a framework for understanding software architecture through architectural styles, demonstrating how to use architectural styles to guide architecture design based on Web application software. When a common architectural style is applied to the architecture design of a network-based hypermedia system (network-based hypermedia), a series of architectural attributes are created to investigate and classify the architectural style based on these architectural attributes, The resulting classification is then used to identify a set of schema constraints that can improve an earlier web schema.
As we discussed in the 4th chapter, designing a Web architecture requires understanding the needs of the Web. The web is designed to be an Internet-scale (Internet-scale) distributed hypermedia system, which means its connotation extends far beyond the mere geographical distribution. The internet is a network of information that is interconnected across organizational boundaries. Providers of information services must be able to meet the requirements of uncontrolled scalability (anarchic scalability) and independent deployment of software components (the independent deployment of software component). By embedding the action controls in the information representation obtained from the remote site, distributed Hypermedia provides a unified approach to accessing the service. Therefore, the architecture of the Web must be designed in environments that span high-latency networks and multiple trusted boundaries to communicate with large-grained (large-grain) data Objects.
The 5th chapter introduces and describes in detail the architecture style of rest (representational state handover) designed for distributed hypermedia systems. Rest provides a set of schema constraints that, when applied as a whole, emphasizes the scalability of component interactions, the commonality of interfaces, the independent deployment of components, and the intermediate components used to reduce interaction latency, enhance security, and encapsulate legacy systems. I describe the software engineering principles that guide rest and the interaction constraints chosen to support these principles, and compare them to the constraints of other architectural styles.
As shown in the 6th chapter, over the past 6 years, we have used the rest architecture style to guide the design and development of modern web architectures (the Translator notes: "Early Web Architectures"). This work is done in conjunction with the HTTP (Hypertext Transfer Protocol) and URI (Uniform Resource Identifier) Two Internet specifications I authored, which define the common interfaces used by all components interacting on the web.
Just like most real-world systems, not all deployed Web schema components are subject to every constraint given in their schema design. Rest can be used as a way to define schema improvements or as a way to identify schema mismatches (architectural mismatches). Schema mismatches occur when a software implementation is deployed in a way that violates schema constraints due to ignorance or neglect. Although schema mismatches are often not avoided, it is possible to identify them before they become formal specifications. The 6th chapter summarizes several mismatches in modern web architectures, and analyzes why they appear and how they deviate from rest.
In summary, this paper contributes to software research in the field of Internet and computer science:

    • Defines a framework for understanding software architecture through architectural styles, including a set of self-contained terms used to describe software architectures;
    • By applying an architectural style to a schema designed for a distributed hypermedia system (distributed hypermedia systems), the architectural attributes that will be generated are used to classify the architecture style based on the Web application software.
    • Describes a new architecture style designed for distributed hypermedia Systems (rest--), and
    • Apply and evaluate the rest architecture style as you design and deploy a modern web architecture.
1th Chapter Software Architecture

While the field of software architecture has attracted a lot of interest, researchers have almost never reached a consensus on what should be included in the definition of architecture. In many cases, this has led to the neglect of some important aspects of architectural design in past studies. In this chapter, we define a set of self-contained software architecture terms based on the review of existing definitions in the literature and my own understanding of the architecture of Web-based applications. Each definition is highlighted using a box, followed by a discussion of how the definition was obtained, or compared to the relevant study.

1.1 Runtime Abstraction (Run-time abstraction)

Software architecture is an abstraction of a software system's runtime elements (run-time elements) at some stage of its operation. A system can consist of many layers of abstraction and a number of runtime phases, each with its own software architecture.
The core of the software architecture is the abstract principle: to hide some of the details of the system through encapsulation to better identify and support the system's architectural properties [note]. A complex system will contain multiple layers of abstraction, each with its own architecture. Architecture represents the abstraction of system behavior at a certain level, and the schema element (architectural elements) can describe [annotations] by itself as an abstract interface to other elements of the same layer. Within each schema element, there may be another schema, defined by a system of its many child elements, that implements the behavior shown by the abstract interface of the parent element. Such architectures can be recursively passed down to the most basic system elements: they can no longer be decomposed into lower-level elements of abstraction.
In addition to the hierarchy of architectures, software systems typically have multiple run phases, such as startup, initialization, normal processing, reinitialization, and stop. Each run phase has its own architecture. For example, a configuration file will be treated as a data element of the schema during the start-up phase, but it will not be treated as a schema element in the normal processing phase because the information in this phase of the configuration file is already distributed throughout the system. In fact, you can also use a configuration file to define the schema for the normal processing phase. The overall description of the system architecture must be able to describe the behavior of the system architecture at each stage, as well as describe the migration of the architecture between the stages.
Perry and wolf[notes] define the processing element as the "Data Transformation" (Transformers of the), while Shaw and others [note] Describe the component as "the location of the calculation and state" (the locus of computation and the States). Shaw and Clements[notes] further: "A component is a software unit that performs some function at run time." Examples of this are programs, objects, processes, filters. "This leads to an important difference between the software architecture (software architecture) and the commonly described software architecture (software structure): The software architecture is the abstraction of the software system at runtime, and the software structure is the property of the static source code. While there are many benefits to using the module structure of the source code to correspond to the behavioral parts in the running system, and the use of the same Code parts (such as shared libraries) to implement independent software components, we separate the architecture of the software from the source code structure to better focus on the features of the software at runtime. These attributes do not depend on a particular component implementation. Therefore, although the design of the architecture and the design of the source code structure is closely related, they are in fact separate design activities. Unfortunately, the description of some software architectures does not explicitly indicate this distinction (e.g. [note]).

1.2 Schema elements (Elements)

A software architecture is defined by the configuration of some architectural elements (components, connectors, and data) that are constrained in relation to the desired set of schema properties.
Perry and Wolf[notes] A comprehensive review of the scope and knowledge base of the software architecture, they present a model that defines the software architecture as a set of specific forms (form) schema elements (elements) and is described by a set of basic principles (rationale). Schema elements include processing elements, data elements, connection elements, which are defined in the form of the attributes of the element and the relationship between the elements (that is, constraints on the element). These fundamentals provide the underlying foundation for the architecture by capturing the choice of architectural styles, and the motivations for selecting schema elements and forms.
My software architecture definition is based on a model of Perry and wolf[annotations], a more detailed version, but not part of the rationale. Although the rationale is an important aspect of software architecture research, especially with regard to the description of the architecture, it is included in the definition of a software architecture that implies that the design document is part of the runtime system. The inclusion of fundamentals does affect the development of an architecture, but once the architecture is built, it will be independent from the rationale it is based on. The reflective system (reflective systems) [note] Can change future behavior based on past performance, but instead of including the fundamentals in those architectures, it replaces the other low-level architecture with a low-level architecture.
Using an analogy to illustrate, imagine what will happen when a building's blueprint and design plan is burnt down. Will the building collapse in an instant? No, because the walls that support the weight of the roof are still intact. By design, a schema has a set of schema properties that allow the architecture to meet or exceed the requirements of the system. Ignoring these architectural attributes may violate the framework's constraints in future modifications, as if replacing a load-bearing wall with a large window would undermine the stability of the building structure. Therefore, our software architecture definition does not include the rationale, but includes the schema properties. The fundamentals explain these architectural attributes in detail, and the lack of fundamentals can lead to gradual degradation of the architecture over time, but the rationale itself is not part of the architecture.
A key feature in the model for Perry and wolf[annotations is the difference between different types of elements. The processing element (processing elements) is the element that performs the data transformation, the data elements is the element that contains the information that is used and transformed, and the connection element (connecting elements) is a binder that combines different parts of the architecture. I'll use the more popular terminology: components and connectors (connectors) to represent processing elements and connection elements, respectively.
Garlan and shaw[notes] describe the architecture of the system as some computational component and the interaction between those components (connectors). This model is an extension of the model [notes] for people like Shaw, and defines the architecture of a software system according to the interactions between some components and these components. In addition to pointing out the structure and topology of the system, the architecture also shows the desired system requirements and the correspondence between the elements that build the system. More detailed definitions can be found in the articles of Shaw and Garlan[notes].
The surprising part of Shaw's models is that they treat the software architecture as if it were the architecture itself, rather than defining the software architecture as being in the software. In this process, the software architecture is reduced to what is usually seen in most non-formalized architecture diagrams: boxes (components) and straight lines (connectors), while the dynamic aspects of data elements and many other real software architectures are ignored. Such a model is not sufficient to describe the architecture of web-based applications because, for such software, the characteristics, location, and movement of the data elements in the system are often the only and most important determinant of the system's behavior (the single most significant determinant).

1.2.1 Components (component)

A component is an abstract unit of software directives and internal states that provides the ability to transform data through its interfaces.
In software architecture, components are the easiest to identify. In the definition of Perry and wolf[annotation], the processing element is defined as: A component that provides the transformation of the data element. Garlan and shaw[comments] simply describe the component as: the element that performs the calculation. Our definition attempts to differentiate between components and the software in the connector (software within connectors) more precisely.
A component is an abstract unit of software directives and internal states that provides the ability to transform data through its interfaces. Examples of data transformations include loading data into memory from level two storage, performing some calculations, converting to another format, encapsulating it in other data, and so on. The behavior of each component is part of the schema and can be observed (observed) or identified by other components (discerned) [note]. In other words, the component should be defined by a component for the interface and services provided by the other component, rather than by the implementation hidden behind the interface provided by the component. Parnas[Notes] Defines this as a set of assumptions that other schema elements can make on the component.

1.2.2 Connector (connectors)

A connector is an abstract mechanism for intermediate mediation of communication, coordination, or collaboration between components.
The Perry and wolf[annotations] Describe the connection element as a binder that combines the different parts of the schema together in a vague way. Shaw and Clements[notes] provide a more precise definition: A connector is an abstract mechanism for intermediate mediation of communication, coordination, or collaboration between components. Examples of connectors are shared representations, remote procedure calls, message delivery protocols, and data flow.
Perhaps the best way to understand connectors is to compare them to components. The connector transfers data elements from one of its interfaces (transferring) to another interface without altering the data to support communication between components. Inside, a connector can contain a subsystem of components that, for the purpose of handoff, performs some kind of conversion, executes the handover, and then reverses the conversion and delivers the same results as the original data. However, these details can be ignored in the external behavior abstraction that the schema can capture. Conversely, from an external perspective, a component can (though not always) convert the data.

1.2.3 (data)

Data is an element of information that a component receives or sends through a connector.
As mentioned above, whether the inclusion of data elements is the biggest difference between the model proposed by the Perry and wolf[annotations and the model proposed by most other software architecture institutes [1,5,9,53,56,117-122,128]. boasson[comment] Criticizing the current software architecture research too much emphasis on component architecture and architecture development tools, he suggests that attention should be focused more on data-centric architecture modeling. jackson[note] There are similar points of view.
Data is an element of information that a component receives or sends through a connector. Examples of data include byte sequences, messages, encoded parameters, and serialized objects, but not information that is permanently homed or hidden in the component. From an architectural standpoint, a "file" is actually a transformation in which the file system component receives the "file name" data from its interface and translates it into a sequence of bytes recorded in the (hidden) internal storage system. Components can also generate data, such as software encapsulation that corresponds to a clock or sensor.
In a web-based architecture, the characteristics of data elements often determine whether a particular architectural style is applicable. In the comparison of the mobile Code design paradigm (paradigms), [note] is especially obvious, where you have to choose between two architectural styles: to interact directly with the component, or to convert the component to a data element, over the network to transfer the data element, The data element is then converted in reverse, resulting in a component that can interact with it locally. It is not possible to evaluate a schema without considering data elements at the architectural level.

1.3 Configuration (configurations)

Configuration is the structure of the schema relationship between components, connectors, and data during system operation.
Abowd and others [note] The description of the schema is defined as supporting a description of the system based on three basic semantic classifications. These three semantic classifications are: components-where computing is located, connectors-defining interactions between components, configuration-the collection of components and connectors that interact with each other. These concepts can be visualized visually using a variety of visual symbols associated with a particular architectural style to describe legitimate calculations and interactions, as well as the expected system constraints.
Strictly speaking, you might assume that a configuration is equivalent to a specific constraint on a set of component interactions. For example, Perry and wolf[annotations] include topologies in their schema-form relationships (architectural form ralationships) definitions. However, separating the active topology from the more general constraints makes it easier for architects to differentiate between active configurations and areas where all legitimate configurations might be affected. Medvidovic and taylor[notes] provide an additional rationale (additional rationale) to differentiate configuration-related content in the schema description language.

1.4 Schema attributes (properties)

The set of schema properties for a software architecture includes the selection and arrangement of components, connectors, and data.
All properties. Examples of schema properties include the system-acquired functional attributes (functional properties achieved by) and non-functional attributes (for example, the ease of evolution, reusability of components, efficiency, dynamic expansion capabilities, These are often referred to as quality attributes) (Quality attributes) [notes].
Schema properties are generated by a set of schema constraints in the schema. Schema constraints are often driven by the application of software engineering principles [notes] in one aspect of the schema element. For example, the unified Pipeline and filter (uniform pipe-and-filter) architecture style uses the universal (generality) principle on top of its component interfaces-forcing components to implement a single interface type, which gets the reusability and the configurable qualities of the component from the application. As a result, schema constraints are "unified component interfaces" driven by the generality principle to achieve the desired quality of the two above, and when this architectural style is implemented in the architecture, these two qualities become the architectural properties of reusable and configurable components.
The goal of the architecture design is to create a schema that contains a set of schema properties that form a superset of the system requirements. The relative importance of different architectural attributes depends on the nature of the system that is expected. Section 2.3 examines the architectural attributes that are particularly important for web-based architectures.

1.5 architectural style (styles)

Architectural styles are a set of collaborative architectural constraints that limit the role and functionality of the schema elements and the relationships between the elements that are allowed to exist in any schema that follows the architectural style.
Because a schema includes both functional and non-functional attributes, it can be difficult to directly compare the architecture of different types of systems, or even compare the architecture of the same type of system in different environments. Architectural styles are a mechanism for classifying schemas and defining their public characteristics [notes]. Each architectural style provides an abstraction for the interaction of components and captures the essential characteristics of an interactive pattern (pattern of interation) by ignoring the occasional details of the rest of the schema [note].
Perry and wolf[notes] define the architectural style as: The abstraction of various schema element types (element types) and the formal aspects of multiple specific schemas (formal aspects, perhaps focusing only on some specific aspects of the architecture, not all aspects of the schema). An architectural style encapsulates important decisions about architectural elements, emphasizing important constraints on elements and their relationships. This definition allows the architectural style to focus only on the architecture of the connector, or on some specific aspects of the component interface.
In contrast, Garlan and shaw[notes], Garlan, and others [notes], Shaw, and clements[notes] define architectural styles based on the interaction patterns between various types of components. Specifically, an architectural style determines which components and connectors can be used in an architectural instance of this architectural style, and a set of constraints that combine them [notes]. This narrow view of architectural style is a direct result of their software architecture definition-that is, to view the architecture as a formal description rather than a running system, which leads them to abstract only based on shared patterns (GKFX patterns) that are summarized from diagrams containing boxes and lines. Abowd and others [note] Further, the architectural style is clearly defined as a set of conventions (collection of conventions) used to interpret a class of schema descriptions (architectural descriptions).
The new architecture can be defined as an instance of a particular architectural style (instances) [note]. Because architectural styles can emphasize different aspects of the software architecture, a particular architecture may be composed of a variety of architectural styles. Similarly, a mix of architectural styles can be formed by combining a variety of basic architectural styles into a single collaborative architectural style (coordinated style).
Some architectural styles are often described as "silver-bullet" solutions for all forms of software. However, a good designer should choose an architectural style that best matches the specific problem being addressed [note]. To choose the right architectural style for a web-based application, you must understand the problem areas that the application belongs to [note]. It is therefore necessary to understand the communication needs of the application, to understand the different architectural styles and the special problems they cause, and to be able to predict the characteristics of each interaction style for network-based communication (the characteristics of network-based Communication) sensitivity (sensitivity) [note].
Unfortunately, it is often confusing to use the term "style" to express a set of mutually collaborative architectural constraints. This usage differs greatly from the use of the word "style" in dictionaries, which emphasizes the personalization of the design process. Loerke[Notes] A chapter to belittle the idea that professional architects retain their positions for personalized style at work. Instead, he describes the style as a critic's view of the past architecture (past architecture), which is to be responsible for the architectural style, not by the designer, but by the choice of ingredients, community culture, and the self-awareness of the ruler. In other words, loerke that the real source of style in a traditional architecture is a set of constraints that apply to design, and that achieving or duplicating a particular style should be the minimum goal of the designer. By calling a set of named schema constraints a style that makes it easier to express the characteristics of a public constraint (common constraints), we use architectural style as an abstraction rather than a hint of a personalized design.

1.6 Mode and schema language (Patterns and pattern Languages)

While architecture-style software engineering studies, the object-oriented programming community has been exploring how to use design patterns and schema languages to describe recurring abstractions in the field of Object-based (object-based) software development. A design pattern is defined as an important and recurring system construct. A schema language is a system of patterns that are organized in a structure that directs the application of these patterns [notes]. The concepts of design patterns and pattern languages are based on the content of architecture in the writings of Alexander and others [3,4].
The design space of the pattern includes implementation concerns specific to object-oriented programming techniques, such as class inheritance and interface composition, and high-level design issues resulting from architectural styles [notes]. In some cases, the description of the architectural style is also referred to as the schema pattern (architectural patterns) [note]. However, one of the main advantages of the pattern is that they can describe a rather complex interaction protocol between objects as a single abstraction [annotation], which includes both the behavior constraints and the implementation details. In general, a pattern or pattern language that is integrated with multiple schemas can be seen as a way to implement a set of expected interactions between objects. In other words, by following a fixed path in terms of design and implementation selection (Implementationchoices), a pattern defines a process for solving the problem [note].
Like the architectural style of software, the study of software patterns deviates from its origins in architecture. In fact, the core of the model concept proposed by Alexander is not the permutation of recurring architectural elements, but the pattern of recurring (human activity and emotional) events occurring within a space. Alexander also understands that the pattern of events cannot be separated from the space in which these events occur [note]. Alexander's philosophy of design is to identify the common patterns of life in target culture (the pattern of lives, which can be associated with the "patterns of events" described above), Determine what schema constraints can be used to divide a particular space so that the desired life pattern can naturally arise in this space. These patterns exist at multiple levels of abstraction and in all sizes.
As an element of the world, each pattern is a relationship in a particular environment,
A specific mechanical system that recurs in the environment. There is a specific spatial configuration that allows these forces (forces) in the system to solve for themselves, supporting each other and eventually achieving a stable state.
As an element in the schema language, the pattern represents a guide that shows how, in a meaningful environment, it is possible to reuse this spatial configuration over and over again to solve a particular mechanical system.
Patterns, in short, are both a thing that appears in the world and a rule that tells us how to create this thing and when it must be created. A pattern is both a process and a thing, a description of a living thing as well as a description of the process of generating it [note].
In many ways, compared to the design patterns in object-oriented programming language (OOPL) research, the Alexander pattern actually has more in common with the software architecture style. An architectural style, as a set of mutually collaborative architectural constraints, is applied to a design space in order to induce the system to appear the desired schema attributes. By applying an architectural style, the architect distinguishes between different software design spaces, hoping that the results will better match some of the prerequisites inherent in the application, which can lead to a system's behavior that enhances the natural pattern (natural pattern, the translator notes: Can be "naturally produced" with the above-mentioned Associated), rather than conflict with it (Translator Note: This passage is very consistent with Lao Tzu's "Tao Nature" idea).

1.7 Views (view)

Schema views are often application-specific and vary based on the field of application ... We've seen that the schema view solves a lot of problems, including: time-related issues (temporal issues), State and control methods (states and controls approaches), presentation of data, Transaction lifecycle (Transaction life cycle), security safeguards, peak demand, and graceful downgrade (graceful degradation). No doubt, in addition to these views, there are many possible views. Comments
Observing a schema can be seen in many other ways, in addition to the many architectural styles of architecture and composition architecture in a system. Perry and wolf[notes] Describe three important software architecture views: processing, data, connectivity. The processing view focuses on the data flow that flows through the components and the data-related aspects of the connections between components. The Data view focuses on the process of processing, not the connector. The connection view focuses on the relationship between components and the state of communication.
Using multiple architectural views is commonplace in case studies of specific architectures [notes]. In the architecture design methodology of the 4+1 view model [note], 5 collaborative views are used to organize the description of the software architecture, each of which is dedicated to solving a specific set of concerns.

1.8 Related work

I have included only those research areas that define the software architecture or describe the style of the software architecture. Other software architecture research areas include architecture analysis technology (architectural analyst techniques), architecture Recovery and reengineering (architecture recovery and re-engineering), Tools and environments for architecture design (tools and environments for architectural design), refinement from specification to implementation (architecture refinement from specification to implementation), as well as case studies of deployed software architectures (cases studies of deployed software architectures) [note]. Relevant work in these areas is discussed in chapter 3rd on the classification of architectural styles, the Distributed process paradigm (Distributed process paradigms), and the middleware.

1.8.1 Design Methodology

Most of the early software architecture research was focused on design methodology (methodologies). For example, object-oriented design [annotations] advocates a structured approach to solving problems that can naturally lead to an object-based architecture (or, to be more precise, no other form of architecture). One of the first design methodologies to emphasize design at the architectural level is the Jackson System development Methodology (JSD) [note]. JSD intends to structure the analysis of the problem so that it can lead to an architectural style that combines the style of the pipeline and filter (Pipe-and-filter, also known as data flow) and the Process Control constraint (the work-constraints) style. These design methodologies usually only produce an architectural style.
The researchers conducted some preliminary studies on the methodology of architecture analysis and development. Kazman (architectural trade-off analysis), by using scenario-based analysis (scenario-based analyses) and atam[annotations for saam[comments) Describes the design methodology used to identify the architecture aspect (architectural aspects). Shaw[notes] Comparing the various square arrow design (Box-and-arrow designs) diagrams of a car navigation control system, a different design methodology is used in each design and includes a variety of architectural styles.

1.8.2 design, design pattern, pattern language manual

In keeping with the traditional engineering disciplines, shaw[notes] advocates for the development of the architecture Manual (architectural handbooks). The object-oriented programming community took the lead in developing a catalogue of design patterns, as exemplified by the "Gang of Four" book (Translator note: The famous "design pattern" black book) [notes], Coplien and schmidt[notes].
Software design patterns are more oriented toward specific problems (problem-oriented) than architectural styles. shaw[note] Based on the architectural style described in [notes], 8 examples of architectural patterns are presented, as well as the types of problems that are most appropriate for each architecture. Buschmann and others [note] A comprehensive review of the common schema patterns in object-based development (object-based development). These two references
Are purely descriptive and do not attempt to compare or demonstrate the differences between architectural patterns.
Tepfenhart and cusick[notes] use a two-dimensional map to differentiate domain taxonomy (domain taxonomies), domain models, architectural styles, frameworks, toolkits, design patterns, and application software. In this topology diagram, the design pattern is a pre-engineered structure used as a building block for the software Architecture (building block), while the architectural style is a set of running characteristics (sets of operational characteristics), Used to identify an architecture family that is independent of the application domain (architectural family). However, none of them have succeeded in defining the schema itself.

1.8.3 Reference Model and domain-specific software architecture

The researchers developed a variety of reference models that provide a conceptual framework for describing the interrelationships between architecture and presentation components [note]. Omg[Notes] Developed Object Management Architecture (OMA) as a reference implementation of the proxy distributed object Architecture (brokered distributed object architectures), OMA details how to define and create objects, how client applications Invoke objects , how to share and reuse objects. The focus is on the management of distributed objects, rather than on efficient interactions in applications.
Hayes-roth and others [note] The domain-specific software architecture (DSSA) is defined as consisting of the following: a) a reference architecture that describes a common conceptual framework for a significant application area. b) A library of components that contains expert knowledge of reusable domains. c) An application configuration method that is used to select and configure components in the architecture to meet specific application requirements. Tracz[notes] for Dssa (general overview).
By limiting the software development space (software development spaces) to a specific architectural style that meets the needs of a particular domain, the Dssa project successfully shifts the focus of architectural decisions to a running system (running Systems) (note: Instead of just focusing on the box line chart) [note]. Examples of Dssa include: adage[notes for avionics), ais[annotations for Adaptive Intelligent Systems, metah[notes for missile navigation, navigation, and control systems). Dssa more emphasis on the reuse of components (a common architectural domain) in a common architecture domain, rather than how to choose the architectural style specific to each system.

1.8.4 Schema description Language

Most recently released software architecture-related work is in the domain of Architecture Description Language (ADL). According to the definition of Medvidovic and taylor[notes], ADL is a language used to articulate the conceptual architecture of software systems (conceptual architecture) and to model these conceptual architectures. ADL includes at least the following sections: components, component interfaces, connectors, and schema configuration.
Darwin is a declarative (declarative) language that is intended to be a general-purpose presentation that details the structure of a system consisting of different components using different interaction mechanisms [note]. The interesting thing about Darwin is that it allows for a detailed description of the distributed architecture (distributed architectures) and the dynamic Composition architecture (dynamically composed architectures) [note].
Unicon[Notes] is a group of languages and associated toolsets that combine a limited set of components and connectors into one schema. wright[Note] Specifies the type of connector (based on the Protocol of the interaction), providing a formalized basis for describing the interaction between schema components (formal basis).
As with design methodologies, ADL often introduces specific architectural assumptions that may affect the ability of the language to describe some architectural styles and may contradict assumptions that exist in existing middleware [notes]. In some cases, a ADL is designed specifically for a single architectural style, which is at the expense of loss of commonality and enhances its ability to describe and analyze professionally. For example, c2sadel[comment] is a adl[annotation specifically designed to describe a architecture developed in C2 style. In contrast, acme[annotation] is an attempt to generalize as much as possible to the ADL. The tradeoff for Acme is that it does not support architectural style-specific analysis and construction of real-world applications, but rather supports the exchange of analytical results between different analytical tools (interchange among Analysis tool).

1.8.5 formalized architecture model

Abowd and others [note] It is claimed that the architectural style can be formally described based on a small set of mappings from the syntactic domain (box line graph) of the architecture description to the semantic domain of the schema meaning. The assumption, however, is that the schema is a description, not an abstraction of a running system.
Inverardi and wolf[notes] Use the expression form of a chemical abstraction machine (CHAM) to model software architecture elements as chemicals, using clearly defined rules to control the reactions that occur on top of these elements. Cham specifies the behavior of a component based on how the component transforms the available data elements and how to propagate many single transformations to the entire system using a composition rule. Although this is a very interesting model, it is still unclear: if the purpose of an architectural form exceeds the mere conversion of a data stream, how can cham be used to describe this form of architecture?
rapide[annotation] is a parallel, event-based simulation language designed specifically for defining and simulating system architectures. The emulator generates a set of partially ordered (partially-ordered) events that can be used to analyze the consistency of schema constraints on the internal connection (interconnection). Le métayer[Notes] presents a way to define the expression of a schema (formalism) based on the syntax of graphs and graphs.

1.9 Summary

This chapter discusses the background of this paper, introduces and formalized a set of self-just software architecture concept terminology. These terms are required to avoid confusion between the schema and schema descriptions that are common in the literature. Especially in early architectural studies, data is often not used as an important architectural element. Finally, I investigated a number of other studies related to software architecture and architectural styles.
The next two chapters will continue our discussion of background material by focusing on the architecture of Web-based applications, and describe how to use architectural styles to guide their architectural design, and then use a Taxonomy methodology (classification Methodology) to investigate the common architectural style, This classification methodology focuses on schema attributes, which are generated when the architectural style is applied to a network-based hypermedia architecture.

Architectural style and architecture design based on Web application software (i.)

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.