cs 1023 lec 13 web (week 4)

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

AppliedArchitectures

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

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

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

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

Architecture in Action: WWW (cont’d) So is this



7

Architecture in Action: WWW

And this



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

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

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

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

An Instance of REST

$ $Client+Cache:Client Connector: Server Connector: Server+Cache:

$ $

Origin Servers

User Agent

$$

DNS

$DNS

Proxy

Proxy Gateway

wais

http

orbhttp

http

http http

a

b

c


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

REST — Connectors

Modern Web Examples client libwww, libwww-perl server libwww, Apache API, NSAPI cachebrowser cache, Akamai cache network resolver bind (DNS lookup library) tunnel SOCKS, SSL after HTTP CONNECT


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

An Instance of REST Revisited

$ $Client+Cache:Client Connector: Server Connector: Server+Cache:

$ $

Origin Servers

User Agent

$$

DNS

$DNS

Proxy

Proxy Gateway

wais

http

orbhttp

http

http http

a

b

c


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

Derivation of REST (cont’d)



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

Commercial Internet-Scale Applications Akamai

Caching to the max Google

Google distributed file system (GFS) MapReduce

Data selection and reductionAll parallelization done automatically


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

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

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

Grid Protocol Architecture


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

Grid GLOBUS (Recovered)



26

Peer-to-Peer Architectures

Decentralized resource sharing and discovery Napster Gnutella

P2P that works: Skype And BitTorrent


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

Peer-to-Peer LL



29

Napster (“I am the Napster!”)


--Lyle, “The Italian Job” (2003)


30

Gnutella (original)



31

Skype



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

Web Services



34

Web Services (cont’d)



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

Robotics: Sense-Plan-Act



37

Robotics Subsumption Architecture



38

Robotics: Three-Layer



39

Wireless Sensor Networks



Flight Simulators

40

Extremely complex systems

http://www.gillesvidal.com/blogpano/cockpit1.htm


41

Flight Simulators: Key Characteristics Real-time performance constraints

Extremely high fidelity demandsRequires distributed computingMust execute at high fixed frame rates

Often called harmonic frequencies e.g. often 60Hz, 30Hz; some higher (100Hz)

Coordination across simulator componentsAll 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

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

SimulationModels

AirVehicle

CockpitDisplays Cockpit

Controls

Environment

Crew

Instructor/OperatorStation

VisualCueingSystem

MotionCueingSystem

AudioCueingSystem

Functional Model


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

How Is the Complexity Managed? (cont’d) Style principles

Pre-defined partitioning of functionality among SW elements

Restricted data- & control-flowData-flow through export areas only

Decoupling objects Small number of element types

Results in replicated subsystems


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

strategiesEmploys pre-defined mechanisms for data &

control passingEnable component communication &

synchronization


47

F-Sim In The Structural Modeling Style Five basic computational elements in two classes

Executive (or infrastructure)Periodic sequencerEvent handlerSynchronizer

ApplicationComponentsSubsystems

Each of the five has Small API Encapsulated state Severely limited external data upon which it relies


48

Level–0 Architecture


49

Level–1 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.

cs 1023 lec 13 web (week 4)

Education

wwws architecture

web software architecture

rest components

instance of rest

representation reuse

rest principles rp1

nenad medvidovic

practice richard