SEng 5861: Software Architecture

SEng 5861: Software Architecture Lecture 11 Dr. Michael Whalen Fall 2010 SEng 5861 - Mike Whalen

Topics for Today • Questions / Comments from Last Week • Grading on project Phase III • Group presentations • Final review & expectations • Performance and Scalability Perspective SEng 5861 - Mike Whalen

Updates • Remember: tomorrow (12/10) is the colloquium • Speaker: Leon Webster • Very interesting guy! • Talking about SOA…with much more authority than I can  • December 17th is the Final exam • I probably won’t finish RESTful services today, so I will try to finish up on Dec. 17th. • Therefore, RESTful services will not be on the final – though general REST concepts are fair game. • We will start with questions • I’ll make it somewhat shorter than midterm • I don’t want it to be about how fast you can write. SEng 5861 - Mike Whalen

Updates • If you are planning to register for Independent Study in the Spring, please find an advisor and tell Mats or me. • Phase III project grades • Mostly done, but not done • Just a couple projects left • You will get them today • I apologize! • Presentation grades: you will get them right after class. http://www.youtube.com/watch?v=xbE8E1ez97M SEng 5861 - Mike Whalen

Technical Presentations • You have the floor… SEng 5861 - Mike Whalen

Final Exam Topics • Viewpoints • Functional • Information • Concurrency • EI Patterns • Deployment • Operations • Perspectives • Security • Performance and Scalability • System Scope • Stakeholders • Scenarios • Architecture Languages (but not AADL) • REST (but not RESTful services) SEng 5861 - Mike Whalen

Final final questions? SEng 5861 - Mike Whalen

Performance and scalability SEng 5861 - Mike Whalen

Performance and Scalability Performance defines how quickly the system responds to expected user tasks. It is usually expressed in terms of an expected performance profile. Scalability focuses on the predictability of performance as the workload increases. SEng 5861 - Mike Whalen

Concerns • Response Time • Responsiveness [Interactive] • Turnaround Time [Batch] • Throughput • Scalability • Predictability • Peak Load Behavior • Hardware Resource Requirements SEng 5861 - Mike Whalen

Activities SEng 5861 - Mike Whalen

Capturing Performance Requirements • How do you do this? • What kinds of information should you capture? • Response time for common actions • Use cases • Based on context • Throughput requirements • Peak load • Scalability SEng 5861 - Mike Whalen

Performance Requirements Example Context: System has fewer than 50 concurrent users Activity: User adds an item to their online shopping cart Expected response time: 95% of the time, under 2.5 seconds. 99.9% of the time under 10 seconds. Context: System has fewer than 500 concurrent users (reference load) Activity: User adds an item to their online shopping cart Expected response time: 95% of the time, under 5 seconds. 99.9% of the time under 20 seconds. SEng 5861 - Mike Whalen

Create Performance Models • Many client-server systems perform like this: SEng 5861 - Mike Whalen

Create Performance Models • Want to find the “knee” in the curve • How do you do this? • Several formal notations can capture this: queuing theory, Petri Nets • However, most analysis is done in an ad-hoc way • Examine the physical & logical architecture of the system • Estimate (and test) the costs associated with each component • Examine use-cases to determine sequences of operations & sum costs SEng 5861 - Mike Whalen

Example Performance Model • Fig 25-3 Pg. 409 SEng 5861 - Mike Whalen

Embedded Systems Performance • Specify task WCETs / Periods for OS scheduling • Define network I/O requirements per task • Define partitioning of resources for safety / fault tolerance requirements • Determine whether tasks can be mapped to physical resources such that processor/network utilization can be scheduled • Use testing or static analysis to determine whether implementation WCETs match projections • AADL models can do this fairly well. SEng 5861 - Mike Whalen

Performance Testing • How do you do it? • Can be done piecewise and/or end-to-end • Piecewise can be used to validate model assumptions for estimates • End-to-end testing is required to accurately model behavior of real system • Many pitfalls if tests do not accurately model field usage SEng 5861 - Mike Whalen

Activities SEng 5861 - Mike Whalen

