Applied Architectures Part 2 Software Architecture Lecture 18

Applied Architectures, Part 2 Software Architecture Lecture 18 Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved.

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 2

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 Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission. 3

Software Architecture: Foundations, Theory, and Practice Grid GLOBUS (Recovered) 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 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 5

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! 6

Software Architecture: Foundations, Theory, and Practice Peer-to-Peer LL 7 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) 8 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) 9 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 10 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. 11

Software Architecture: Foundations, Theory, and Practice Web Services 12 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) 13 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 14

Software Architecture: Foundations, Theory, and Practice Robotics: Sense-Plan-Act 15 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 16 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 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 Wireless Sensor Networks 18 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: 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 19

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 20

Software Architecture: Foundations, Theory, and Practice Functional Model 21

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 22

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 23

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 24

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 25

Software Architecture: Foundations, Theory, and Practice Level– 0 Architecture 26

Software Architecture: Foundations, Theory, and Practice Level– 1 Architecture 27

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. Most likely you don’t need a new style. 28