Cs 1023 lec 13 web (week 4)

262 views

Published on

Published in: Education, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
262
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Process view of a REST-based architecture at one instance in time. A user agent is portrayed in the midst of three parallel interactions: a, b, and c. The interactions were not satisfied by the user agent’s client connector cache, so each request has been routed to the resource origin according to the properties of each resource identifier and the configuration of the client connector. Request (a) has been sent to a local proxy, which in turn accesses a caching gateway found by DNS lookup, which forwards the request on to be satisfied by an origin server whose internal resources are defined by an encapsulated object request broker architecture. Request (b) is sent directly to an origin server, which is able to satisfy the request from its own cache. Request (c) is sent to a proxy that is capable of directly accessing WAIS, an information service that is separate from the Web architecture, and translating the WAIS response into a format recognized by the generic connector interface. Each component is only aware of the interaction with their own client or server connectors; the overall process topology is an artifact of our view.
  • Process view of a REST-based architecture at one instance in time. A user agent is portrayed in the midst of three parallel interactions: a, b, and c. The interactions were not satisfied by the user agent’s client connector cache, so each request has been routed to the resource origin according to the properties of each resource identifier and the configuration of the client connector. Request (a) has been sent to a local proxy, which in turn accesses a caching gateway found by DNS lookup, which forwards the request on to be satisfied by an origin server whose internal resources are defined by an encapsulated object request broker architecture. Request (b) is sent directly to an origin server, which is able to satisfy the request from its own cache. Request (c) is sent to a proxy that is capable of directly accessing WAIS, an information service that is separate from the Web architecture, and translating the WAIS response into a format recognized by the generic connector interface. Each component is only aware of the interaction with their own client or server connectors; the overall process topology is an artifact of our view.
  • A flight simulator must provide a great number and great variety of services to its users.
    crew being trained: pilot, co-pilot, navigator, and weapons personnel (if this is a military simulator)
    "instructor-operator".
    In charge of the pedagogical aspects of flight simulation
    Decides what mission will be run, and under what conditions
    Controls the simulation in real time
    Runs simulation, insert malfunctions (in order to test the flight crew's response to emergency situations), or freezes simulation if some pedagogical point is to be made.
    Simulator must provide visual, audio and motion cues to the users-the aircrew. In addition, some simulators will have to provide a force-feed­back cues. These sensory cues are generated in order to provide the sights, sounds and feel of a normal air vehicle. The software must also simulate the air vehicle's normal set of instruments. These must all be simulated to a high degree of fidelity, with a high degree of coordination (in order to avoid simulator sickness).
    The aircrew will be responding to their environment in real-time. Some of these responses are continuous (the pilot's "stick", for example), and some will be events (changing the setting of a switch). These responses will need to be communicated back to the software simulation as they change the state of the simulation. In addi­tion, as the air vehicle is being navigated, the environment through which it is passing changes, which will, in turn, affect both the sensory inputs being fed to the aircrew, and the state of the simulation.
  • Functionality is partitioned into
    objects analogous to aircraft components: pumps, actuators, valves, etc.
    few classes of objects,
    all objects within a class
    look the same
    have the same entry points (or methods).
    Parts of a simulation for which no real-world analogy (such as data gatherers)
    modeled in the same way as the real-world entities
    using the same software structures.
    Minimizing the number of base types
    Goal
    Provide higher-level commonalities among groupings of objects
    Encapsulate patterns of system behavior at a high level of abstraction.
    Eases the development of large systems.
    Every part of the system is composed of the same small set of base types
    the system is more regular,
    easier to
    communicate,
    learn,
    review,
    modify.
    Fixed control patterns
    Easier to understand & analyzed temporal depen­dencies to be more
    Data Flow through export areas
    Reduces dependencies & coupling
    Objects don’t need to know identity of other object to communicate
    Message traffic is channeled so can be easily
    Controlled
    Monitored
    Measured
    Limited coordination strategies
    Reduces programmer assumptions about time relations
    Makes easier to distribute & control
  • Functionality is partitioned into
    objects analogous to aircraft components: pumps, actuators, valves, etc.
    few classes of objects,
    all objects within a class
    look the same
    have the same entry points (or methods).
    Parts of a simulation for which no real-world analogy (such as data gatherers)
    modeled in the same way as the real-world entities
    using the same software structures.
    Minimizing the number of base types
    Goal
    Provide higher-level commonalities among groupings of objects
    Encapsulate patterns of system behavior at a high level of abstraction.
    Eases the development of large systems.
    Every part of the system is composed of the same small set of base types
    the system is more regular,
    easier to
    communicate,
    learn,
    review,
    modify.
    Fixed control patterns
    Easier to understand & analyzed temporal depen­dencies to be more
    Data Flow through export areas
    Reduces dependencies & coupling
    Objects don’t need to know identity of other object to communicate
    Message traffic is channeled so can be easily
    Controlled
    Monitored
    Measured
    Limited coordination strategies
    Reduces programmer assumptions about time relations
    Makes easier to distribute & control
  • two main sets of con­cerns: executive and application.
    executive handles coordination issues:
    real-time scheduling of sub-systems,
    synchronization between processors,
    event management from the instructor-opera­tor station,
    data sharing, and
    data integrity
    application handles computation
    modeling the air vehicle
  • timeline synchronizer
    controls data accesses, periodic processing and event processing by scheduling the periodic sequencer and the event handler
    maintains syn­chronization with other processes
    periodic sequencer
    Handles the regular scheduling of sub-systems when it is invoked through its periodic processing operation
    event handler
    Handles aperiodic events principally from the instructor-operator station
    Sub-system Controllers
    coordinate the activities of the purely computational com­ponents
    group these components into meaningful collections which represent sub-systems within the air vehicle:
    hydraulics,
    air-frame,
    fuel,
    braking,
    engines
    sub-system invokes each component in turn, passing it the relevant state data
    Components
    models of things like reservoirs, valves, turbines, and actuators
    do the actual simulation computation
  • Cs 1023 lec 13 web (week 4)

    1. 1. Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Applied Architectures
    2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 40. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture Flight Simulators 40  Extremely complex systems  http://www.gillesvidal.com/blogpano/cockpit1.htm
    41. 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. 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. 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. 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. 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. 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. 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. 48. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture 48 Level–0 Architecture
    49. 49. Foundations, Theory, and PracticeSoftware ArchitectureSoftware Architecture 49 Level–1 Architecture
    50. 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.

    ×