Tactics • Optimize repeated processing (80/20 rule) • Replicate contentious resources • Prioritize processing • Consolidate related workload (buffering) • Parallelize • Use asynchronous processing (message queueing) SEng 5861 - Mike Whalen

Pitfalls • Imprecise Requirements • Often missing context! • Check with stakeholders • Unrealistic V&V • Incorrect or underspecified performance models • Unrealistic test scenarios • Poor partitioning • Logically: “god elements” in architecture • Physically: tightly coupled resources should, when possible, be co-located. SEng 5861 - Mike Whalen

Networking and distribution styles (REST) SEng 5861 - Mike Whalen

Network Distribution Styles • Many possible ways to distribute and communicate between applications across multiple computing devices. • Possible to think of distribution across several dimensions • Data flow • Replication • Hierarchy and Layering • Code Mobility • Roy Fielding examines these dimensions from the perspective of extreme scale and modifiability. SEng 5861 - Mike Whalen

Evaluation Criteria • Network Performance: How efficiently the style uses the network: (available bandwidth = throughput – overhead) • User-Perceived Performance: Performance of the style as perceived by the user: • latency : period between initial stimulus and first indication of response • completion time: period between initial stimulus and completion of response • Network Efficiency: how efficiently the style uses the network • The most efficient style does not use the network . • Considers caching, locality. • Scalability: support of large number of components and interactions • Simplicity: how well does architecture support separation of concerns? How straightforward is it to understand and support? SEng 5861 - Mike Whalen

Evaluation Criteria Continued • Evolvability: The degree to which a component implementation can be changed without negatively impacting other components. • Extensibility: The ability to add functionality to a system. Dynamic extensibility implies that functionality can be added to a deployed system without impacting the rest of the system. • Customizability: The ability to temporarily specialize the behavior of an architectural element, such that it can then perform an unusual service. • Configurability: refers to post-deployment modification of components, or configurations of components, such that they are capable of using a new service or data element type. • Reusability: degree to which components, connectors, or data elements can be reused, without modification, in other applications SEng 5861 - Mike Whalen

Evaluation Criteria Continued • Visibility: ability of a component to monitor or mediate the interaction between two other components • Portability: Software is portable if it can run in different environments. • Reliability: the degree to which an architecture is susceptible to failure at the system level in the presence of partial failures within components, connectors, or data SEng 5861 - Mike Whalen

Client/Server • most hyped, least meaningful style • emphasizes separation of concerns • initiators (clients) and listeners (servers) SEng 5861 - Mike Whalen Slide from: Representational State Transfer: An Architectural Style for Distributed Hypermedia Interaction by Roy Fielding

Layered Client Server (N-tier) • Increases scalability • Increased evolvability … … SEng 5861 - Mike Whalen

Stateless Client/Server • No client state stored on server • Visibility, Scalability and Reliability are improved SEng 5861 - Mike Whalen Slide from: Representational State Transfer: An Architectural Style for Distributed Hypermedia Interaction by Roy Fielding

Stateless Cached Client/Server • No client state stored on server • Visibility, Scalability and Reliability are improved C C SEng 5861 - Mike Whalen Slide from: Representational State Transfer: An Architectural Style for Distributed Hypermedia Interaction by Roy Fielding

Remote Session • each client initiates a session on server • application state kept on server • commands are used to exchange data orchange session state • flexible, interactive, easy to extend services • scalability is a problem SEng 5861 - Mike Whalen Slide from: Representational State Transfer: An Architectural Style for Distributed Hypermedia Interaction by Roy Fielding

Remote Data Access (RDA) • Clients send database queries to remote server • Server maintains per-client state for joins/trans. • Client must know enough about data structure to build structure-dependent queries • SQL commonly used to define query • Results transferred by (proprietary) protocol SEng 5861 - Mike Whalen Slide from: Representational State Transfer: An Architectural Style for Distributed Hypermedia Interaction by Roy Fielding

Pipe-and-Filter • a.k.a., one-way data flow • data stream is filtered through a sequence of components • components do not need to know identity of peers • components are transitive SEng 5861 - Mike Whalen Slide from: Representational State Transfer: An Architectural Style for Distributed Hypermedia Interaction by Roy Fielding

