瀵逛簬榪欑瘒璁烘枃錛屾垜璁や負(fù)錛屽畠涓嶅崟綰槸涓綃囧浣嶈鏂囷紝鍥犱負(fù)浣滆呯殑鍐欎綔鎵嬫硶錛屽啓浣滆璦鐪熺殑鍊煎緱鎴戝涔?fàn)锛屽锛屽浜庢灦鏋勭殑鏂规硶锛屼綔鑰呬粠derivation tree鐨勮搴︾被姣旈槓榪幫紝褰㈣薄鑰岀敓鍔紝鎴戞兂錛孯oy Thomas Fielding鐨勫崥澹鏂囦負(fù)鎴戜粖鍚庡啓璁烘枃甯姪寰堝ぇ銆?br /> 鍙﹀錛屾湰綃囪鏂囩殑鐭ヨ瘑閲忓緢澶э紝浠呬粠涓綃囨枃绔犱究鍙互瀛﹀埌寰堝鐭ヨ瘑錛屽甯歌鐨勬灦鏋勯鏍鹼紝鏋舵瀯鍏蟲敞鐨勭壒鎬э紝浜掕仈緗戝緢澶氬崗璁殑浜х敓鍙婂彂灞曠瓑絳夛紝寰呭畬鏁磋瀹屽悗錛屾垜浼?xì)鏀惰庝h洿澶氾紒
涓栫晫钁楀悕鏋舵瀯澶у笀錛孶C Berkeley鏁欐巿Christopher Alexander璇磋繃涓嬮潰涓孌佃瘽鈥斺?br /> "Each one of us has, somewhere in his heart, the dream to make a living world, a universe. Those of us who have been trained as architects have this desire perhaps at the very center of our lives: that one day, somewhere, somehow, we shall build one building which is wonderful, beautiful, breathtaking, a place where people can walk and dream for centuries."
鎴戝緢鍠滄榪欐璇濓紝鍦ㄦ鎴戞妸瀹冪炕璇戣繃鏉ワ紝鎴戞兂錛屽畠瀵逛笌鎴戯紝鏄竴涓暱鏈熶笉渚跨殑鐩爣錛屾槸涓鑲℃寔涔嬩互鎭掔殑鍔涢噺錛屾洿鏄竴縐嶆亽瀹氫笉鍙樼殑淇″康錛?br /> “鎴戜滑姣忎釜浜猴紝鍦ㄥ唴蹇冩繁澶勯兘鎬鏈変竴涓ⅵ鎯籌細(xì)姊︽兂鍘誨垱閫犱竴涓矞媧葷殑涓栫晫涓庡畤瀹欍傞偅浜涙垨璁稿鍦ㄦ垜浠敓媧葷殑涓績銆佽璁粌浣滀負(fù)鏋舵瀯甯堢殑浜轟滑錛岄兘鎷ユ湁鑰呬竴涓復(fù)鏈?娓存湜鏌愪竴澶╋紝鍦ㄦ煇涓湴鏂癸紝鍥犳煇縐嶅師鍥狅紝鏋舵瀯鍑轟竴搴т笉鍙濊鐨勩佺編涓界殑銆佷護浜哄績鍔ㄧ殑寤虹瓚錛屽湪閭ｉ噷錛屼漢浠彲浠ヨ璧幫紝鍙互姊︽兂錛屽巻緇忔暟鐧懼勾渚濈劧鍌茬劧鎸烘嫈銆?#8221;-- by Christopher Alexander
]]>
5.1 Deriving REST
5.1.1 Starting with the Null Style
Two common perspectives on the process of architectural design:
The first is that a designer starts with nothing鈥攁 blank slate, whiteboard, or drawing board鈥攁nd builds-up an architecture from familiar components until it satisfies the needs of the intended system.
The second is that a designer starts with the system needs as a whole, without constraints, and then incrementally identifies and applies constraints to elements of the system in order to differentiate the design space and allow the forces that influence system behavior to flow naturally, in harmony with the system.
REST is based on the latter process.
The following eight sections depict how the applied constraints would differentiate the process view of an architecture as the incremental set of constraints is applied.
From the Null style (Figure 5-1) is simply an empty set of constraints. It is the starting point for our description of REST.
5.1.2 Client-Server
From the client-server architectural style (Figure 5-2)
Separation of concerns is the principle behind the client-server constraints. Perhaps most significant to the Web is that the separation allows the components to evolve independently, thus supporting the Internet-scale requirement of multiple organizational domains.
5.1.3 Stateless
From the client-stateless-server (CSS) style (Figure 5-3)
Each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server.
Session state is kept entirely on the client.
Advantage: ease the pressure of Sever.
Disadvantage: decrease network performance by increasing the repetitive data in a series of requests in clients.
5.1.4 Cache
From the client-cache-stateless-server style (Figure 5-4).
Requiring: a response is implicitly or explicitly labeled as cacheable or noncacheable.
Advantage: eliminate some interactions.
Disadvantage: decrease reliability if state data within the cache differs significantly from the data that would have been sent directly to the server.
5.1.5 Uniform Interface
The central feature that distinguishes the REST architectural style from other network-based styles is its emphasis on a uniform interface between components (Figure 5-6).
The REST interface is designed to be efficient for large-grain hypermedia data transfer, optimizing for the common case of the Web.
REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state.
5.1.6 Layered System
From layered system constraints (Figure 5-7).
The layered system style allows an architecture to be composed of hierarchical layers by constraining component behavior such that each component cannot “see” beyond the immediate layer with which they are interacting.
5.1.7 Code-On-Demand
From the code-on-demand style (Figure 5-8).
REST allows client functionality to be extended by downloading and executing code in the form of applets or scripts. This simplifies clients by reducing the number of features required to be pre-implemented. Allowing features to be downloaded after deployment improves system extensibility.
5.1.8 Style Derivation Summary
Figure 5-9 depicts the derivation of REST’s constraints graphically in terms of the network-based architectural styles examined in Chapter 3.
5.2 REST Architectural Elements
5.2.1 Data Elements
The nature and state of an architecture’s data elements is a key aspect of REST.
Three fundamental options: 1) render the data where it is located and send a fixed-format image to the recipient; 2) encapsulate the data with a rendering engine and send both to the recipient; or, 3) send the raw data to the recipient along with metadata that describes the data type, so that the recipient can choose their own rendering engine.
5.2.2 Connectors
5.2.3 Components
浠ｇ悊鍜岀綉鍏充箣闂寸殑鍖哄埆鏄紝浣曟椂浣跨敤浠ｇ悊鏄敱瀹㈡埛绔潵鍐沖畾鐨?/span>
5.3 REST Architectural Views
5.3.1 Process View
5.3.2 Connector View
5.3.3 Data View
5.3.1 Process View
5.3.2 Connector View
5.3.3 Data View
]]>
4.1 WWW Application Domain Requirements
4.1.1 Low Entry-barrier
1. Since participation in the creation and structuring of information was voluntary, a low entry-barrier was necessary to enable sufficient adoption. This applied to all users of the Web architecture: readers, authors, and application developers.
2. Simplicity was also a goal for the sake of application developers.
4.1.2 Extensibility
Extensibility: A system intending to be as long-lived as the Web must be prepared for change.
4.1.3 Distributed Hypermedia
1. The usability of hypermedia interaction is highly sensitive to user-perceived latency: the time between selecting a link and the rendering of a usable result.
2. The architecture needs to minimize network interactions.
4.1.4 Internet-scale
1. The Internet is about interconnecting information networks across multiple organizational boundaries.
2. Suppliers of information services must be able to cope with the demands of anarchic scalability and the independent deployment of software components.
4.1.4.1 Anarchic Scalability
1. Anarchic scalability refers to the need for architectural elements to continue operating when they are subjected to an unanticipated load, or when given malformed or maliciously constructed data, since they may be communicating with elements outside their organizational control.
2. The anarchic scalability requirement applies to all architectural elements.
3. Security of the architectural elements, and the platforms on which they operate, also becomes a significant concern.
4.1.4.2 Independent Deployment
4.2 Problem
4.3 Approach
The first step, is to identify the constraints placed within the early Web architecture that are responsible for its desirable properties.
Hypothesis I: The design rationale behind the WWW architecture can be described by an architectural style consisting of the set of constraints applied to the elements within the Web architecture.
The next step, is to identify the properties desirable in an Internet-scale distributed hypermedia system, select additional architectural styles that induce those properties, and combine them with the early Web constraints to form a new, hybrid architectural style for the modern Web architecture.
Hypothesis II: Constraints can be added to the WWW architectural style to derive a new hybrid style that better reflects the desired properties of a modern Web architecture.
The third step, is to use the new architectural style as a guide, we can compare proposed extensions and modifications to the Web architecture against the constraints within the style.
Hypothesis III: Proposals to modify the Web architecture can be compared to the updated WWW architectural style and analyzed for conflicts prior to deployment.
This approach as a single sequence, it is actually applied in a non-sequential, iterative fashion.
4.4 Summary
My approach is to use an architectural style to define and improve the design rationale behind the Web’s architecture, to use that style as the acid test for proving proposed extensions prior to their deployment, and to deploy the revised architecture via direct involvement in the software development projects that have created the Web’s infrastructure.
]]>
3.1 Classification Methodology
In order to provide useful design guidance, a classification of architectural styles should be based on the architectural properties induced by those styles.
3.1.1 Selection of Architectural Styles for Classification
3.1.2 Style-induced Architectural Properties
3.1.3 Visualization
3.2 Data-flow Styles
3.2.1 Pipe and Filter (PF)
Description: In a pipe and filter style, each component (filter) reads streams of data on its inputs and produces streams of data on its outputs, usually while applying a transformation to the input streams and processing them incrementally so that output begins before the input is completely consumed.
Characteristic:
1. One-way data flow network;
2. Zero coupling: a filter must be completely independent of other filters.
Advantage: (by Garlan and Shaw)
1. Simplicity: PF allows the designer to understand the overall input/output of the system as a simple composition of the behaviors of the individual filters.
2. Reusability: any two filters can be hooked together, provided they agree on the data that is being transmitted between them.
3. Extensibility and evolvability: new filters can be added to existing systems (extensibility) and old filters can be replaced by improved ones (evolvability).
4. Verifiability: they permit certain kinds of specialized analysis.
5. User-perceived performance: they naturally support concurrent execution.
6. Configurability: a network of filters is typically arranged just prior to each activation, allowing the application to specify the configuration of filter components based on the task at hand and the nature of the data streams.
Disadvantage:
1. Propagation delay: propagation delay is added through long pipelines;
2. Batch sequential processing occurs if a filter cannot incrementally process its inputs, and no interactivity is allowed.
3. A filter cannot interact with its environment: because it cannot know that any particular output stream shares a controller with any particular input stream.
4. User-perceived performance: these properties decrease user-perceived performance if the problem being addressed does not fit the pattern of a data flow stream.
3.2.2 Uniform Pipe and Filter (UPF)
Characteristic: the uniform pipe and filter style adds the constraint that all filters must have the same interface.
Advantage:
Example: Unix operating system, where filter processes have an interface consisting of one input data stream of characters (stdin) and two output data streams of characters (stdout and stderr).
1. Restricting the interface allows independently developed filters to be arranged at will to form new applications.
2. It also simplifies the task of understanding how a given filter works.
Disadvantage:
It may reduce network performance if the data needs to be converted to or from its natural format.
3.3 Replication Styles
3.3.1 Replicated Repository (RR)
Example: (1) distributed filesystems, such as XMS, and, (2) remote versioning systems, like CVS [www.cyclic.com].
Advantage: Improved user-perceived performance, both by reducing the latency of normal requests and enabling disconnected operation in the face of primary server failure or intentional roaming off the network(綰夸笅婕父).
Concern: Maintaining consistency is the primary concern.
3.3.2 Cache ($)
This form of replication is most often found in cases (1) where the potential data set far exceeds the capacity of any one client, as in the WWW, or (2) where complete access to the repository is unnecessary.
Advantage:caching is much easier to implement, doesn’t require as much processing and storage, and is more efficient because data is transmitted only when it is requested.
A typical network-based architectural style: client-stateless-server style (rest rationale).
3.4 Hierarchical Styles
3.4.1 Client-Server (CS)
Description:
1. A server component: offering a set of services, listens for requests upon those services.
A client component: desiring that a service be performed, sends a request to the server via a connector.
2. by Andrews:
A client is a triggering process;
A server is a reactive process.
Clients make requests that trigger reactions from servers.
A server is usually a non-terminating process and often provides service to more than one client.
Principle:Separation of concerns.
Simplify the server component in order to improve scalability.
Method: moving all of the user interface functionality into the client component.
The partition between C and S components: It is often referred to by the mechanisms used for the connector implementation, such as remote procedure call or message-oriented middleware.
3.4.2 Layered System (LS) and Layered-Client-Server (LCS)
Layered System:
1. A layered system is organized hierarchically, each layer providing services to the layer above it and using services of the layer below it.
2.Layered systems reduce coupling across multiple layers by hiding the inner layers from all except the adjacent outer layer. In all, in multiple layers, every layer only couples the adjacent outer layer, thus improving evolvability and reusability (e.g., TCP/IP and OSI protocol stacks, and hardware interface libraries).
3. Disadvantage:layered systems add overhead and latency to the processing of data, reducing user-perceived performance.
Layered-Client-Server:
Layered-client-server adds proxy and gateway components to the client-server style.
Client -> Proxy -> Gateway -> Server
A proxy acts as a shared server for one or more client components, taking requests and forwarding them, with possible translation, to server components.
A gateway component appears to be a normal server to clients or proxies that request its services, but is in fact forwarding those requests, with possible translation, to its “inner-layer” servers.
3.4.3 Client-Stateless-Server (CSS)
Characteristic: no session stateis allowed on the server component.
Each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is kept entirely on the client.
Advantage: visibility, reliability, and scalability.
Disadvantage:it may decrease network performance by increasing the repetitive data (per-interaction overhead) sent in a series of requests, since that data cannot be left on the server in a shared context.
3.4.4 Client-Cache-Stateless-Server (C$SS)
Characteristic: the client-cache-stateless-server style derives from the client-stateless-server and cache styles via the addition of cache components.
Description: A cache acts as a mediator between client and server in which the responses to prior requests can, if they are considered cacheable, be reused in response to later requests that are equivalent.
Example: an example system that makes effective use of this style is Sun Microsystems’ NFS.
Advantage: cache components have the potential to partially or completely eliminate some interactions, improving efficiency and user-perceived performance.
3.4.5 Layered-Client-Cache-Stateless-Server (LC$SS)
Characteristic: the layered-client-cache-stateless-server style derives from both layered-client-server and client-cache-stateless-server through the addition of proxy and/or gateway components.
Example: an example system that uses an LC$SS style is the Internet domain name system (DNS).
3.4.6 Remote Session (RS)
Characteristic: minimize the complexity, or maximize the reuse of the client components,andthe application state on server.
Description: each client initiates a session on the server and then invokes a series of services on the server, finally exiting the session. Application state is kept entirely on the server.
Example: when it is desired to access a remote service using a generic client (e.g., TELNET) or via an interface that mimics a generic client (e.g., FTP).
Advantage: (1) easier to centrally maintain the interface at the server, (2) reducing concerns about inconsistencies in deployed clients, and (3) improves efficiency if the interactions make use of extended session context on the server.
Disadvantage:(1) reduces scalability of the server, due to the stored application state, and, (2) reduces visibility of interactions, since a monitor would have to know the complete state of the server.
3.4.7 Remote Data Access (RDA)
Characteristic: the remote data access style is a variant of client-server that spreads the application state across both client and server.
Description: a client sends a database query in a standard format, such as SQL, to a remote server. The server allocates a workspace and performs the query,which may result in a very large data set. The client must know about the data structure of the service to build structure-dependent queries.
Advantage:
Eficiency: a large data set can be iteratively reduced on the server side without transmitting it across the network.
Visibility: is improved by using a standard query language.
Disadvantage:
Lacking simplicity: the client needs to understand the same database manipulation concepts as the server implementation
Decreases scalability: storing application context on the server decreases scalability.
Suffered reliability: partial failure can leave the workspace in an unknown state.
3.5 Mobile Code Styles
3.6 Peer-to-Peer Styles
3.7 Limitations
3.8 Related Work
]]>
As described in the previous chapter, an architectural style is a coordinated set of architectural constraints that has been given a name for ease of reference. Each architectural design decision can be seen as an application of a style. Since the addition of a constraint may derive a new style, we can think of the space of all possible architectural styles as a derivation tree, with its root being the null style (empty set of constraints). When their constraints do not conflict, styles can be combined to form hybrid styles, eventually culminating in a hybrid style that represents a complete abstraction of the architectural design. An architectural design can therefore be analyzed by breaking-down its set of constraints into a derivation tree and evaluating the cumulative effect of the constraints represented by that tree. If we understand the properties induced by each basic style, then traversing the derivation tree gives us an understanding of the overall design’s architectural properties. The specific needs of an application can then be matched against the properties of the design. Comparison becomes a relatively simple matter of identifying which architectural design satisfies the most desired properties for that application. "
]]>
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(鍒嗙鍏蟲敞鐐瑰師鍒?/span>)
2. principle of generality(閫氱敤鎬у師鍒?/span>), 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(鍙繘鍖栨?/span>)
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.
]]>
1.1 run-time abstraction
A software architecture is an abstraction of the run-time elements of a software system during some phase of its operation. A system may be composed of many levels of abstraction and many phases of operation, each with its own software architecture.
At the heart of software architecture is the principle of abstraction: hiding some of the
details of a system through encapsulation in order to better identify and sustain its
properties.
The differences between software architecture and software structure: the former is an abstraction of the run-time behavior of a software system, whereas the latter is a property of the static software source code.
1.2 Elements
A software architecture is defined by a configuration of architectural elements 鈥?components, connectors, and data 鈥?constrained in their relationships in order to achieve a desired set of architectural properties.
Components are those that perform transformations on data, data elements are those that contain the information that is used and transformed, and connectors are the glue that holds the different pieces of the architecturetogether.
Software architecture includes architectural properties. Rationale explicates those properties, but the rationale itself is not part of the architecture.
Rather than defining the software’s architecture as existing within the software, it is defining a description of the software’s architecture as if that were the architecture.
1.2.1 Components
A component is an abstract unit of software instructions and internal state that provides a transformation of data via its interface.
1.2.2 Connectors
A connector is an abstract mechanism that mediates communication, coordination, or cooperation among components.
1.2.3 Data
A datum is an element of information that is transferred from a component, or received by a component, via a connector.
1.3 Configurations
A configuration is the structure of architectural relationships among components, connectors, and data during a period of system run-time.
1.4 Properties
1.5 Styles
An architectural style is a coordinated set of architectural constraints that restricts the roles/features of architectural elements and the allowed relationships among those elements within any architecture that conforms to that style.
1.6 Patterns and Pattern Languages
A design pattern is defined as an important and recurring system construct.
The pattern is, in short, at the same time a thing, which happens in the
world, and the rule which tells us how to create that thing, and when we must
create it. It is both a process and a thing; both a description of a thing which is
alive, and a description of the process which will generate that thing.
1.7 Views
three important views in software architecture: processing, data, and connection views. A process view emphasizes the data flow through the components and some aspects of the connections among the components with respect to the data. A data view emphasizes the processing flow, with less emphasis on the connectors. A connection view emphasizes the relationship between components and the state of communication.
]]>
Architectural Styles and the Design of Network-based Software Architectures銆by銆Roy Thomas Fielding
銆銆銆銆銆銆Doctor of Philosophy in Information and Computer Science
銆銆銆銆銆銆University of California, Irvine, 2000
銆銆銆銆銆銆Professor Richard N. Taylor, Chair
銆銆The World Wide Web has succeeded in large part because its software architecture has
been designed to meet the needs of an Internet-scale distributed hypermedia system. The
Web has been iteratively developed over the past ten years through a series of
modifications to the standards that define its architecture. In order to identify those aspects
of the Web that needed improvement and avoid undesirable modifications, a model for the
modern Web architecture was needed to guide its design, definition, and deployment.
銆銆Software architecture research investigates methods for determining how best to
partition a system, how components identify and communicate with each other, how
information is communicated, how elements of a system can evolve independently, and
how all of the above can be described using formal and informal notations. My work is
motivated by the desire to understand and evaluate the architectural design of networkbased
application software through principled use of architectural constraints, thereby
obtaining the functional, performance, and social properties desired of an architecture. An
architectural style is a named, coordinated set of architectural constraints.
銆銆This dissertation defines a framework for understanding software architecture via
architectural styles and demonstrates how styles can be used to guide the architectural
design of network-based application software. A survey of architectural styles for
network-based applications is used to classify styles according to the architectural
properties they induce on an architecture for distributed hypermedia. I then introduce the
Representational State Transfer (REST) architectural style and describe how REST has
been used to guide the design and development of the architecture for the modern Web.
銆銆REST emphasizes scalability of component interactions, generality of interfaces,
independent deployment of components, and intermediary components to reduce
interaction latency, enforce security, and encapsulate legacy systems. I describe the
software engineering principles guiding REST and the interaction constraints chosen to
retain those principles, contrasting them to the constraints of other architectural styles.
Finally, I describe the lessons learned from applying REST to the design of the Hypertext
Transfer Protocol and Uniform Resource Identifier standards, and from their subsequent
deployment in Web client and server software.
Roy Thomas Fielding鍗氬＋璁烘枃鑻辨枃鐗堟湰銆http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
]]>