2. 鍦ㄥ垪鍑虹殑蹇嵎閿垪琛ㄤ腑鏌ユ壘鍒幫細(xì)word competion錛屾妸瀹冪殑蹇嵎閿產(chǎn)lt + / 鏀規(guī)垚鍏跺畠鐨勫揩鎹烽敭錛堟庝箞鏀癸紝鍏堟妸姝ゅ揩鎹烽敭鍒犻櫎錛岀偣鍙寵竟鐨勬寜閽?remove binding", 鍐嶉変腑binding鏂囨湰妗嗭紝杈撳叆浣犳兂瑕佺殑蹇嵎閿級銆?
3. 鍦ㄥ垪鍑虹殑蹇嵎閿垪琛ㄤ腑鏌ユ壘鍒幫細(xì)content assist錛屾妸瀹冪殑蹇嵎閿?ctrl + space 鏀規(guī)垚鎴戜滑鎯崇殑鐨?alt + / 鍗沖彲浜嗐?br />
瑙ｅ喅鍔炴硶浜岋細(xì)
window->Preferences->Java->Editor->Content Assist->Advanced
涓婇潰鐨勯夐」鍗elect the proposal kinds contained in the 'default' content assist list: 涓妸 Other Java Proposals 閫夐」鎵撲笂鍕懼氨鍙互浜嗐?
]]>
DISC can be developed as a prototype system of Google's instructure, we can divide it into two types of partitions: one for application development, and the other for system research.
For the program development partitions, we can use available software, such as the open source code from the Hadoop project, to implement the file system and support for application programming.
For the systems research partitions, we can create our own design, studying the different kinds of design patterns. (e.g.: high-end hardware, low-cost component).
The paper Data-Intensive Supercomputing: The case for DISC gives me an entire impression of a new form of high-performance computing facility, and there are many other aspects that deeply attract me, I've taken notes on this paper as follows:
闃呰Paper錛?/span>
Data-Intensive Supercomputing: The case for DISC
Randal E. Bryant May 10, 2007 CMU-CS-07-128
Question錛?/span>How can university researchers demonstrate the credibility of their work without having comparable computing facilities available?
1 Background
Describe a new form of high-performance computing facility (Data-Intensive Super Computer) that places emphasis on data, rather than raw computation, as the core focus of the system.
The author inspiration for DISC: comes from the server infrastructures that have been developed to support search over the worldwide web.
This paper outlines the case for DISC as an important direction for large-scale computing systems.
1.1 Motivation
The common role in the computations:
• Web search without language barriers. (No matter in which language they type the query)
• Inferring biological function from genomic sequences.
• Predicting and modeling the effects of earthquakes.
• Discovering new astronomical phenomena from telescope imagery data.
• Synthesizing realistic graphic animations.
• Understanding the spatial and temporal patterns of brain behavior based on MRI data.
2 Data-Intensive Super Computing
Conventional (Current) supercomputers:
are evaluated largely on the number of arithmetic operations they can supply each second to the application programs.
Advantage: highly structured data requires large amounts of computation.
Disadvantage:
1. It creates misguided priorities in the way these machines are designed, programmed, and operated;
2. Disregarding the importance of incorporating computation-proximate, fast-access data storage, and at the same time creating machines that are very difficult to program effectively;
3. The range of computational styles is restricted by the system structure.
The key principles of DISC:
1. Intrinsic, rather than extrinsic data.
2. High-level programming models for expressing computations over the data.
3. Interactive access.
4. Scalable mechanisms to ensure high reliability and availability. (error detection and handling)
3 Comparison to Other Large-Scale Computer Systems
3.1 Current Supercomputers
3.2 Transaction Processing Systems
3.3 Grid Systems
4 Google: A DISC Case Study
1. The Google system actively maintains cached copies of every document it can find on the Internet.
The system constructs complex index structures, summarizing information about the documents in forms that enable rapid identification of the documents most relevant to a particular query.
When a user submits a query, the front end servers direct the query to one of the clusters, where several hundred processors work together to determine the best matching documents based on the index structures. The system then retrieves the documents from their cached locations, creates brief summaries of the documents, orders them with the most relevant documents first, and determines which sponsored links should be placed on the page.
2. The Google hardware design is based on a philosophy of using components that emphasize low cost and low power over raw speed and reliability. Google keeps the hardware as simple as possible.
They make extensive use of redundancy and software-based reliability.
These failed components are removed and replaced without turning the system off.
Google has significantly lower operating costs in terms of power consumption and human labor than do other data centers.
3. MapReduce, that supports powerful forms of computation performed in parallel over large amounts of data.
Two function: a map function that generates values and associated keys from each document, and a reduction function that describes how all the data matching each possible key should be combined.
MapReduce can be used to compute statistics about documents, to create the index structures used by the search engine, and to implement their PageRank algorithm for quantifying the relative importance of different web documents.
4. BigTable: a distributed data structures, provides capabilities similar to those seen in database systems.
5 Possible Usage Model
The DISC operations could include user-specified functions in the style of Google’s MapReduce programming framework. As with databases, different users will be given different authority over what operations can be performed and what modifications can be made.
6 Constructing a General-Purpose DISC System
The open source project Hadoop implements capabilities similar to the Google file system and support for MapReduce.
Constructing a General-Purpose DISC System錛?/span>
• Hardware Design.
There are a wide range of choices;
We need to understand the tradeoffs between the different hardware configurations and how well the system performs on different applications.
Google has made a compelling case for sticking with low-end nodes for web search applications, and the Google approach requires much more complex system software to overcome the limited performance and reliability of the components. But it might not be the most cost-effective solution for a smaller operation when personnel costs are considered.
• Programming Model.
1. One important software concept for scaling parallel computing beyond 100 or so processors is to incorporate error detection and recovery into the runtime system and to isolate programmers from both transient and permanent failures as much as possible.
Work on providing fault tolerance in a manner invisible to the application programmer started in the context of grid-style computing, but only with the advent of MapReduce and in recent work by Microsoft has it become recognized as an important capability for parallel systems.
2. We want programming models that dynamically adapt to the available resources and that perform well in a more asynchronous execution environment.
e.g.: Google’s implementation of MapReduce partitions a computation into a number of map and reduce tasks that are then scheduled dynamically onto a number of “worker” processors.
• Resource Management.
Problem: how to manage the computing and storage resources of a DISC system.
We want it to be available in an interactive mode and yet able to handle very large-scale computing tasks.
• Supporting Program Development.
Developing parallel programs is difficult, both in terms of correctness and to get good performance.
As a consequence, we must provide software development tools that allow correct programs to be written easily, while also enabling more detailed monitoring, analysis, and optimization of program performance.
• System Software.
System software is required for a variety of tasks, including fault diagnosis and isolation, system resource control, and data migration and replication.
Google and its competitors provide an existence proof that DISC systems can be implemented using available technology. Some additional topics include:
• How should the processors be designed for use in cluster machines?
• How can we effectively support different scientific communities in their data management and applications?
• Can we radically reduce the energy requirements for large-scale systems?
• How do we build large-scale computing systems with an appropriate balance of performance and cost?
• How can very large systems be constructed given the realities of component failures and repair times?
• Can we support a mix of computationally intensive jobs with ones requiring interactive response?
• How do we control access to the system while enabling sharing?
• Can we deal with bad or unavailable data in a systematic way?
• Can high performance systems be built from heterogenous components?
7 Turning Ideas into Reality
7.1 Developing a Prototype System
Operate two types of partitions: some for application development, focusing on gaining experience with the different programming techniques, and others for systems research, studying fundamental issues in system design.
For the program development partitions:
Use available software, such as the open source code from the Hadoop project, to implement the file system and support for application programming.
For the systems research partitions:
Create our own design, studying the different layers of hardware and system software required to get high performance and reliability. (e.g.: high-end hardware, low-cost component)
7.2 Jump Starting
Begin application development by renting much of the required computing infrastructure:
1. network-accessible storage: Simple Storage System (S3) service
2. computing cycles: Elastic Computing Cloud (EC2) service
(The current pricing for storage is $0.15 per gigabyte per day ($1,000 per terabyte per year), with addition costs for reading or writing the data. Computing cycles cost $0.10 per CPU hour ($877 per year) on a virtual Linux machine.)
Renting problems:
1. The performance of such a configuration is much less than that of a dedicated facility.
2. There is no way to ensure that the S3 data and the EC2 processors will be in close enough proximity to provide high speed access.
3. We would lose the opportunity to design, evaluate, and refine our own system.
7.3 Scaling Up
8 Conclusion
1. We believe that DISC systems could change the face of scientific research worldwide.
2. DISC will help realize the potential all these data such as the combination of sensors and networks to collect data, inexpensive disks to store data, and the benefits derived by analyzing data provides.
]]>
System Challenges錛?/span>
Data distributed over many disks
Compute using many processors
Connected by gigabit Ethernet (or equivalent)
System Requirements:
Lots of disks
Lots of processors
Located in close proximity
System Comparison:
(i) Data
|
Conventional Supercomputers |
DISC |
|
Data stored in separate repository No support for collection or management Brought into system for computation Time consuming Limits interactivity |
System collects and maintains data Shared, active data set Computation colocated with storage Faster access |
(ii) Programing Models
|
Conventional Supercomputers |
DISC |
|
Programs described at very low level Specify detailed control of processing & communications Rely on small number of software packages Written by specialists Limits classes of problems & solution methods |
Application programs written in terms of high-level operations on data Runtime system controls scheduling, load balancing, … |
(iii) Interaction
|
Conventional Supercomputers |
DISC |
|
Main Machine: Batch Access Priority is to conserve machine resources User submits job with specific resource requirements Run in batch mode when resources available Offline Visualization Move results to separate facility for interactive use |
Interactive Access Priority is to conserve human resources User action can range from simple query to complex computation System supports many simultaneous users Requires flexible programming and runtime environment |
(iv) Reliability
|
Conventional Supercomputers |
DISC |
|
“Brittle” Systems Main recovery mechanism is to recompute from most recent checkpoint Must bring down system for diagnosis, repair, or upgrades |
Flexible Error Detection and Recovery Runtime system detects and diagnoses errors Selective use of redundancy and dynamic recomputation Replace or upgrade components while system running Requires flexible programming model & runtime environment |
Comparing with Grid Computing:
Grid: Distribute Computing and Data
(i) Computation: Distribute problem across many machines
Generally only those with easy partitioning into independent subproblems
(ii) Data: Support shared access to large-scale data set
DISC: Centralize Computing and Data
(i) Enables more demanding computational tasks
(ii) Reduces time required to get data to machines
(iii) Enables more flexible resource management
A Commercial DISC
Netezza Performance Server (NPS)
Designed for “data warehouse” applications
Heavy duty analysis of database
Data distributed over up to 500 Snippet Processing Units
Disk storage, dedicated processor, FPGA controller
User “programs” expressed in SQL
Constructing DISC
Hardware: Rent from Amazon
Elastic Compute Cloud (EC2)
Generic Linux cycles for $0.10 / hour ($877 / yr)
Simple Storage Service (S3)
Network-accessible storage for $0.15 / GB / month ($1800/TB/yr)
Software: utilize open source
Hadoop Project
Open source project providing file system and MapReduce
Supported and used by Yahoo
Implementing System Software
Programming Support
Abstractions for computation & data representation
E.g., Google: MapReduce & BigTable
Usage models
Runtime Support
Allocating processing and storage
Scheduling multiple users
Implementing programming model
Error Handling
Detecting errors
Dynamic recovery
Identifying failed components
]]>
1.鍗曞厓嫻嬭瘯鐨勭紪鍐欏師鍒?br /> 涓変釜鎬諱綋鐩爣錛氱涓涓槸綆鍖栨祴璇曠殑緙栧啓錛岃繖縐嶇畝鍖栧寘鎷祴璇曟鏋剁殑瀛︿範(fàn)鍜屽疄闄呮祴璇曞崟鍏冪殑緙栧啓錛涚浜屼釜鏄嬌嫻嬭瘯鍗曞厓淇濇寔鎸佷箙鎬э紱絎笁涓垯鏄彲浠ュ埄鐢ㄦ棦鏈夌殑嫻嬭瘯鏉ョ紪鍐欑浉鍏崇殑嫻嬭瘯銆?br /> 2. 濡備綍紜畾鍗曞厓嫻嬭瘯
涓涓崟鍏冩祴璇曞熀鏈槸浠ヤ竴涓璞＄殑鏄庣‘鐗規(guī)т負(fù)鍩虹錛屽崟鍏冩祴璇曠殑榪囩▼搴旇闄愬畾鍦ㄤ竴涓槑紜殑綰跨▼鑼冨洿鍐呫?br /> 涓轟簡紜畾涓涓郴緇熸渶緇堢殑琛屼負(fù)絎﹀悎鎴戜滑璧峰鐨勮姹傦紝鎴戜滑棣栧厛闇瑕佷繚璇佺郴緇熷唴鐨勫悇涓儴鍒嗙殑鐘舵佷細(xì)絎﹀悎鎴戜滑鐨勮璁¤姹傦紝鎵浠ユ垜浠殑嫻嬭瘯鍗曞厓鐨勯噸鐐瑰簲璇ユ斁鍦ㄧ‘瀹氬璞＄殑鐘舵佸彉鎹笂銆?br /> 搴旇鍦ㄦ湁鍙兘寮曞叆閿欒鐨勫湴鏂瑰紩鍏ユ祴璇曞崟鍏冿紝閫氬父榪欎簺鍦版柟瀛樺湪浜庢湁鐗瑰畾杈圭晫鏉′歡銆佸鏉傜畻娉曚互鍙?qiáng)闇姹傚彉鍔ㄦ瘮杈冮綣佺殑浠ｇ爜閫昏緫涓傞櫎浜嗚繖浜涚壒鎬ч渶瑕佽緙栧啓鎴愮嫭绔嬬殑嫻嬭瘯鍗曞厓澶栵紝榪樻湁涓浜涜竟鐣屾潯浠舵瘮杈冨鏉傜殑瀵硅薄鏂規(guī)硶涔熷簲璇ヨ緙栧啓鎴愮嫭绔嬬殑嫻嬭瘯鍗曞厓錛岃繖閮ㄥ垎鍗曞厓嫻嬭瘯宸茬粡鍦↗unit鏂囨。涓杈冨ソ鐨勬弿榪板拰瑙ｉ噴榪囦簡銆?br /> 3. 濡備綍緙栧啓鍗曞厓嫻嬭瘯
浜? junit涓殑assert鏂規(guī)硶鍏ㄩ儴鏀懼湪Assert綾諱腑錛屾葷粨涓涓媕unit綾諱腑assert鏂規(guī)硶鐨勫垎綾匯?br /> 1.assertTrue/False([String message,]boolean condition);
鍒ゆ柇涓涓潯浠舵槸true榪樻槸false銆傜敤閫旀渶騫褲?br /> 2.fail([String message,]);
澶辮觸錛屽彲浠ユ湁娑堟伅錛屼篃鍙互娌℃湁娑堟伅銆?br /> 3.assertEquals([String message,]Object expected,Object actual);
鍒ゆ柇鏄惁鐩哥瓑錛屽彲浠ユ寚瀹氳緭鍑洪敊璇俊鎭?br /> 絎竴涓弬鏁版槸鏈熸湜鍊鹼紝絎簩涓弬鏁版槸瀹為檯鐨勫箋?br /> 榪欎釜鏂規(guī)硶瀵瑰悇涓彉閲忔湁澶氱瀹炵幇銆傚湪JDK1.5涓熀鏈竴鏍楓?br /> 4.assertNotNull/Null([String message,]Object obj);
鍒よ涓涓璞℃槸鍚﹂潪絀?闈炵┖)銆?br /> 5.assertSame/NotSame([String message,]Object expected,Object actual);
鍒ゆ柇涓や釜瀵硅薄鏄惁鎸囧悜鍚屼竴涓璞°傜湅鍐呭瓨鍦板潃銆?br /> 6.failNotSame/failNotEquals(String message, Object expected, Object actual)
褰撲笉鎸囧悜鍚屼竴涓唴瀛樺湴鍧鎴栬呬笉鐩哥瓑鐨勬椂鍊欙紝杈撳嚭閿欒淇℃伅銆?br /> 娉ㄦ剰淇℃伅鏄繀欏葷殑錛岃屼笖榪欎釜杈撳嚭鏄牸寮忓寲榪囩殑銆?br />
]]>
1銆佷腑鏂湇鍔＄▼搴忎腑淇敼鐨勪緵鍏跺畠紼嬪簭媯嫻嬬殑鍙橀噺闇瑕佸姞volatile;
2銆佸浠誨姟鐜涓嬪悇浠誨姟闂村叡浜殑鏍囧織搴旇鍔爒olatile;
3銆佸瓨鍌ㄥ櫒鏄犲皠鐨勭‖浠跺瘎瀛樺櫒閫氬父涔熻鍔爒olatile璇存槑,鍥犱負(fù)姣忔瀵瑰畠鐨勮鍐欓兘鍙兘鐢變笉鍚屾剰涔?
]]>
瀵逛簬榪欑瘒璁烘枃錛屾垜璁や負(fù)錛屽畠涓嶅崟綰槸涓綃囧浣嶈鏂囷紝鍥犱負(fù)浣滆呯殑鍐欎綔鎵嬫硶錛屽啓浣滆璦鐪熺殑鍊煎緱鎴戝涔?fàn)锛屽锛屽浜庢灦鏋勭殑鏂规硶锛屼綔鑰呬粠derivation tree鐨勮搴︾被姣旈槓榪幫紝褰㈣薄鑰岀敓鍔紝鎴戞兂錛孯oy Thomas Fielding鐨勫崥澹鏂囦負(fù)鎴戜粖鍚庡啓璁烘枃甯姪寰堝ぇ銆?br /> 鍙﹀錛屾湰綃囪鏂囩殑鐭ヨ瘑閲忓緢澶э紝浠呬粠涓綃囨枃绔犱究鍙互瀛﹀埌寰堝鐭ヨ瘑錛屽甯歌鐨勬灦鏋勯鏍鹼紝鏋舵瀯鍏蟲敞鐨勭壒鎬э紝浜掕仈緗戝緢澶氬崗璁殑浜х敓鍙?qiáng)鍙戝睍绛壗{夛紝寰呭畬鏁磋瀹屽悗錛屾垜浼?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ù)鏈?娓存湜鏌愪竴澶╋紝鍦ㄦ煇涓湴鏂癸紝鍥犳煇縐嶅師鍥狅紝鏋舵瀯鍑轟竴搴т笉鍙濊鐨勩佺編涓界殑銆佷護(hù)浜哄績鍔ㄧ殑寤虹瓚錛屽湪閭ｉ噷錛屼漢浠彲浠ヨ璧幫紝鍙互姊︽兂錛屽巻緇忔暟鐧懼勾渚濈劧鍌茬劧鎸烘嫈銆?#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
]]>