526 lines
No EOL
43 KiB
HTML
526 lines
No EOL
43 KiB
HTML
|
||
<!DOCTYPE html>
|
||
|
||
|
||
|
||
|
||
<html lang="en">
|
||
<head>
|
||
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||
|
||
<title>1.4. System Architectures — Computer Systems Fundamentals</title>
|
||
|
||
<link rel="stylesheet" href="_static/css/bootstrap.min.css" integrity="sha384-ggOyR0iXCbMQv3Xipma34MD+dH/1fQ784/j6cY/iJTQUOhcWr7x9JvoRxT2MZw1T" crossorigin="anonymous" />
|
||
<link rel="stylesheet" href="_static/css/pygments.css" type="text/css" />
|
||
<link rel="stylesheet" href="_static/css/normalize.css" type="text/css" />
|
||
<link rel="stylesheet" href="../../../JSAV/css/JSAV.css" type="text/css" />
|
||
<link rel="stylesheet" href="../../../lib/odsaMOD-min.css" type="text/css" />
|
||
<link rel="stylesheet" href="_static/css/jquery-1.11.4-smoothness-ui.css" type="text/css" />
|
||
<link rel="stylesheet" href="../../../lib/odsaStyle-min.css" type="text/css" />
|
||
<link rel="stylesheet" href="_static/css/csf.css" type="text/css" />
|
||
|
||
<style>
|
||
.underline { text-decoration: underline; }
|
||
</style>
|
||
|
||
<script type="text/javascript">
|
||
var DOCUMENTATION_OPTIONS = {
|
||
URL_ROOT: './',
|
||
VERSION: '0.4.1',
|
||
COLLAPSE_INDEX: false,
|
||
FILE_SUFFIX: '.html',
|
||
HAS_SOURCE: true
|
||
};
|
||
</script>
|
||
|
||
<script type="text/x-mathjax-config">
|
||
MathJax.Hub.Config({
|
||
tex2jax: {
|
||
inlineMath: [['$','$'], ['\\(','\\)']],
|
||
displayMath: [ ['$$','$$'], ["\\[","\\]"] ],
|
||
processEscapes: true
|
||
},
|
||
"HTML-CSS": {
|
||
scale: "80"
|
||
}
|
||
});
|
||
</script>
|
||
<link rel="shortcut icon" href="_static/favicon.ico"/>
|
||
<link rel="index" title="Index" href="genindex.html" />
|
||
<link rel="search" title="Search" href="search.html" />
|
||
<link rel="index" title="Computer Systems Fundamentals" href="index.html" />
|
||
<link rel="next" title="5. State Models in UML" href="StateModels.html" />
|
||
<link rel="prev" title="3. Themes and Guiding Principles" href="Themes.html" />
|
||
|
||
</head><body>
|
||
|
||
<nav class="navbar navbar-expand-md navbar-dark navbar-custom fixed-top">
|
||
|
||
<a class="navbar-brand py-0" href="index.html"><img src="_static/CSF-Logo-Square-Text.png" alt="OpenCSF Logo" height="40em" class="py-1 px-2 mb-0 align-center rounded-lg bg-white" /></a>
|
||
<!-- Show a navbar toggler on mobile -->
|
||
<button class="navbar-toggler" type="button" data-toggle="collapse" data-target="#defaultNavbars" aria-controls="defaultNavbars" aria-expanded="false" aria-label="Toggle navigation">
|
||
<span class="navbar-toggler-icon"></span>
|
||
</button>
|
||
<div class="collapse navbar-collapse" id="defaultNavbars">
|
||
<ul class="navbar-nav mr-auto">
|
||
<li class="nav-item dropdown">
|
||
<a class="nav-link dropdown-toggle jmu-gold rounded" href="Architectures.html#" id="navbarDropdownChapters" role="button" data-toggle="dropdown" aria-haspopup="true" aria-expanded="false">Contents</a>
|
||
<div class="dropdown-menu scrollable-menu" role="menu" aria-labelledby="navbarDropdownChapters">
|
||
<a class="dropdown-item" tabindex="-1" href="Architectures.html#"><b>Chapter 1</b></a>
|
||
<a class="dropdown-item" href="IntroConcSysOverview.html"> 1.1. Introduction to Concurrent Systems</a>
|
||
<a class="dropdown-item" href="SysAndModels.html"> 1.2. Systems and Models</a>
|
||
<a class="dropdown-item" href="Themes.html"> 1.3. Themes and Guiding Principles</a>
|
||
<a class="dropdown-item" href="Architectures.html"> 1.4. System Architectures</a>
|
||
<a class="dropdown-item" href="StateModels.html"> 1.5. State Models in UML</a>
|
||
<a class="dropdown-item" href="SequenceModels.html"> 1.6. Sequence Models in UML</a>
|
||
<a class="dropdown-item" href="StateModelImplementation.html"> 1.7. Extended Example: State Model Implementation</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 2</b></a>
|
||
<a class="dropdown-item" href="ProcessesOverview.html"> 2.1. Processes and OS Basics</a>
|
||
<a class="dropdown-item" href="Multiprogramming.html"> 2.2. Processes and Multiprogramming</a>
|
||
<a class="dropdown-item" href="KernelMechanics.html"> 2.3. Kernel Mechanics</a>
|
||
<a class="dropdown-item" href="Syscall.html"> 2.4. System Call Interface</a>
|
||
<a class="dropdown-item" href="ProcessCycle.html"> 2.5. Process Life Cycle</a>
|
||
<a class="dropdown-item" href="UnixFile.html"> 2.6. The UNIX File Abstraction</a>
|
||
<a class="dropdown-item" href="EventsSignals.html"> 2.7. Events and Signals</a>
|
||
<a class="dropdown-item" href="Extended2Processes.html"> 2.8. Extended Example: Listing Files with Processes</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 3</b></a>
|
||
<a class="dropdown-item" href="IPCOverview.html"> 3.1. Concurrency with IPC</a>
|
||
<a class="dropdown-item" href="IPCModels.html"> 3.2. IPC Models</a>
|
||
<a class="dropdown-item" href="Pipes.html"> 3.3. Pipes and FIFOs</a>
|
||
<a class="dropdown-item" href="MMap.html"> 3.4. Shared Memory With Memory-mapped Files</a>
|
||
<a class="dropdown-item" href="POSIXvSysV.html"> 3.5. POSIX vs. System V IPC</a>
|
||
<a class="dropdown-item" href="MQueues.html"> 3.6. Message Passing With Message Queues</a>
|
||
<a class="dropdown-item" href="ShMem.html"> 3.7. Shared Memory</a>
|
||
<a class="dropdown-item" href="IPCSems.html"> 3.8. Semaphores</a>
|
||
<a class="dropdown-item" href="Extended3Bash.html"> 3.9. Extended Example: Bash-lite: A Simple Command-line Shell</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 4</b></a>
|
||
<a class="dropdown-item" href="SocketsOverview.html"> 4.1. Networked Concurrency</a>
|
||
<a class="dropdown-item" href="FiveLayer.html"> 4.2. The TCP/IP Internet Model</a>
|
||
<a class="dropdown-item" href="NetApps.html"> 4.3. Network Applications and Protocols</a>
|
||
<a class="dropdown-item" href="Sockets.html"> 4.4. The Socket Interface</a>
|
||
<a class="dropdown-item" href="TCPSockets.html"> 4.5. TCP Socket Programming: HTTP</a>
|
||
<a class="dropdown-item" href="UDPSockets.html"> 4.6. UDP Socket Programming: DNS</a>
|
||
<a class="dropdown-item" href="AppBroadcast.html"> 4.7. Application-Layer Broadcasting: DHCP</a>
|
||
<a class="dropdown-item" href="Extended4CGI.html"> 4.8. Extended Example: CGI Web Server</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 5</b></a>
|
||
<a class="dropdown-item" href="InternetOverview.html"> 5.1. The Internet and Connectivity</a>
|
||
<a class="dropdown-item" href="AppLayer.html"> 5.2. Application Layer: Overlay Networks</a>
|
||
<a class="dropdown-item" href="TransLayer.html"> 5.3. Transport Layer</a>
|
||
<a class="dropdown-item" href="NetSec.html"> 5.4. Network Security Fundamentals</a>
|
||
<a class="dropdown-item" href="NetLayer.html"> 5.5. Network Layer: IP</a>
|
||
<a class="dropdown-item" href="LinkLayer.html"> 5.6. Link Layer</a>
|
||
<a class="dropdown-item" href="Wireless.html"> 5.7. Wireless Connectivity: Wi-Fi, Bluetooth, and Zigbee</a>
|
||
<a class="dropdown-item" href="Extended5DNS.html"> 5.8. Extended Example: DNS client</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 6</b></a>
|
||
<a class="dropdown-item" href="ThreadsOverview.html"> 6.1. Concurrency with Multithreading</a>
|
||
<a class="dropdown-item" href="ProcVThreads.html"> 6.2. Processes vs. Threads</a>
|
||
<a class="dropdown-item" href="RaceConditions.html"> 6.3. Race Conditions and Critical Sections</a>
|
||
<a class="dropdown-item" href="POSIXThreads.html"> 6.4. POSIX Thread Library</a>
|
||
<a class="dropdown-item" href="ThreadArgs.html"> 6.5. Thread Arguments and Return Values</a>
|
||
<a class="dropdown-item" href="ImplicitThreads.html"> 6.6. Implicit Threading and Language-based Threads</a>
|
||
<a class="dropdown-item" href="Extended6Input.html"> 6.7. Extended Example: Keyboard Input Listener</a>
|
||
<a class="dropdown-item" href="Extended6Primes.html"> 6.8. Extended Example: Concurrent Prime Number Search</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 7</b></a>
|
||
<a class="dropdown-item" href="SynchOverview.html"> 7.1. Synchronization Primitives</a>
|
||
<a class="dropdown-item" href="CritSect.html"> 7.2. Critical Sections and Peterson's Solution</a>
|
||
<a class="dropdown-item" href="Locks.html"> 7.3. Locks</a>
|
||
<a class="dropdown-item" href="Semaphores.html"> 7.4. Semaphores</a>
|
||
<a class="dropdown-item" href="Barriers.html"> 7.5. Barriers</a>
|
||
<a class="dropdown-item" href="Condvars.html"> 7.6. Condition Variables</a>
|
||
<a class="dropdown-item" href="Deadlock.html"> 7.7. Deadlock</a>
|
||
<a class="dropdown-item" href="Extended7Events.html"> 7.8. Extended Example: Event Log File</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 8</b></a>
|
||
<a class="dropdown-item" href="SynchProblemsOverview.html"> 8.1. Synchronization Patterns and Problems</a>
|
||
<a class="dropdown-item" href="SynchDesign.html"> 8.2. Basic Synchronization Design Patterns</a>
|
||
<a class="dropdown-item" href="ProdCons.html"> 8.3. Producer-Consumer Problem</a>
|
||
<a class="dropdown-item" href="ReadWrite.html"> 8.4. Readers-Writers Problem</a>
|
||
<a class="dropdown-item" href="DiningPhil.html"> 8.5. Dining Philosophers Problem and Deadlock</a>
|
||
<a class="dropdown-item" href="CigSmokers.html"> 8.6. Cigarette Smokers Problem and the Limits of Semaphores and Locks</a>
|
||
<a class="dropdown-item" href="Extended8ModExp.html"> 8.7. Extended Example: Parallel Modular Exponentiation</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Chapter 9</b></a>
|
||
<a class="dropdown-item" href="ParallelDistributedOverview.html"> 9.1. Parallel and Distributed Systems</a>
|
||
<a class="dropdown-item" href="ParVConc.html"> 9.2. Parallelism vs. Concurrency</a>
|
||
<a class="dropdown-item" href="ParallelDesign.html"> 9.3. Parallel Design Patterns</a>
|
||
<a class="dropdown-item" href="Scaling.html"> 9.4. Limits of Parallelism and Scaling</a>
|
||
<a class="dropdown-item" href="DistTiming.html"> 9.5. Timing in Distributed Environments</a>
|
||
<a class="dropdown-item" href="DistDataStorage.html"> 9.6. Reliable Data Storage and Location</a>
|
||
<a class="dropdown-item" href="DistConsensus.html"> 9.7. Consensus in Distributed Systems</a>
|
||
<a class="dropdown-item" href="Extended9Blockchain.html"> 9.8. Extended Example: Blockchain Proof-of-Work</a>
|
||
<div class="dropdown-divider"></div>
|
||
<a class="dropdown-item disabled"><b>Appendix A</b></a>
|
||
<a class="dropdown-item" href="CLangOverview.html"> A.1. C Language Reintroduction</a>
|
||
<a class="dropdown-item" href="Debugging.html"> A.2. Documentation and Debugging</a>
|
||
<a class="dropdown-item" href="BasicTypes.html"> A.3. Basic Types and Pointers</a>
|
||
<a class="dropdown-item" href="Arrays.html"> A.4. Arrays, Structs, Enums, and Type Definitions</a>
|
||
<a class="dropdown-item" href="Functions.html"> A.5. Functions and Scope</a>
|
||
<a class="dropdown-item" href="Pointers.html"> A.6. Pointers and Dynamic Allocation</a>
|
||
<a class="dropdown-item" href="Strings.html"> A.7. Strings</a>
|
||
<a class="dropdown-item" href="FunctionPointers.html"> A.8. Function Pointers</a>
|
||
<a class="dropdown-item" href="Files.html"> A.9. Files</a>
|
||
</div>
|
||
</li>
|
||
|
||
|
||
|
||
</ul>
|
||
</div>
|
||
|
||
<ul class="navbar-nav flex-row ml-md-auto d-none d-md-flex">
|
||
<li class="nav-item"><a class="nav-link jmu-gold" href="https://w3.cs.jmu.edu/kirkpams/OpenCSF/Books/csf/source/Architectures.rst"
|
||
target="_blank" rel="nofollow">Show Source</a></li>
|
||
|
||
</ul>
|
||
</nav>
|
||
|
||
|
||
<div class="container center">
|
||
«  <a id="prevmod" href="Themes.html">1.3. Themes and Guiding Principles</a>
|
||
  ::  