Event-based Integration • components listen to a message bus or register with a broker • components do not need to know identity of peers • separation of concerns, independent evolution • usually not designed for high-latency networks • poor scalability • collisions or single point of failure SEng 5861 - Mike Whalen Slide from: Representational State Transfer: An Architectural Style for Distributed Hypermedia Interaction by Roy Fielding

Putting it all together… SEng 5861 - Mike Whalen

Code Motion • Virtual Machine: provides portability • Remote Evaluation: client sends code to server • Code on Demand: server sends code to client • Layered Code on Demand Client Cache Stateless Server: code is not session dependent, so you can use C$SS for it. Winner of the Buzzword Award SEng 5861 - Mike Whalen

SEng 5861 - Mike Whalen

SEng 5861 - Mike Whalen Slide from: A little REST and Relaxation by Roy Fielding

REST Uniform Interface • All important resources are identified by one (uniform) resource identifier mechanism • simple, visible, reusable, stateless communication • Access methods (actions) mean the same for all resources (universal semantics) • layered system, cacheable, and shared caches • Resources are manipulated through the exchange of representations • simple, visible, reusable, cacheable, and stateless communication • Exchanged as self-descriptive messages • Layered system, cacheable, and shared caches SEng 5861 - Mike Whalen Slide from: A little REST and Relaxation by Roy Fielding

REST Uniform Interface Hypertext as the engine of application state • A successful response indicates (or contains) a current representation of the state of the identified resource; the resource remains hidden behind the interface. • Some representations contain links to potential next application states, including direction on how to transition to those states when a transition is selected. • Each steady-state (Web page) embodies the current application state • simple, visible, scalable, reliable, reusable, and cacheable • All application state (not resource state) is kept on client • All shared state (not session state) is kept on origin server SEng 5861 - Mike Whalen Slide from: A little REST and Relaxation by Roy Fielding

Hypertext Clarification Hypertext has many (old) definitions • "By 'hypertext,' I mean non-sequential writing — text that branches and allows choices to the reader, best read at an interactive screen. As popularly conceived, this is a series of text chunks connected by links which offer the reader different pathways“[Theodor H. Nelson] • “Hypertext is a computer-supported medium for information in which many interlinked documents are displayed with their links on a high-resolution computer screen.”[Jeffrey Conklin] When I say Hypertext, I mean ... • The simultaneous presentation of information and controls such that the information becomes the affordance through which the user obtains choices and selects actions. • Hypertext does not need to be HTML on a browser • machines can follow links when they understand the data format and relationship types SEng 5861 - Mike Whalen Slide from: A little REST and Relaxation by Roy Fielding

Hypertext Clarification Hypertext has many (old) definitions • "By 'hypertext,' I mean non-sequential writing — text that branches and allows choices to the reader, best read at an interactive screen. As popularly conceived, this is a series of text chunks connected by links which offer the reader different pathways“[Theodor H. Nelson] • “Hypertext is a computer-supported medium for information in which many interlinked documents are displayed with their links on a high-resolution computer screen.”[Jeffrey Conklin] When I say Hypertext, I mean ... • The simultaneous presentation of information and controls such that the information becomes the affordance through which the user obtains choices and selects actions. • Hypertext does not need to be HTML on a browser • machines can follow links when they understand the data format and relationship types Hypertext = non-linear documents Hypertext = selectable GUI controls Hypertext = data-guided controls SEng 5861 - Mike Whalen Slide from: A little REST and Relaxation by Roy Fielding

Web Requirements & Properties Low entry barrier • Hypermedia User Interface • Simple protocols for authoring and data transfer • must be Simple and Reusable; want Extensible Distributed Hypermedia System • Large data transfers • Sensitive to user-perceived latency • must be Data-driven and Streamable; want Performant Multiple organizational boundaries • Anarchic scalability • Gradual and fragmented change (deployment) • must be Scalable, Portable, Evolvable; want Reliable, Visible, Customizable, Configurable, Extensible, ... SEng 5861 - Mike Whalen Slide from: A little REST and Relaxation by Roy Fielding

What is the web, really? Information Browsers SEng 5861 - Mike Whalen Slide from: A little REST and Relaxation by Roy Fielding

SEng 5861: Software Architecture