Network-based Application Architectures
2.1 Scope
Network-based Application Architectures
2.1.1 Network-based vs. Distributed
The primary distinction between network-based architectures and software architectures in general is that communication between components is restricted to message passing, or the equivalent of message passing if a more efficient mechanism can be selected at runtime based on the location of components.
The disctinction between distributed systems and network-based systems: a distributed system is one that looks in users’ opinion like an ordinary centralized system, but runs on multiple, independent CPUs. In contrast, network-based systems are those capable of operation across a network, but not necessarily in a fashion that is transparent to the user.
2.1.2 Application Software vs. Networking Software
Application software architecture is an abstraction level of an overall system, in which the goals of a user action are representable as functional architectural properties. The goal of networking abstraction (behavioral architectural properties) is to move bits from one location to another without regard towhy those bits are being moved.
2.2 Evaluating the Design of Application Architectures
An architecture is the realization of an architectural design and not the design
itself.
The first level of evaluating the design: the application’s functional requirements.
The second level of evaluating it: regard the architectural style asa derivation tree based on a set of architectural constraints because the architectural constraints are in line with the architectural style.
The third level: build such a derivation tree of architectural constraints for a given application domain, and then use the tree to evaluate many different architectural designs for applications within that domain. Thus, building a derivation tree provides a mechanism for architectural design guidance.
The fourth level: ensuring consistency is to make the tree domain-specific.
The fifth level: rationally evaluate the design between trade-offs.
2.3 Architectural Properties of Key Interest
2.3.1 Performance
The performance of a network-based application is bound first by the application
requirements, then by the chosen interaction style, followed by the realized architecture, and finally by the implementation of each component.
2.3.1.1 Network Performance
Network performance is measured by some attributes of communication: throughput, overhead, bandwidth, (useable bandwidth).
Styles impact network performance by their influence on the number of interactions
per user action and the granularity of data elements.
2.3.1.2 User-perceived Performance
The primary measures for user-perceived performance are latency and completion time.
1. Latency occurs:
1) the time needed for the application to recognize the event that initiated the action; 2) the time required to setup the interactions between components; 3) the time required to transmit each interaction to the components; 4) the time required to process each interaction on those components; and, 5) the time required to complete sufficient transfer and processing of the result of the interactions before the application is able to begin rendering a usable result. It is important to notethat, (i) only (3) and (5) represent actual network communication, (ii) all five points can be impacted by the architectural style.
2. Completion is the amount of time taken to complete an application action.
It is important to note that design considerations for optimizing latency will often have the side-effect of degrading completion time, and vice versa.
2.3.1.3 Network Efficiency
1.The most efficient architectural styles for a network-based application are those that can effectively minimize use of the network when it is possible to do so.
2.Method: reuse of prior interactions (caching), reduction of the frequency of network interactions in relation to user actions (replicated data and disconnected operation), or by removing the need for some interactions by moving the processing of data closer to the source of the data (mobile code).
3.The impact of the various performance issues is often related to the scope of
distribution for the application.(LAN or WAN, a single process or multi-processes, etc)
2.3.2 Scalability
Scalability refers to the ability of the architecture to support large numbers of components, or interactions among components, within an active configuration.
2.3.3 Simplicity
1. principle of separation of concerns(分離關注點原則)
2. principle of generality(通用性原則), it generates middleware.
3. properties: complexity, understandability, and verifiability
2.3.4 Modifiability
Modifiability can be explained as evolvability, extensibility, customizability, configurability, and reusability, as described below.
2.3.4.1 Evolvability(可進化性)
1. Static evolution: depends on how well the architectural abstraction is enforced by the implementation, thus is not unique to any particular architectural style.
2. Dynamic evolution: can be influenced by the style if it includes constraints on the maintenance and location of application state.
2.3.4.2 Extensibility
1. Dynamic extensibility implies that functionality can be added to a deployed system without impacting the rest of the system.
2. Extensibility is induced within an architectural style by reducing the coupling between components.
2.3.4.3 Customizability
1. Customizability refers to the ability to temporarily specialize the behavior of an architectural element, such that it can then perform an unusual service.
2. Styles that support customization may also improve simplicity and scalability, since service components can be reduced in size and complexity by directly implementing only the most frequent services and allowing infrequent services to be defined by the client.
2.3.4.4 Configurability
Two examples: the pipe-and-filter and code-on-demand styles (管道-過濾器風格和按需代碼風格).
2.3.4.5 Reusability
The primary mechanisms for inducing reusability within architectural styles is reduction of (1) coupling (knowledge of identity) between components and (2) constraining the generality of component interfaces.
2.3.5 Visibility
2.3.6 Portability
2.3.7 Reliability
Styles can improve reliability by avoiding single points of failure, enabling redundancy, allowing monitoring, or reducing the scope of failure to a recoverable action.