|
||
<a class="uplink" href="index.html">Contents</a>
|
||
  ::  
|
||
<a id="nextmod" href="StateModels.html">1.5. State Models in UML</a>  »
|
||
|
||
</div>
|
||
<br />
|
||
|
||
|
||
|
||
<script type="text/javascript" src="_static/js/jquery-2.1.4.min.js"></script>
|
||
<script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.1/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>
|
||
<script type="text/javascript" src="_static/js/jquery-1.11.4-ui.min.js"></script>
|
||
<script type="text/javascript" src="_static/js/forge-0.7.0.min.js"></script>
|
||
<script type="text/javascript" src="../../../JSAV/lib/jquery.transit.js"></script>
|
||
<script type="text/javascript" src="../../../JSAV/lib/raphael.js"></script>
|
||
<script type="text/javascript" src="../../../JSAV/build/JSAV-min.js"></script>
|
||
<script type="text/javascript" src="_static/js/config.js"></script>
|
||
<script type="text/javascript" src="../../../lib/odsaUtils-min.js"></script>
|
||
<script type="text/javascript" src="../../../lib/odsaMOD-min.js"></script>
|
||
<script type="text/javascript" src="_static/js/d3-4.13.0.min.js"></script>
|
||
<script type="text/javascript" src="_static/js/d3-selection-multi.v1.min.js"></script>
|
||
<script type="text/javascript" src="../../../lib/dataStructures.js"></script>
|
||
|
||
|
||
|
||
|
||
|
||
|
||
<div class="container">
|
||
|
||
<script>ODSA.SETTINGS.DISP_MOD_COMP = true;ODSA.SETTINGS.MODULE_NAME = "Architectures";ODSA.SETTINGS.MODULE_LONG_NAME = "System Architectures";ODSA.SETTINGS.MODULE_CHAPTER = "Introduction to Computer Systems"; ODSA.SETTINGS.BUILD_DATE = "2021-06-01 15:31:50"; ODSA.SETTINGS.BUILD_CMAP = false;JSAV_OPTIONS['lang']='en';JSAV_EXERCISE_OPTIONS['code']='java';</script><div class="section" id="system-architectures">
|
||
<h1>1.4. System Architectures<a class="headerlink" href="Architectures.html#system-architectures" title="Permalink to this headline">¶</a></h1>
|
||
<p>As stated previously, a model is a simplified representation of a system. Models are created to
|
||
illustrate particular features of the system, while omitting other details that are not relevant to
|
||
the current discussion. In other words, if we characterize a system implementation—with all details,
|
||
variables, and states set to have particular values—as exhibiting a low level of abstraction, a
|
||
model would possess a higher level. We can construct a model from an implementation by removing
|
||
details, or we can construct an implementation by adding details to a model. However, both the model
|
||
and the implementation are focused on a particular application. For instance, an automobile’s cruise
|
||
control system would be an implementation, created from a model that illustrates which components
|
||
determine the vehicle’s velocity, which entities calculate the changes to acceleration needed, and
|
||
which ones adjust the rotation of the wheels. Both the model and the implementation are focused on
|
||
the specific issue of acceleration in an automobile.</p>
|
||
<p>We can also approach the question of models from an even higher level of abstraction by examining
|
||
the system’s <a class="reference internal" href="Glossary.html#term-architectural-style"><span class="xref std std-term">architectural style</span></a>. The architectural style describes the relationship between
|
||
entities in the system and how those entities can communicate. Selecting a particular architecture
|
||
has significant overall impact on the system’s performance and design style. Each approach has its
|
||
advantages and disadvantages, and these must be considered for the intended use of the system.</p>
|
||
<div class="section" id="client-server-architectures">
|
||
<h2>1.4.1. Client/Server Architectures<a class="headerlink" href="Architectures.html#client-server-architectures" title="Permalink to this headline">¶</a></h2>
|
||
<div class="figure mb-2 align-right" id="id1" style="width: 30%">
|
||
<span id="archcliserv"></span><a class="reference internal image-reference" href="_images/CSF-Images.1.5.png"><img class="p-3 mb-2 align-center border border-dark rounded-lg" alt="Multiple clients connect to a single server" src="_images/CSF-Images.1.5.png" style="width: 90%;" /></a>
|
||
<p class="caption align-center px-3"><span class="caption-text"> Figure 1.4.1: Multiple clients connect to a single server</span></p>
|
||
</div>
|
||
<p><a href="Architectures.html#archcliserv">Figure 1.4.1</a> shows the logical structure of the
|
||
<a class="reference internal" href="Glossary.html#term-client-server-architecture"><span class="xref std std-term">client/server architecture</span></a>, a well-known and intuitive paradigm for building computer
|
||
systems. The developer creates a centralized server that receives requests for service and responds
|
||
accordingly. Web servers listen for requests created by a user’s web browser (the client) or an app
|
||
running on a smartphone or tablet. Email servers allow you to send a message to someone else using a
|
||
client application running within a web page or as part of a native email application. Network file
|
||
servers can store large amounts of data, such as a collection of movies and music files; a streaming
|
||
media client can then retrieve these files as indicated by the user.</p>
|
||
<p>When creating a client/server architecture, the first key question is to determine how the client
|
||
knows how to locate the server. The <a class="reference internal" href="Glossary.html#term-uniform-resource-identifier"><span class="xref std std-term">uniform resource identifier (URI)</span></a>
|
||
approach is the most common, relying on standard Internet services to fill in the details. For
|
||
instance, the URI <code class="docutils literal notranslate"><span class="pre">www.example.com/index.html</span></code> indicates that there is a file named <code class="docutils literal notranslate"><span class="pre">index.html</span></code>
|
||
that can be accessed from the <code class="docutils literal notranslate"><span class="pre">www.example.com</span></code> web server. This answer is not entirely
|
||
satisfying, because it leaves unanswered how you are supposed to know where to find
|
||
<code class="docutils literal notranslate"><span class="pre">www.example.com</span></code>; the answer is you use a DNS client to contact a DNS server as a preliminary
|
||
step toward using your web client to contact a web server. The main idea in this approach is that
|
||
there is a single entity (the server) that provides a service to clients upon request.</p>
|
||
<p>Client/server architectures are common in user-focused applications, but they are also widely used
|
||
in systems that do not provide visible services. As an example, several components of operating
|
||
systems (OS) are designed according to a client/server architecture. For instance, the graphical
|
||
user interface (GUI) is typically structured as a server that displays information in windows,
|
||
manages the desktop, and directs keyboard or mouse input correctly; each application that is running
|
||
acts as a client, sending requests to the GUI to update the visual display. Components that provide
|
||
information about what applications are running, what the current time is, or whether a login
|
||
request is allowed are all structured as servers. That is, anything that is typically described as
|
||
an OS <em>service</em> exhibits a client/server architecture.</p>
|
||
<p>One advantage of the client/server architecture is the simplicity of handling updates. If a file is
|
||
renamed, its contents modified, or changed in any other way, this change only needs to occur once.
|
||
After the file or resource is updated on the server, the new version can be made immediately
|
||
available. Relatedly, the centralized structure makes it easy to detect security breaches or data
|
||
corruptions. If a user reports a broken link or some other bad result, the problem only needs to be fixed in one location.</p>
|
||
<p>From a communication perspective, client/server architectures rely on communication
|
||
<a class="reference internal" href="Glossary.html#term-protocol"><span class="xref std std-term">protocols</span></a>, standards that specify precisely how to request a service and
|
||
interpret the response. Protocols are necessary, because there are no pre-defined assumptions
|
||
regarding who can be a client. Returning to the previous examples from above, a web server defaults
|
||
to responding to requests from any web browser connected to the Internet. The email server that you
|
||
are using will accept incoming messages from anyone, including a long-lost friend attempting to
|
||
reconnect or a criminal enterprise sending you spam with a virus attached. So long as the client and
|
||
server adhere to the communication protocol, messages can be delivered to and from the server.
|
||
Granted, after the server receives the message, it may use a spam filter or other security mechanism
|
||
to discard it without your knowledge; however, the message was still delivered to the server itself.</p>
|
||
<p>Client/server architectures have a key feature that is both an advantage and disadvantage:
|
||
centralization. Maintaining a single server makes it easy to process changes efficiently and provide
|
||
consistent service. The downside of this is that the system has a <em>single point of failure</em>.
|
||
If the web server crashes, then the entire service is down. The single access point also creates a
|
||
<em>bottleneck</em> when many clients try to request service at the same time. As an analogy, imagine
|
||
going to a restaurant that only has one table. That is not a problem for most of the day when there
|
||
are few (if any) customers arriving; however, the restaurant would quickly go out of business since
|
||
it could not serve enough customers during the busy (and profitable) meal-time rushes. One way for
|
||
client/server architectures to solve this problem is to use <a class="reference internal" href="Glossary.html#term-343"><span class="xref std std-term">replication</span></a>. Instead of using
|
||
only one server, a few servers coordinate the work very closely, providing backup to each other.
|
||
This would be analogous to adding more tables to the restaurant.</p>
|
||
</div>
|
||
<div class="section" id="peer-to-peer-p2p-architectures">
|
||
<h2>1.4.2. Peer-to-peer (P2P) Architectures<a class="headerlink" href="Architectures.html#peer-to-peer-p2p-architectures" title="Permalink to this headline">¶</a></h2>
|
||
<p>This idea of replication can be extended even further to the notion of
|
||
<a class="reference internal" href="Glossary.html#term-peer-to-peer-architecture"><span class="xref std std-term">peer-to-peer (P2P) architectures</span></a>. <a href="Architectures.html#archp2p">Figure 1.4.2</a>
|
||
illustrates the logical structure of a P2P architecture. P2P architectures retain many of the key
|
||
features of traditional client/server architectures, with the exception that every (or most)
|
||
participating entities take turns acting as both clients and servers. Any node in the architecture
|
||
can communicate with any other, requesting or providing service as needed.</p>
|
||
<div class="figure mb-2 align-right" id="id2" style="width: 30%">
|
||
<span id="archp2p"></span><a class="reference internal image-reference" href="_images/CSF-Images.1.6.png"><img class="p-3 mb-2 align-center border border-dark rounded-lg" alt="All P2P nodes are clients and servers" src="_images/CSF-Images.1.6.png" style="width: 90%;" /></a>
|
||
<p class="caption align-center px-3"><span class="caption-text"> Figure 1.4.2: All P2P nodes are clients and servers</span></p>
|
||
</div>
|
||
<p>For many readers, P2P architectures are probably associated with file-sharing services, such as
|
||
BitTorrent. In that service, you may use your client to download a file provided by another user; in
|
||
return, while you are connected to the network, other users can also download that same file (or
|
||
pieces of it) from your client. P2P architectures go beyond just this single application, though.
|
||
Another common example of a P2P architecture is DNS, the service that translates human-readable
|
||
domain names (<code class="docutils literal notranslate"><span class="pre">www.example.com</span></code>) into a numeric IP address. (We will cover many of the details of
|
||
DNS in Chapter 4.) Although your web browser interacts with DNS in a traditional client/server
|
||
approach, DNS itself consists of a world-wide P2P network of systems that exchange information to
|
||
support these translations.</p>
|
||
<p>Overall, P2P architectures extend the client/server paradigm with the benefit that they
|
||
<a class="reference internal" href="Glossary.html#term-scale"><span class="xref std std-term">scale</span></a> well by maintaining good (or even better) service as the number of users increases.
|
||
For instance, in a system like DNS with P2P nodes distributed world-wide, your request can be routed
|
||
to the server that is physically closest to you. Consequently, your request would be handled more
|
||
efficiently than if the message had to be transmitted to the other side of the world.</p>
|
||
<p>The tradeoff for these scaling benefits is more difficulty in both administration and security. For
|
||
instance, if one of the nodes is corrupted so that it serves spam or other malware, system
|
||
administrators may struggle to identify which particular node is causing the problem. Another
|
||
problem that arises from this tradeoff is that updates are not guaranteed to be immediately
|
||
accessible. When a file is updated on one node, that change needs to be communicated to all of the
|
||
other nodes, which takes time. While this change is propagating, that file may be designated as not
|
||
available or only the old version can be accessed. The choice between traditional client/server and
|
||
P2P architectures must account for all of these factors.</p>
|
||
</div>
|
||
<div class="section" id="layered-architectures">
|
||
<h2>1.4.3. Layered Architectures<a class="headerlink" href="Architectures.html#layered-architectures" title="Permalink to this headline">¶</a></h2>
|
||
<div class="figure mb-2 align-right" id="id3" style="width: 35%">
|
||
<span id="archlayer"></span><a class="reference internal image-reference" href="_images/CSF-Images.1.7.png"><img class="p-3 mb-2 align-center border border-dark rounded-lg" alt="Common layers for an information system application" src="_images/CSF-Images.1.7.png" style="width: 90%;" /></a>
|
||
<p class="caption align-center px-3"><span class="caption-text"> Figure 1.4.3: Common layers for an information system application</span></p>
|
||
</div>
|
||
<p>In a <a class="reference internal" href="Glossary.html#term-layered-architecture"><span class="xref std std-term">layered architecture</span></a>, the system structure is arranged in a hierarchical order of
|
||
modular components. <a href="Architectures.html#archlayer">Figure 1.4.3</a> shows a common layered architecture that is used
|
||
in building information systems. In this design, the user interacts with the Presentation Layer,
|
||
which is responsible for the user interface and other graphical components. This layer can interact
|
||
only with a Business Layer that encodes domain-specific business logic, such as adding new employees
|
||
to a human resources database. The Business Layer may interact with a Services Layer that defines
|
||
common processes that are used for a variety of application. User authentication and security
|
||
mechanisms would commonly be implemented as such a service. At the bottom level, the Persistence
|
||
Layer contains the database and other mechanisms for storing data.</p>
|
||
<p>Client/server and P2P architectures support bidirectional communication between any entity that
|
||
adheres to the specified protocol. In contrast, a layered architecture imposes a strict ordering to
|
||
the allowable communication. Each layer is designed to interact only with the layer immediately
|
||
above and the layer immediately below. For instance, in <a href="Architectures.html#archlayer">Figure 1.4.3</a>, the
|
||
Presentation Layer should never interact directly with the Services or Persistence Layers. Instead,
|
||
all data that the Presentation Layer receives for long-term storage would need to be passed to the
|
||
Business Layer, which would forward the requests on to the lower layers.</p>
|
||
<p>One significant advantage of the layered architecture approach is that the layers can be
|
||
independently modified and replaced with new components. Switching the Persistence Layer to use a
|
||
different kind of database would not affect any of the other layers, assuming the interfaces are
|
||
preserved and the layers are cleanly defined. Furthermore, new layers could be added as the
|
||
application evolves, allowing for an extensible and modular approach.</p>
|
||
<p>On the other hand, the layers of many systems are hard to delineate cleanly in a single hierarchical
|
||
ordering. Some systems have circular dependencies that cannot be easily resolved, while others have
|
||
layers that are not truly independent. For instance, consider the relationship between a file system
|
||
and the physical storage device driver in an OS. In theory, file systems could break files into
|
||
pieces of any size; in practice, all file systems structure data in chunks that are multiples of 512
|
||
B, because that is the standard size imposed by the cables used with hard drives. Consequently, it
|
||
does not seem efficient to ignore this reality when defining the file system layer. Similarly, there
|
||
may be good reason to allow messages to bypass layers. For instance, the Business Layer may need to
|
||
store a significant amount of temporary data until an approval (implemented in the Services Layer)
|
||
is granted; thus, the system could benefit from granting the Business Layer direct access to the
|
||
Persistence Layer.</p>
|
||
<p>A related problem with layered architectures is that there tends to be unnecessary redundancy and
|
||
inefficient mechanisms. As an example of the former, consider the layers of the Internet protocol
|
||
stack, which we will discuss in Chapter 5. The layers of this stack use the terms <a class="reference internal" href="Glossary.html#term-segment"><span class="xref std std-term">segment</span></a>,
|
||
<a class="reference internal" href="Glossary.html#term-packet"><span class="xref std std-term">packet</span></a>, <a class="reference internal" href="Glossary.html#term-datagram"><span class="xref std std-term">datagram</span></a>, and <a class="reference internal" href="Glossary.html#term-frame"><span class="xref std std-term">frame</span></a> to refer to a structured message that contains a header and a
|
||
piece of data. Granted, there are subtle nuances between some of them, but the concept is very
|
||
similar. Additionally, all of these layers include error checking mechanisms to ensure that none of
|
||
the bits of the message have been corrupted; when a message arrives, multiple layers all perform the
|
||
same calculation to check the message’s validity.</p>
|
||
</div>
|
||
<div class="section" id="pipe-and-filter-architectures">
|
||
<h2>1.4.4. Pipe-and-filter Architectures<a class="headerlink" href="Architectures.html#pipe-and-filter-architectures" title="Permalink to this headline">¶</a></h2>
|
||
<p>In contrast to the previous architectures, <a class="reference internal" href="Glossary.html#term-pipe-and-filter-architecture"><span class="xref std std-term">pipe-and-filter architectures</span></a>
|
||
impose a unidirectional ordering on communication between system components. The data processing
|
||
begins at the <em>source</em> of the input and proceeds through a series of stages. The output of
|
||
each stage becomes the input of the next, with the intention that each stage transforms the data in
|
||
some way. The final result is referred to as the <em>sink</em>, which denotes the output. Readers who
|
||
have some familiarity with working on the UNIX or Linux command line are likely to have encountered
|
||
a pipe-and-filter architecture, created by the following sample command line:</p>
|
||
<div class="highlight-none border border-dark rounded-lg bg-light px-2 mb-3 notranslate"><div class="highlight bg-light"><pre class="mb-0"><span></span>$ sort foo.txt | grep -i error | head -n 10 > out.txt
|
||
</pre></div>
|
||
</div>
|
||
<p>In this sequence of commands, the contents of the file foo.txt are sorted and sent to the grep
|
||
utility, which performs text matching (finding “error” in a case insensitive manner). The lines that
|
||
contain “error” are then sent to the head command that grabs only the first 10 lines of output,
|
||
writing the results in a new file called <code class="docutils literal notranslate"><span class="pre">out.txt</span></code>. <a href="Architectures.html#archpipefilter">Figure 1.4.4</a>
|
||
illustrates this sequence as a pipe-and-filter architecture.</p>
|
||
<div class="figure mb-2 align-center" id="id4">
|
||
<span id="archpipefilter"></span><a class="reference internal image-reference" href="_images/CSF-Images.1.8.png"><img class="p-3 mb-2 align-center border border-dark rounded-lg" alt="The pipe-and-filter system constructed from chaining command-line utilities" src="_images/CSF-Images.1.8.png" style="width: 70%;" /></a>
|
||
<p class="caption align-center px-3"><span class="caption-text"> Figure 1.4.4: The pipe-and-filter system constructed from chaining command-line utilities</span></p>
|
||
</div>
|
||
<p>In this example, the system was constructed dynamically by linking these command-line utilities
|
||
together. That is one way for creating a pipe-and-filter architecture. If there are several
|
||
independent modules that share a common interface (a stream of bytes as input and output), then a
|
||
pipe-and-filter system can be constructed from any composition of these components. Other
|
||
pipe-and-filter systems are not dynamic, and the sequence of stages cannot be re-ordered.</p>
|
||
<p>One example of such a pipe-and-filter system is a programming language compiler. The source code is
|
||
passed through a lexical analysis stage to recognize keywords (e.g., “if” and “while”) and other
|
||
language components. These tokens are passed to syntax analysis to check for errors, such as
|
||
forgotten semicolons or other invalid code. Next, the semantic analysis stage checks for type
|
||
mismatches (e.g., initializing an <code class="docutils literal notranslate"><span class="pre">int</span></code> variable with <code class="docutils literal notranslate"><span class="pre">"foo"</span></code>). These stages, which make up the
|
||
<em>front end</em> of the compiler, lead to the generation of intermediate representation. The processing
|
||
continues with additional stages to optimize the code and generate the machine-language executable.</p>
|
||
<p>One significant disadvantage of a pipe-and-filter architecture is the unidirectional structure does
|
||
not allow for error recovery. For instance, if you chain together 10 command-line utilities and the
|
||
third one wipes out all of the data being processed, the later stages cannot recover the eliminated
|
||
data. Furthermore, it may not be immediately evident which stage was the cause of the lost data.
|
||
Despite this drawback, however, pipe-and-filter architectures are very good for serial data processing.</p>
|
||
</div>
|
||
<div class="section" id="event-driven-architectures">
|
||
<h2>1.4.5. Event-driven Architectures<a class="headerlink" href="Architectures.html#event-driven-architectures" title="Permalink to this headline">¶</a></h2>
|
||
<p>The last major style that we will consider here is the <a class="reference internal" href="Glossary.html#term-event-driven-architecture"><span class="xref std std-term">event-driven architecture</span></a>. An
|
||
<a class="reference internal" href="Glossary.html#term-event"><span class="xref std std-term">event</span></a> refers to a meaningful change in the state of the system. For instance, in a GUI,
|
||
keyboard presses and mouse clicks are instances of events. When either of these occur, the user is
|
||
indicating a desire for the system to respond to this request in some way. <a href="Architectures.html#archevent">Figure 1.4.5</a> illustrates the logical structure of an event-driven system. An <em>event generator</em>
|
||
is any input device that can trigger the creation of an event. A keyboard and mouse are event
|
||
generators in a GUI; the server that a mobile app uses to connect to other users would also be an
|
||
event generator. The events are sent through an <em>event channel</em>, such as an HTTP connection or
|
||
a wire, where they are received by an <em>event processing</em> component. This component detects the
|
||
type of event that was triggered and invokes the corresponding <em>event handler</em> to respond accordingly.</p>
|
||
<div class="figure mb-2 align-center" id="id5">
|
||
<span id="archevent"></span><a class="reference internal image-reference" href="_images/CSF-Images.1.9.png"><img class="p-3 mb-2 align-center border border-dark rounded-lg" alt="The logical structure of an event-driven architecture" src="_images/CSF-Images.1.9.png" style="width: 70%;" /></a>
|
||
<p class="caption align-center px-3"><span class="caption-text"> Figure 1.4.5: The logical structure of an event-driven architecture</span></p>
|
||
</div>
|
||
<p>Event-driven architectures are effective designs for <a class="reference internal" href="Glossary.html#term-reactive"><span class="xref std std-term">reactive</span></a> systems. By differentiating
|
||
the event channel, event processing, and event handlers as distinct components, this approach
|
||
creates a robust and extensible framework. To support a new type of event, the developer creates the
|
||
event handler and makes the event processing layer aware of it. Similarly, the channel can be
|
||
modified and upgraded without affecting the event handler operations.</p>
|
||
<p>One drawback of the event-driven architecture is how it complicates the timing of access to shared
|
||
resources. Some event handlers are designed to have higher priority than others, and some event
|
||
handlers may take a while to complete. Consequently, if a low-priority event handler is currently
|
||
using a shared resource when a high-priority event arrives, the correct response is not immediately
|
||
clear. The low-priority handler may need to finish its work to keep the system in a stable,
|
||
consistent state because it has made some changes that cannot be undone. However, the high-priority
|
||
handler is, by definition, supposed to run first. As such, correct handling of events can be complicated.</p>
|
||
</div>
|
||
<div class="section" id="hybrid-architectures">
|
||
<h2>1.4.6. Hybrid Architectures<a class="headerlink" href="Architectures.html#hybrid-architectures" title="Permalink to this headline">¶</a></h2>
|
||
<p>In practice, computer systems rarely fit into exactly one architectural style. Many systems are best
|
||
described as hybrid architectures that can be viewed from different perspectives depending on the
|
||
context. This hybrid structure is particularly common when systems are composed of subsystems that
|
||
operate independently. Some subsystems are more naturally aligned with one architecture than
|
||
another, implying that there is no single architecture for the whole system.</p>
|
||
<p>One example of this is an OS kernel, which is the central system that provides applications with
|
||
managed access to the hardware. From one perspective, the kernel is an event-driven architecture, as
|
||
it consists of a collection of <em>interrupt handlers</em> that respond to
|
||
signals (interrupts) from the hardware that something meaningful has occurred. Those events can
|
||
include plugging in a USB drive, receiving data from a network card, detecting keyboard presses,
|
||
being alerted to low battery power, and so on. From a different perspective, the kernel is also a
|
||
client/server architecture. Applications that are running use the <a class="reference internal" href="Glossary.html#term-system-call"><span class="xref std std-term">system call interface</span></a>
|
||
to request access to a shared resource. These requests include sending and receiving pieces of data
|
||
across the network, opening and closing files, sending audio data to the speakers, and so on.
|
||
Furthermore, some aspects of the kernel are designed as layered architectures. File systems, for
|
||
example, are often structured in layers that convert generic file operations (reading, writing) into
|
||
operations that are specific to the particular organization of a specific device; that is, the
|
||
device may use file systems such as FAT32, HFS+, ext4, or NTFS, and the kernel maps the generic
|
||
operations as needed. Thus, there are systems, such as OS kernels, that can exhibit the features of
|
||
more than one architecture based on which aspect of the system is being considered.</p>
|
||
<div
|
||
id="ArchitectureSumm"
|
||
class="embedContainer"
|
||
data-exer-name="ArchitectureSumm"
|
||
data-long-name="System architectures questions"
|
||
data-short-name="ArchitectureSumm"
|
||
data-frame-src="../../../Exercises/IntroConcSys/ArchitectureSumm.html?selfLoggingEnabled=false&localMode=true&module=Architectures&JXOP-debug=true&JOP-lang=en&JXOP-code=java"
|
||
data-frame-width="950"
|
||
data-frame-height="550"
|
||
data-external="false"
|
||
data-points="1.0"
|
||
data-required="True"
|
||
data-showhide="show"
|
||
data-threshold="5"
|
||
data-type="ka"
|
||
data-exer-id="">
|
||
|
||
<div class="center">
|
||
<div id="ArchitectureSumm_iframe"></div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
|
||
|
||
</div>
|
||
|
||
|
||
|
||
<div class="container">
|
||
|
||
<div class="mt-4 container center">
|
||
«  <a id="prevmod1" href="Themes.html">1.3. Themes and Guiding Principles</a>
|
||
  ::  
