1. Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved.
Applied
Architectures

2. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
2
Objectives
 Illustrate how principles have been used to solve
challenging problems
Usually means combining elements
 Highlight some critical issues
I.e., ignore them at your peril
 Show how architecture can be used to explain and
analyze common commercial systems

3. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
3
Outline
 Distributed and networked architectures
Limitations
REST
Commercial Internet-scale applications
 Decentralized applications
Peer-to-peer
Web services
 Some interesting domains
Robotics
Wireless sensors
Flight simulators

4. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
4
Limitations of the Distributed Systems
Viewpoint
 The network is reliable
 Latency is zero
 Bandwidth is infinite
 The network is secure
 Topology doesn’t change
 There is one administrator
 Transport cost is zero
 The network is homogeneous
-- Deutsch & Gosling

5. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
5
Architecture in Action: WWW
 (From lecture #1) This is the Web
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

6. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
6
Architecture in Action: WWW
(cont’d)
 So is this
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

7. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
7
Architecture in Action: WWW
 And this
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

8. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
8
WWW’s Architecture
 The application is distributed (actually,
decentralized) hypermedia
 Architecture of the Web is wholly separate from the code
 There is no single piece of code that implements the
architecture.
 There are multiple pieces of code that implement the various
components of the architecture.
E.g., different Web browsers
 Stylistic constraints of the Web’s architectural style are not
apparent in the code
The effects of the constraints are evident in the Web
 One of the world’s most successful applications is only
understood adequately from an architectural vantage point.

9. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
9
REST Principles
 [RP1] The key abstraction of information is a resource,
named by an URL. Any information that can be named
can be a resource.
 [RP2] The representation of a resource is a sequence of
bytes, plus representation metadata to describe those
bytes. The particular form of the representation can be
negotiated between REST components.
 [RP3] All interactions are context-free: each interaction
contains all of the information necessary to understand
the request, independent of any requests that may have
preceded it.

10. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
10
REST Principles (cont’d)
 [RP4] Components perform only a small set of well-
defined methods on a resource producing a
representation to capture the current or intended state of
that resource and transfer that representation between
components. These methods are global to the specific
architectural instantiation of REST; for instance, all
resources exposed via HTTP are expected to support
each operation identically.

11. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
11
REST Principles (cont’d)
 [RP5] Idempotent operations and representation
metadata are encouraged in support of caching and
representation reuse.
 [RP6] The presence of intermediaries is promoted.
Filtering or redirection intermediaries may also use both
the metadata and the representations within requests or
responses to augment, restrict, or modify requests and
responses in a manner that is transparent to both the
user agent and the origin server.

12. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
12
An Instance of REST
$ $Client+Cache:Client Connector: Server Connector: Server+Cache:
$ $
Origin Servers
User Agent
$$
DNS
$DNS
Proxy
Proxy Gateway
wais
http
orb
http
http
http http
a
b
c

13. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
13
REST — Data Elements
 Resource
Key information abstraction
 Resource ID
 Representation
Data plus metadata
 Representation metadata
 Resource metadata
 Control data
e.g., specifies action as result of message

14. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
14
REST — Connectors
 Modern Web Examples
 client libwww, libwww-perl
 server libwww, Apache API, NSAPI
 cache browser cache, Akamai cache network
 resolver bind (DNS lookup library)
 tunnel SOCKS, SSL after HTTP CONNECT

15. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
15
REST — Components
 User agent
e.g., browser
 Origin server
e.g., Apache Server, Microsoft IIS
 Proxy
Selected by client
 Gateway
Squid, CGI, Reverse proxy
Controlled by server

16. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
16
An Instance of REST Revisited
$ $Client+Cache:Client Connector: Server Connector: Server+Cache:
$ $
Origin Servers
User Agent
$$
DNS
$DNS
Proxy
Proxy Gateway
wais
http
orb
http
http
http http
a
b
c

17. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
17
Derivation of REST
Key choices in this derivation include:
 Layered Separation (a theme in the middle portion of
diagram) is used to increase efficiencies, enable
independent evolution of elements of the system, and
provide robustness;
 Replication (left side of the diagram) is used to address
latency and contention by allowing the reuse of
information;
 Limited commonality (right side) addresses the
competing needs for universally understood operations
with extensibility.
The derivation is driven by the application(!)

18. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
18
Derivation of REST (cont’d)
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

19. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
19
REST: Final Thoughts
 REpresentational State Transfer
 Style of modern web architecture
Web architecture one of many in style
 Web diverges from style on occasion
e.g., Cookies, frames
Doesn’t explain mashups

20. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
20
Commercial Internet-Scale
Applications
 Akamai
Caching to the max
 Google
Google distributed file system (GFS)
MapReduce
Data selection and reduction
All parallelization done automatically

21. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
21
Architectural Lessons from Google
 Abstraction layers abound: GFS hides details of
data distribution and failure, for instance; MapReduce
hides the intricacies of parallelizing operations;
 By designing, from the outset, for living with failure of
processing, storage, and network elements, a highly
robust system can be created;
 Scale is everything: Google’s business demands
that everything be built with scaling issues in mind;

22. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
22
Architectural Lessons from Google
(cont’d)
 By specializing the design to the problem
domain, rather than taking the generic “industry
standard” approach, high performance and very cost-
effective solutions can be developed;
 By developing a general approach (MapReduce) to
the data extraction/reduction problem, a highly reusable
service was created.

23. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
23
Decentralized Architectures
 Networked applications where there are multiple
authorities
 In other words
Computation is distributed
Parts of the network may behave differently, and vary
over time
It’s just like collaboration in the real
world

24. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
24
Grid Protocol Architecture
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
 Coordinated resource sharing in a
distributed environment
E.g., Folding-at-home
 GLOBUS
A commonly used infrastructure
 “Standard architecture”
Fabric manages low-level
resources
Connectivity: communication and
authentication
Resource: sharing of a single r.
Collective: coordinating r. usage

25. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
25
Grid GLOBUS (Recovered)
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

26. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
26
Peer-to-Peer Architectures
 Decentralized resource sharing and discovery
Napster
Gnutella
 P2P that works: Skype
And BitTorrent

27. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
27
Peer-to-Peer Style
 State and behavior are distributed among peers
which can act as either clients or servers.
 Peers: independent components, having their own
state and control thread.
 Connectors: Network protocols, often custom.
 Data Elements: Network messages
 Topology: Network (may have redundant connections
between peers); can vary arbitrarily and dynamically
 Supports decentralized computing with flow of control
and resources distributed among peers. Highly
robust in the face of failure of any given node.
Scalable in terms of access to resources and
computing power. But caution on the protocol!

28. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
28
Peer-to-Peer LL
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

29. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
29
Napster (“I am the Napster!”)
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
--Lyle, “The Italian Job” (2003)

30. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
30
Gnutella (original)
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

31. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
31
Skype
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

32. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
32
Insights from Skype
 A mixed client-server and peer-to-peer architecture addresses
the discovery problem.
 Replication and distribution of the directories, in the form of
supernodes, addresses the scalability problem and
robustness problem encountered in Napster.
 Promotion of ordinary peers to supernodes based upon
network and processing capabilities addresses another
aspect of system performance: “not just any peer” is relied
upon for important services.
 A proprietary protocol employing encryption provides privacy
for calls that are relayed through supernode intermediaries.
 Restriction of participants to clients issued by Skype, and
making those clients highly resistant to inspection or
modification, prevents malicious clients from entering the
network.

33. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
33
Web Services
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

34. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
34
Web Services (cont’d)
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

35. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
35
Mobile Robotics
 Manned or partially manned vehicles
 Uses
Space exploration
Hazardous waste disposal
Underwater exploration
 Issues
Interface with external sensors & actuators
Real-time response to stimuli
Response to obstacles
Sensor input fidelity
Power failures
Mechanical limitations
Unpredictable events

36. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
36
Robotics: Sense-Plan-Act
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

37. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
37
Robotics Subsumption
Architecture
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

38. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
38
Robotics: Three-Layer
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

39. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
39
Wireless Sensor Networks
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

40. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
Flight Simulators
40
 Extremely complex systems
 http://www.gillesvidal.com/blogpano/cockpit1.htm

41. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
41
Flight Simulators: Key
Characteristics
 Real-time performance constraints
Extremely high fidelity demands
Requires distributed computing
Must execute at high fixed frame rates
 Often called harmonic frequencies
 e.g. often 60Hz, 30Hz; some higher (100Hz)
Coordination across simulator components
All portions of simulator run at integral multiple of base
rate
 e.g. if base rate = 60Hz, then 30Hz, 15Hz, 12Hz, etc.
Every task must complete on time
 Delays can cause simulator sickness

42. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
42
Flight Simulators: Key
Characteristics (cont’d)
 Continuous evolution
 Very large & complex
Millions of SLOC
Exponential growth over lifetime of simulator
 Distributed development
Portions of work sub­contracted to specialists
Long communication paths increase integration complexity
 Expensive verification & validation
Direct by-product of above characteristics
 Mapping of Simulation SW to HW components unclear
Efficiency muddies abstraction
Needed because of historical HW limitations

43. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
43
Simulation
Models
Air
Vehicle
Cockpit
Displays Cockpit
Controls
Environment
Crew
Instructor/
Operator
Station
Visual
Cueing
System
Motion
Cueing
System
Audio
Cueing
System
Functional Model

44. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
44
How Is the Complexity Managed?
 New style
“Structural Modeling”
Based on
Object–oriented design to model air vehicle’s
 Sub-systems
 Components
Real-time scheduling to control execution order
 Goals of Style
Maintainability
Integrability
Scalability

45. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
45
How Is the Complexity Managed?
(cont’d)
 Style principles
Pre-defined partitioning of functionality among SW
elements
Restricted data- & control-flow
Data-flow through export areas only
 Decoupling objects
Small number of element types
Results in replicated subsystems

46. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
46
How Is the Complexity Managed?
(cont’d)
 Style principles (continued)
Objects fully encapsulate their own internal state
No side-effects of computations
Narrow set of system-wide coordination strategies
Employs pre-defined mechanisms for data &
control passing
Enable component communication &
synchronization

47. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
47
F-Sim In The Structural Modeling
Style
 Five basic computational elements in two classes
Executive (or infrastructure)
Periodic sequencer
Event handler
Synchronizer
Application
Components
Subsystems
 Each of the five has
Small API
Encapsulated state
Severely limited external data upon which it relies

48. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
48
Level–0 Architecture

49. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
49
Level–1 Architecture

50. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture
50
Takeaways
 A great architecture is the ticket to runaway success
 A great architecture reflects deep understanding of the
problem domain
 A great architecture probably combines aspects of
several simpler architectures
 Develop a new architectural style with great care and
caution. Most likely you don’t need a new style.