Applied Architectures Copyright Richard N Taylor Nenad Medvidovic

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

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

Software Architecture Foundations, Theory, and Practice Outline l l l Distributed and networked architectures u Limitations u REST u Commercial Internet scale applications Decentralized applications u Peer to peer u Web services Some interesting domains u Robotics u Wireless sensors u Flight simulators 3

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

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

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

Software Architecture Foundations, Theory, and Practice WWW’s Architecture l l l 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. u E. g. , different Web browsers Stylistic constraints of the Web’s architectural style are not apparent in the code u 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. 7

Software Architecture Foundations, Theory, and Practice REST Principles l l l [RP 1] The key abstraction of information is a resource, named by an URL. Any information that can be named can be a resource. [RP 2] 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. [RP 3] 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. 8

Software Architecture Foundations, Theory, and Practice REST Principles (cont’d) l [RP 4] 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. 9

Software Architecture Foundations, Theory, and Practice REST Principles (cont’d) l l [RP 5] Idempotent operations and representation metadata are encouraged in support of caching and representation reuse. [RP 6] 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. 10

Software Architecture Foundations, Theory, and Practice An Instance of REST 11

Software Architecture Foundations, Theory, and Practice REST — Data Elements l l l Resource u Key information abstraction Resource ID Representation u Data plus metadata Representation metadata Resource metadata Control data u e. g. , specifies action as result of message 12

Software Architecture Foundations, Theory, and Practice REST — Connectors l l l 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 13

Software Architecture Foundations, Theory, and Practice REST — Components l l User agent u e. g. , browser Origin server u e. g. , Apache Server, Microsoft IIS Proxy u Selected by client Gateway u Squid, CGI, Reverse proxy u Controlled by server 14

Software Architecture Foundations, Theory, and Practice An Instance of REST Revisited 15

Software Architecture Foundations, Theory, and Practice Derivation of REST Key choices in this derivation include: l 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; l Replication (left side of the diagram) is used to address latency and contention by allowing the reuse of information; l Limited commonality (right side) addresses the competing needs for universally understood operations with extensibility. The derivation is driven by the application(!) 16

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

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

Software Architecture Foundations, Theory, and Practice Commercial Internet-Scale Applications l l Akamai u Caching to the max Google u Google distributed file system (GFS) u Map. Reduce l Data selection and reduction l All parallelization done automatically 19

Software Architecture Foundations, Theory, and Practice Architectural Lessons from Google l l l Abstraction layers abound: GFS hides details of data distribution and failure, for instance; Map. Reduce 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; 20

Software Architecture Foundations, Theory, and Practice Architectural Lessons from Google (cont’d) l l 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 (Map. Reduce) to the data extraction/reduction problem, a highly reusable service was created. 21

Software Architecture Foundations, Theory, and Practice Decentralized Architectures l l Networked applications where there are multiple authorities In other words u Computation is distributed u Parts of the network may behave differently, and vary over time It’s just like collaboration in the real world 22

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

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

Software Architecture Foundations, Theory, and Practice Peer-to-Peer Architectures l l Decentralized resource sharing and discovery u Napster u Gnutella P 2 P that works: Skype u And Bit. Torrent 25

Software Architecture Foundations, Theory, and Practice Peer-to-Peer Style l l l 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! 26

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

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

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

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

Software Architecture Foundations, Theory, and Practice Insights from Skype l l l 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. 31

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

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

Software Architecture Foundations, Theory, and Practice Mobile Robotics l l l Manned or partially manned vehicles Uses u Space exploration u Hazardous waste disposal u Underwater exploration Issues u Interface with external sensors & actuators u Real time response to stimuli u Response to obstacles u Sensor input fidelity u Power failures u Mechanical limitations u Unpredictable events 34

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

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

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

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

Software Architecture Foundations, Theory, and Practice Flight Simulators l Extremely complex systems l http: //www. gillesvidal. com/blogpano/cockpit 1. htm 39

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

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

Software Architecture Foundations, Theory, and Practice Functional Model 42

Software Architecture Foundations, Theory, and Practice How Is the Complexity Managed? l New style u “Structural Modeling” u Based on l Object–oriented design to model air vehicle’s u Sub systems u Components l Real time l scheduling to control execution order Goals of Style u Maintainability u Integrability u Scalability 43

Software Architecture Foundations, Theory, and Practice How Is the Complexity Managed? (cont’d) l Style principles u Pre defined partitioning of functionality among SW elements u Restricted data & control flow l Data flow through export areas only u Decoupling u objects Small number of element types l Results in replicated subsystems 44

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

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

Software Architecture Foundations, Theory, and Practice Level– 0 Architecture 47

Software Architecture Foundations, Theory, and Practice Level– 1 Architecture 48

Software Architecture Foundations, Theory, and Practice Online Gaming – EMPIREBET 49

Software Architecture Foundations, Theory, and Practice EMPIREBET Non-Functional Requirements l l l Performance 1. Efficiency 2. Scalability Dependability 3. Reliability 4. Availability Flexibility 5. Modularity 6. Adaptability 50

Software Architecture Foundations, Theory, and Practice EMPIREBET – Original Architecture 51

Software Architecture Foundations, Theory, and Practice EMPIREBET – Current Architecture 52

Software Architecture Foundations, Theory, and Practice libcomm – Component Communication 53

Software Architecture Foundations, Theory, and Practice Two Patterns in libcomm Reactor 54

Software Architecture Foundations, Theory, and Practice Two Patterns in libcomm Acceptor-Connector 55

Software Architecture Foundations, Theory, and Practice libcomm – Component Communication 56

Software Architecture Foundations, Theory, and Practice EMPIREBET – Current Architecture 57

Software Architecture Foundations, Theory, and Practice Takeaways l l 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. u Most likely you don’t need a new style. 58