|
||
<a class="uplink" href="index.html">Contents</a>
|
||
  ::  
|
||
<a id="nextmod1" href="StateModels.html">1.5. State Models in UML</a>  »
|
||
</div>
|
||
|
||
|
||
</div>
|
||
|
||
<br />
|
||
|
||
<div class="row jmu-dark-purple-bg">
|
||
<div class="col-md-12">
|
||
<center>
|
||
<a id="contact_us" class="btn button-link-no-blue jmu-gold" rel="nofollow" href="mailto:webmaster@opencsf.org" role="button">Contact Us</a>
|
||
<a id="license" class="btn button-link-no-blue jmu-gold" rel="nofollow" href="https://w3.cs.jmu.edu/kirkpams/OpenCSF/lib/license.html" target="_blank">License</a>
|
||
</center>
|
||
</div>
|
||
</div>
|
||
|
||
|
||
|
||
|
||
|
||
|
||
<script src="_static/js/popper.js-1.14.7-min.js" integrity="sha384-UO2eT0CpHqdSJQ6hJty5KVphtPhzWj9WO1clHTMGa3JDZwrnQq4sF86dIHNDz0W1" crossorigin="anonymous"></script>
|
||
<script src="_static/js/bootstrap.min.js" integrity="sha384-JjSmVgyd0p3pXB1rRibZUAYoIIy6OrQ6VrjIEaFf/nJGzIxFDsf4x0xIM+B07jRM" crossorigin="anonymous"></script>
|
||
</body>
|
||
</html> |