1 Software Architecture And Design Session 1: Introduction to Software Architecture 2 Session Outline IT Systems Application Domain What is Software Architecture? Definitions What does an architect do? Architectures and technologies Further reading 3 IT Systems Application Domain IT systems are everywhere Banks Shops Internet sites Large, complex, heterogeneous, distributed applications Use commercial-off-the-shelf middleware, databases, web servers, application packages Major problems are architecture design, technology selection, application and business integration 4 What is Software Architecture? It’s about software design All architecture is software design, but not all design is software architecture Part of the design process Simply, architecture focuses on ‘issues that will be difficult/impossible to change once the system is built’ Quality attributes like security, performance Non-functional requirements like cost, deployment hardware More on these later in this session 5 Defintions – ANSI/IEEE Std 1471-2000 “Architecture is the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.” 6 Definitions – SEI “The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.” 7 Definitions – Garlan and Shaw “[Software architecture goes] beyond the algorithms and data structures of the computation; designing and specifying the overall system structure emerges as a new kind of problem. Structural issues include gross organization and global control structure; protocols for communication, synchronization, and data access; assignment of functionality to design elements; physical distribution; composition of design elements; scaling and performance; and selection among design alternatives.” 8 Architecture Defines Structure Decomposition of system in to components/modules/subsystems Architecture defines: Component interfaces What a component can do Component communications and dependencies How components communicate Component responsibilities Precisely what a component will do when you ask it 9 Structure and Dependencies Excessive component dependencies are bad! Key architecture issue Identifying components that may change Reduce direct dependencies on these components Creates more modifiable systems C1 Third Party Component Diagram Key Component Dependency C1 C2 C3 C4 C Third Party Component AL Four components are directly dependent on a third party component. If the third party component is replaced with a new component with a different interface, changes to each component are likely. Only the AL (abstraction layer) component is directly dependent on the third party component. If the third party component is replaced, changes are restricted to the AL component only C2 C3 C4 10 Architecture Specifies Component Communication Communication involves: Data passing mechanisms, e.g.: Function call Remote method invocation Asynchronous message Control flow Flow of messages between components to achieve required functionality Sequential Concurrent/parallel Synchronization 11 Architecture Patterns/Styles Patterns catalogue successfully used structures that facilitate certain kinds of component communication client-server Message broker Pipeline Patterns have well-known characteristics appropriate for particular types of requirements Patterns are very useful things … Reusable architectural blueprints Help efficiently communicate a design Large systems comprise a number of individual patterns “Patterns and Styles are the same thing – the patterns people won” [anonymous SEI member] 12 Architecture addresses NFRs Non-functional requirements (NFRs) define ‘how’ a system works NFRs rarely captured in functional requirements Aka. architecture requirements Must be elicited by architect NFRs include: Technical constraints (e.g.we must develop in Java) Business constraints (e.g.raised prices,so moving to an open source version) Quality attributes 13 Architecture is an Abstraction Architecture provides an abstract view of a design Hides complexity of design May or may not be a direct mapping between architecture elements and software elements Example – A Marketecture informal depiction of system’s structure and interactions. portray the design philosophies embodied in the architecture Every system should have a marketecture: Easy to understand Helps discussion during design, build, review, sales (!) process 14 Decomposition Hierarchical decomposition is a powerful abstraction mechanism Partitions design Allocate components to development teams Why isn’t the Client component decomposed? Client Broker Server Diagram Key Component Dependency C Top Level Architecture Description Security Server Messag e Handler Director y Server Data Store Request Handler 15 Architecture Views A software architecture represents a complex design artifact Many possible ‘views’ of the architecture Cf. with buildings – floor plan, external, electrical, plumbing, air-conditioning 16 Philippe Krutchen – 4+1 View Model Logical view: describes architecturally significant elements of the architecture and the relationships between them. Process view: describes the concurrency and communications elements of an architecture. Physical view: depicts how the major processes and components are mapped on to the applications hardware. Development view: captures the internal organization of the software components as held in e.g. a configuration management tool. Architecture use cases: capture the requirements for the architecture; related to more than one particular view 17 SEI – Views and Beyond Module: structural view of the architecture, comprising the code modules such as classes, packages and subsystems Component and Connector: describes the behavioral aspects of the architecture. Components are objects, threads or processes, and connectors describe how components interact. Allocation: shows how the processes are mapped to hardware and gives a view of the source code in the configuration management systems. This course will focus on structural and behavioral views 18 What does an Architect do? Many responsibilities: Liaison with stakeholders Technology knowledge Software engineering Risk managements Long list at: http://www.sei.cmu.edu/ata/arch_duties.html 19 Architectures and Technologies Architects reduce risks by using proven design patterns Must map abstract design pattern to concrete implementation Software vendors have created (COTS) technologies that explicitly support widely used patterns Makes implementation of patterns easier Reduces risk if technology is well built 20 Architectures and Technologies Each technology has multiple vendors/open source versions Architects need to choose technology wisely Proof of concept prototype Detailed feature evaluation Architectural Patterns/Styles Application Servers Messaging Message Brokers Object Brokers Process Orchestration Concrete COTS technologies Abstract 21 Summary “The life of a software architect is a long (and sometimes painful) succession of suboptimal decisions made partly in the dark” Architecture involves complex design decisions Architect role is much more than just technical design Made harder by early lifecycle nature of much of the design 22 Software Architecture And Design Session 2: Architectural Styles of Software Systems 23 State of Practice There is not currently a well-defined terminology or notation to characterize architectural structures. However, good software engineers make common use of architectural principles when designing complex software. These principles represent rules of thumb or idiomatic patterns that have emerged informally over time. Others are more carefully documented as industry standards. 24 Descriptions of Architectures “Camelot is based on the client-server model and uses remote procedure calls both locally and remotely to provide communication among applications and servers.” 25 Descriptions of Architectures (Cont’d) “Abstraction layering and system decomposition provide the appearance of system uniformity to clients, yet allow Helix to accommodate a diversity of autonomous devices. The architecture encourages a client-server model for the structuring of applications.” 26 Descriptions of Architectures (Cont’d) “We have chosen a distributed, objectoriented approach to managing information.” 27 Descriptions of Architectures (Cont’d) “The easiest way to make a canonical sequential compiler into a concurrent compiler is to pipeline the execution of the compiler phases over a number of processors. A more effective way is to split the source code into many segments, which are concurrently processed through the various phases of compilation (by multiple compiler processes) before a final, merging pass recombines the object code into a single program.” 28 Some Standard Architectures ISO/OSI Reference Model is a layered network architecture. X Window System is a distributed windowed user interface architecture based on event triggering and callbacks. NIST/ECMA Reference Model is a generic software engineering environment architecture based on layered communication substrates. 29 The “Toaster” Model 30 Intuition About Architecture 31 Intuition About Architecture It is interesting that we have so few named software architectures. This is not because there are so few architectures, but so many. We next look at several architectural disciplines in order to develop an intuition about software architecture. Specifically, we look at: Hardware Architecture Network Architecture Building Architecture 32 Hardware Architecture RISC machines emphasize the instruction set as an important feature. Pipelined and multi-processor machines emphasize the configuration of architectural pieces of the hardware. 33 Differences & Similarities Between SW & HW Architectures Differences: relatively (to software) small number of design elements. scale is achieved by replication of design elements. Similarities: we often configure software architectures in ways analogous to hardware architectures. (e.g., we create multi-process software and use pipelined processing). 34 Network Architecture Networked architectures are achieved by abstracting the design elements of a network into nodes and connections. Topology is the most emphasized aspect: Star networks Ring networks Manhattan Street networks Unlike software architectures, in network architectures only few topologies are of interest. 35 Building Architecture Multiple Views: skeleton frames, detailed views of electrical wiring, etc. Architectural Styles: Classical, Romanesque, and so on. Materials: One does not build a skyscraper using wooden posts and beams. 36 Architectural Styles of Software Systems An Architectural Style defines a family of systems in terms of a pattern of structural organization. It determines: the vocabulary of components and connectors that can be used in instances of that style, a set of constraints on how they can be combined. For example, one might constrain: the topology of the descriptions (e.g., no cycles). execution semantics (e.g., processes execute in parallel). 37 Determining an Architectural Style We can understand what a style is by answering the following questions: What is the structural pattern? (i.e., components, connectors, constraints) What is the underlying computational model? What are the essential invariants of the style? What are some common examples of its use? What are the advantages and disadvantages of using that style? What are some of the common specializations of that style? 38 Describing an Architectural Style The architecture of a specific system is a collection of: computational components, description of the interactions between these components (connectors). 39 Describing an Architectural Style (Cont’d) software architectures are represented as graphs where nodes represent components: procedures modules processes tools databases and edges represent connectors: procedure calls event broadcasts database queries pipes 40 Pipe and Filter Architectural Style Suitable for applications that require a defined series of independent computations to be performed on ordered data. A component reads streams of data on its inputs and produces streams of data on its outputs. 41 Pipe and Filter Architectural Style (Cont’d) Components: called filters, apply local transformations to their input streams and often do their computing incrementally so that output begins before all input is consumed. Connectors: called pipes, serve as conduits for the streams, transmitting outputs of one filter to inputs of another. 42 Pipe and Filter Architectural Style (Cont’d) 43 Pipe and Filter Invariants Filters do not share state with other filters. Filters do not know the identity of their upstream or downstream filters. The correctness of the output of a pipe and filter network should not depend on the order in which their filters perform their incremental processing. 44 Pipe and Filter Specializations Pipelines: Restricts topologies to linear sequences of filters. Batch Sequential: A degenerate case of a pipeline architecture where each filter processes all of its input data before producing any output. 45 Pipe and Filter Examples Unix Shell Scripts: Provides a notation for connecting Unix processes via pipes. cat file | grep Erroll | wc -l Traditional Compilers: Compilation phases are pipelined, though the phases are not always incremental. The phases in the pipeline include: lexical analysis + parsing + semantic analysis + code generation 46 Pipe and Filter Advantages Easy to understand the overall input/output behavior of a system as a simple composition of the behaviors of the individual filters. They support reuse, since any two filters can be hooked together, provided they agree on the data that is being transmitted between them. 47 Pipe and Filter Advantages (Cont’d) Systems can be easily maintained and enhanced, since new filters can be added to existing systems and old filters can be replaced by improved ones. They permit certain kinds of specialized analysis, such as throughput and deadlock analysis. They naturally support concurrent execution. 48 Pipe and Filter Disadvantages Not good for handling interactive systems, because of their transformational character. Excessive parsing and unparsing leads to loss of performance and increased complexity in writing the filters themselves. 49 Object-Oriented Style Suitable for applications in which a central issue is identifying and protecting related bodies of information (data). Data representations and their associated operations are encapsulated in an abstract data type. Components: are objects. Connectors: are function and procedure invocations (methods). 50 Object-Oriented Style (Cont’d) 51 Object-Oriented Invariants Objects are responsible for preserving the integrity (e.g., some invariant) of the data representation. The data representation is hidden from other objects. 52 Object-Oriented Specializations Distributed Objects Objects with Multiple Interfaces 53 Object-Oriented Advantages Because an object hides its data representation from its clients, it is possible to change the implementation without affecting those clients. Can design systems as collections of autonomous interacting agents. 54 Object-Oriented Disadvantages In order for one object to interact with another object (via a method invocation) the first object must know the identity of the second object. Contrast with Pipe and Filter Style. When the identity of an object changes it is necessary to modify all objects that invoke it. Objects cause side effect problems: E.g., A and B both use object C, then B’s affect on C look like unexpected side effects to A. 55 Implicit Invocation Style Suitable for applications that involve looselycoupled collection of components, each of which carries out some operation and may in the process enable other operations. Particularly useful for applications that must be reconfigured on the fly: Changing a service provider. Enabling or disabling capabilities. 56 Implicit Invocation Style (Cont’d) Instead of invoking a procedure directly … A component can announce (or broadcast) one or more events. Other components in the system can register an interest in an event by associating a procedure with the event. When an event is announced, the broadcasting system (connector) itself invokes all of the procedures that have been registered for the event. 57 Implicit Invocation Style (Cont’d) An event announcement “implicitly” causes the invocation of procedures in other modules. 58 Implicit Invocation Invariants Announcers of events do not know which components will be affected by those events. Components cannot make assumptions about the order of processing. Components cannot make assumptions about what processing will occur as a result of their events (perhaps no component will respond). 59 Implicit Invocation Specializations Often connectors in an implicit invocation system also include the traditional procedure call in addition to the bindings between event announcements and procedure calls. 60 Implicit Invocation Examples Used in programming environments to integrate tools: Debugger stops at a breakpoint and makes that announcement. Editor responds to the announcement by scrolling to the appropriate source line of the program and highlighting that line. 61 Implicit Invocation Examples (Cont’d) Used to enforce integrity constraints in database management systems (called triggers). Used in user interfaces to separate the presentation of data from the applications that manage that data. 62 Implicit Invocation Advantages Provides strong support for reuse since any component can be introduced into a system simply by registering it for the events of that system. Eases system evolution since components may be replaced by other components without affecting the interfaces of other components in the system. 63 Implicit Invocation Disadvantages When a component announces an event: it has no idea what other components will respond to it, it cannot rely on the order in which the responses are invoked, it cannot know when responses are finished. 64 Client-Server Style Suitable for applications that involve distributed data and processing across a range of components. Components: Servers: Stand-alone components that provide specific services such as printing, data management, etc. Clients: Components that call on the services provided by servers. Connector: The network, which allows clients to access remote servers. 65 Client-Server Style 66 Client-Server Style Examples File Servers: Primitive form of data service. Useful for sharing files across a network. The client passes request for files over the network to the file server. 67 Client-Server Style Examples(Cont’d) Database Servers: More efficient use of distributing power than file servers. Client passes SQL requests as messages to the DB server; results are returned over the network to the client. Query processing done by the server. No need for large data transfers. Transaction DB servers also available. 68 Client-Server Style Examples (Cont’d) Object Servers: Objects work together across machine and network boundaries. ORBs allow objects to communicate with each other across the network. IDLs define interfaces of objects that communicate via the ORB. ORBs are the evolution of the RPC. 69 RPCs Versus ORBs 70 Client-Server Advantages Distribution of data is straightforward, transparency of location, mix and match heterogeneous platforms, easy to add new servers or upgrade existing servers. 71 Client-Server Disadvantages No central register of names and services — it may be hard to find out what services are available 72 Layered Style Suitable for applications that involve distinct classes of services that can be organized hierarchically. Each layer provides service to the layer above it and serves as a client to the layer below it. Only carefully selected procedures from the inner layers are made available (exported) to their adjacent outer layer. 73 Layered Style (Cont’d) Components: are typically collections of procedures. Connectors: are typically procedure calls under restricted visibility. 74 Layered Style (Cont’d) 75 Layered Style Specializations Often exceptions are be made to permit non-adjacent layers to communicate directly. This is usually done for efficiency reasons. 76 Layered Style Examples Layered Communication Protocols: Each layer provides a substrate for communication at some level of abstraction. Lower levels define lower levels of interaction, the lowest level being hardware connections (physical layer). Operating Systems Unix 77 Unix Layered Architecture 78 Layered Style Advantages Design: based on increasing levels of abstraction. Enhancement: since changes to the function of one layer affects at most two other layers. Reuse: since different implementations (with identical interfaces) of the same layer can be used interchangeably. 79 Layered Style Disadvantages Not all systems are easily structured in a layered fashion. Performance requirements may force the coupling of high-level functions to their lowerlevel implementations. 80 Repository Style Suitable for applications in which the central issue is establishing, augmenting, and maintaining a complex central body of information. Typically the information must be manipulated in a variety of ways. Often longterm persistence is required. 81 Repository Style (Cont’d) Components: A central data structure representing the correct state of the system. A collection of independent components that operate on the central data structure. Connectors: Typically procedure calls or direct memory accesses. 82 Repository Style (Cont’d) 83 Repository Style Specializations Changes to the data structure trigger computations. Data structure in memory (persistent option). Data structure on disk. Concurrent computations and data accesses. 84 Repository Style Examples Information Systems Programming Environments Graphical Editors AI Knowledge Bases Reverse Engineering Systems 85 Repository Style Advantages Efficient way to store large amounts of data. Sharing model is published as the repository schema. Centralized management: backup security concurrency control 86 Repository Style Disadvantages Must agree on a data model a priori. Difficult to distribute data. Data evolution is expensive. 87 Interpreter Style Suitable for applications in which the most appropriate language or machine for executing the solution is not directly available. 88 Interpreter Style (Cont’d) Components: include one state machine for the execution engine and three memories: current state of the execution engine program being interpreted current state of the program being interpreted Connectors: procedure calls direct memory accesses. 89 Interpreter Style (Cont’d) 90 Interpreter Style Examples Programming Language Compilers: Java Smalltalk Rule Based Systems: Prolog Coral Scripting Languages: Awk Perl 91 Interpreter Style Advantages Simulation of non-implemented hardware. Facilitates portability of application or languages across a variety of platforms. 92 Java Architecture 93 Interpreter Style Disadvantages Extra level of indirection slows down execution. Java has an option to compile code. JIT (Just In Time) compiler. 94 Process-Control Style Suitable for applications whose purpose is to maintain specified properties of the outputs of the process at (sufficiently near) given reference values. Components: Process Definition includes mechanisms for manipulating some process variables. Control Algorithm for deciding how to manipulate process variables. 95 Process-Control Style (Cont’d) Connectors: are the data flow relations for: Process Variables: Controlled variable whose value the system is intended to control. Input variable that measures an input to the process. Manipulated variable whose value can be changed by the controller. Set Point is the desired value for a controlled variable. Sensors to obtain values of process variables pertinent to control. 96 Feed-Back Control System The controlled variable is measured and the result is used to manipulate one or more of the process variables. 97 Open-Loop Control System Information about process variables is not used to adjust the system. 98 Process Control Examples Real-Time System Software to Control: Automobile Anti-Lock Brakes Nuclear Power Plants Automobile Cruise-Control Clean Architecture The business rules are testable by design and independent of frameworks, databases, UI technologies, and other external applications or interfaces. The domain code must not have any outward-facing dependencies. Instead, with the help of the DIP, all dependencies point toward the domain code. 99 100 In a clean architecture,all dependencies point inward toward the domain logic. Clean Architecture The core of the architecture contains the domain entities, which are accessed by the surrounding use cases. The use cases are what we have called services earlier. Around this core, we can find all the other components of our application that support the business rules. 101 Advantages Since the domain code knows nothing about which persistence or UI framework is used, it cannot contain any code specific to those frameworks and will concentrate on the business rules. We have all the freedom we could wish for to model the domain code. For example, apply Domain-Driven Design (DDD) in its purest form. 102 Disadvantage Since the domain layer is completely decoupled from the outer layers, we have to maintain a model of our application’s entities in each of the layers. That means we have to translate between both representations when the domain layer sends and receives data to and from other outer layers. 103 Example：Hexagonal Architecture 104 Example：Hexagonal Architecture The application core is represented as a hexagon. Within the hexagon, we find our domain entities and the use cases that work with them. The hexagon has no outgoing dependencies, so the dependency rule from clean architecture holds true. Instead, all dependencies point toward the center. 105 Example：Hexagonal Architecture Outside of the hexagon, we find various adapters that interact with the application. The adapters on the left-hand side are adapters that drive our application (because they call our application core). The adapters on the right-hand side are driven by our application (because they are called by our application core). 106 Example：Hexagonal Architecture To allow communication between the application core and the adapters, the application core provides specific ports. For driving adapters, such a port might be an interface that is implemented by one of the use case classes in the core and called by the adapter. For a driven adapter, such a port might be an interface that is implemented by the adapter and called by the core. 107 108 Case Study: Architecture of a Compiler 109 Architecture of a Compiler The architecture of a system can change in response to improvements in technology. This can be seen in the way we think about compilers. 110 Early Compiler Architectures In the 1970s, compilation was regarded as a sequential (batch sequential or pipeline) process: 111 Early Compiler Architectures Most compilers create a separate symbol table during lexical analysis and used or updated it during subsequent passes. 112 Modern Compiler Architectures Later, in the mid 1980s, increasing attention turned to the intermediate representation of the program during compilation. 113 Hybrid Compiler Architectures The new view accommodates various tools (e.g., syntax-directed editors) that operate on the internal representation rather than the textual form of a program. Architectural shift to a repository style, with elements of the pipeline style, since the order of execution of the processes is still predetermined. 114 Hybrid Compiler Architectures 115 Software Architecture And Design Session 3: Introduction to the Case Study 116 ICDE System Information Capture and Dissemination Environment (ICDE) is a software system for providing intelligent assistance to financial analysts scientific researchers intelligence analysts analysts in other domains 117 ICDE Schematic ICDE Repository ICDE Recording Software Local information repositories Internet Analyst 3 rd Party Tools 118 ICDE Use Cases ICDE Analyst 3rd Party Tools Data Store Capture User Actions Query User Actions User Assistance * * * * * * * * * * * * 119 Case Study Context ICDE version 1.0 in production Basically a complex, raw information capture tool, GUI for looking at captured data 2 tier client-server, single machine deployment Java, Perl, SQL, Programmatic access to data through very complex SQL (38 tables, 46 views) 120 ICDE version 2.0 ICDE v2.0 scheduled for development in 12 month timeframe Fixed schedule, budget Major changes to: Enhance data capture tools (GUI) Support 3rd party tool integration, testing, data access and large production scale deployments (100’s of users) Very few concrete requirements for the 3rd party tool support or release to full production environment 121 ICDE v2.0 Business Goals Business Goal Supporting Technical Objective Encourage third party tool developers Simple and reliable programmatic access to data store for third party tools Heterogeneous (i.e. non-Windows) platform support for running third party tools Allow third party tools to communicate with ICDE deployments from a remote machine Promote the ICDE concept to users Scale the data collection and data store components to support up to 150 users at a single site Low-cost deployment for each ICDE user workstation 122 Architecturally Significant Requirements for ICDE v2.0 ICDE project requirements: Heterogeneous platform support for access to ICDE data Instantaneous event notification (local/distributed) Over the Internet, secure ICDE data access Ease of programmatic data access ICDE Project team requirements: Insulate 3rd party projects and ICDE tools from database evolution Reliability for multi-tool ICDE deployments Scalable infrastructure to support large, shared deployments Minimize license costs for a deployment Unknowns Minimize dependencies, making unanticipated changes potentially easier 123 Summary ICDE is a reasonably complex system Will be used to illustrate concepts during the remainder of this course 124 Software Architecture And Design Session 4: Quality Attributes 125 What are Quality Attributes Often know as –ilities Reliability Availability Portability Scalability Performance (!) Part of a system’s NFRs “how” the system achieves its functional requirements 126 Quality Attribute Specification Architects are often told: “My application must be fast/secure/scale” Far too imprecise to be any use at all Quality attributes (QAs) must be made precise/measurable for a given system design, e.g. “It must be possible to scale the deployment from an initial 100 geographically dispersed user desktops to 10,000 without an increase in effort/cost for installation and configuration.” 127 Quality Attribute Specification QA’s must be concrete But what about testable? Test scalability by installing system on 10K desktops? Often careful analysis of a proposed solution is all that is possible “It’s all talk until the code runs” 128 Performance Many examples of poor performance in enterprise applications Performance requires a: Metric of amount of work performed in unit time Deadline that must be met Enterprise applications often have strict performance requirements, e.g. 1000 transactions per second 3 second average latency for a request 129 Performance – Throughput Measure of the amount of work an application must perform in unit time Transactions per second Messages per minute Is required throughput: Average? Peak? Many system have low average but high peak throughput requirements 130 Throughput Example 0 50 100 150 200 250 300 0 5 10 15 20 # of threads CPU % MST (msp) Throughput of a message queuing system Messages per second (msp) Maximum sustainable throughput (MST) Note throughput changes as number of receiving threads increases 131 Performance – Response Time measure of the latency an application exhibits in processing a request Usually measured in (milli)seconds Often an important metric for users Is required response time: Guaranteed? Average? E.g. 95% of responses in sub-4 seconds, and all within 10 seconds 132 Response Time Example shows response time distribution for a J2EE application 133 Performance – Deadlines ‘something must be completed before some specified time’ Payroll system must complete by 2am so that electronic transfers can be sent to bank Weekly accounting run must complete by 6am Monday so that figures are available to management Deadlines often associated with batch jobs in IT systems. 134 Something to watch for … What is a Transaction? Message? Request? All are application specific measures. System must achieve 100 mps throughput BAD!! System must achieve 100 mps peak throughput for PaymentReceived messages GOOD!!! 135 ICDE Performance Issues Response time: Overheads of trapping user events must be imperceptible to ICDE users Solution for ICDE client: Decouple user event capture from storage using a queue 1. Trap user event 2. Write event to queue 3. Return to user thread 4. Read event from queue 5. Write event to ICDE database queue 136 Scalability “How well a solution to some problem will work when the size of the problem increases.” 4 common scalability issues in IT systems: Request load Connections Data size Deployments 137 Scalability – Request Load How does an 100 tps application behave when simultaneous request load grows? E.g. From 100 to 1000 requests per second? Ideal solution, without additional hardware capacity: as the load increases, throughput remains constant (i.e. 100 tps), and response time per request increases only linearly (i.e. 10 seconds). 138 Scalability – Add more hardware … Application Application Application Application Application Scale-out: Application replicated on different machines Scale-up: Single application instance is executed on a multiprocessor machine CPU 139 Scalability – reality Adding more hard ware should improve performance: scalability must be achieved without modifications to application architecture Reality as always is different! Applications will exhibit a decrease in throughput and a subsequent exponential increase in response time. increased load causes increased contention for resources such as CPU, network and memory each request consumes some additional resource (buffer space, locks, and so on) in the application, and eventually these are exhausted 140 Scalability – J2EE example 0 500 1000 1500 2000 2500 0 200 400 600 800 1000 1200 No. of Clients TPS WAS SB JBoss SB IAS SB SS SB WLS SB BES SB I.Gorton, A Liu, Performance Evaluation of Alternative Component Architectures for Enterprise JavaBean Applications, in IEEE Internet Computing, vol.7, no. 3, pages 18-23, 2003. 141 Scalability – connections What happens if number of simultaneous connections to an application increases If each connection consumes a resource? Exceed maximum number of connections? ISP example: Each user connection spawned a new process Virtual memory on each server exceeded at 2000 users Needed to support 100Ks of users Tech crash …. 142 Scalability – Data Size How does an application behave as the data it processes increases in size? Chat application sees average message size double? Database table size grows from 1 million to 20 million rows? Image analysis algorithm processes images of 100MB instead of 1MB? Can application/algorithms scale to handle increased data requirements? 143 Scalability – Deployment How does effort to install/deploy an application increase as installation base grows? Install new users? Install new servers? Solutions typically revolve around automatic download/installation E.g. downloading applications from the Internet 144 Scalability thoughts and ICDE Scalability often overlooked. Major cause of application failure Hard to predict Hard to test/validate Reliance on proven designs and technologies is essential For ICDE – application should be capable of handling a peak load of 150 concurrent requests from ICDE clients. Relatively easy to simulate user load to validate this 145 Modifiability Modifications to a software system during its lifetime are a fact of life. Modifiable systems are easier to change/evolve Modifiability should be assessed in context of how a system is likely to change No need to facilitate changes that are highly unlikely to occur Over-engineering! 146 Modifiability Modifiability measures how easy it may be to change an application to cater for new (non-) functional requirements. ‘may’ – nearly always impossible to be certain Must estimate cost/effort Modifiability measures are only relevant in the context of a given architectural solution. Components Relationships Responsibilities 147 Modifiability Scenarios Provide access to the application through firewalls in addition to existing “behind the firewall” access. Incorporate new features for self-service check-out kiosks. The COTS speech recognition software vendor goes out of business and we need to replace this component. The application needs to be ported from Linux to the Microsoft Windows platform. 148 Modifiability Analysis Impact is rarely easy to quantify The best possible is a: Convincing impact analysis of changes needed A demonstration of how the solution can accommodate the modification without change. Minimizing dependencies increases modifiability Changes isolated to single components likely to be less expensive than those that cause ripple effects across the architecture. 149 Modifiability for ICDE The range of events trapped and stored by the ICDE client to be expanded. Third party tools to communicate new message types. Change database technology used Change server technology used 150 Security Difficult, specialized quality attribute: Lots of technology available Requires deep knowledge of approaches and solutions Security is a multi-faceted quality … 151 Security Authentication: Applications can verify the identity of their users and other applications with which they communicate. Authorization: Authenticated users and applications have defined access rights to the resources of the system. Encryption: The messages sent to/from the application are encrypted. Integrity: This ensures the contents of a message are not altered in transit. Non-repudiation: The sender of a message has proof of delivery and the receiver is assured of the sender’s identity. This means neither can subsequently refute their participation in the message exchange. 152 Security Approaches SSL PKI Web Services security JAAS Operating system security Database security Etc etc 153 ICDE Security Requirements Authentication of ICDE users and third party ICDE tools to ICDE server Encryption of data to ICDE server from 3rd party tools/users executing remotely over an insecure network 154 Availability Key requirement for most IT applications Measured by the proportion of the required time it is useable. E.g. 100% available during business hours No more than 2 hours scheduled downtime per week 24x7x52 (100% availability) Related to an application’s reliability Unreliable applications suffer poor availability 155 Availability Period of loss of availability determined by: Time to detect failure Time to correct failure Time to restart application Strategies for high availability: Eliminate single points of failure Replication and failover Automatic detection and restart Recoverability (e.g. a database) the capability to reestablish performance levels and recover affected data after an application or system failure 156 Availability for ICDE Achieve 100% availability during business hours Plenty of scope for downtime for system upgrade, backup and maintenance. Include mechanisms for component replication and failover 157 Integration ease with which an application can be incorporated into a broader application context Use component in ways that the designer did not originally anticipate Typically achieved by: Programmatic APIs Data integration 158 Integration Strategies Data – expose application data for access by other components API – offers services to read/write application data through an abstracted interface Each has strengths and weaknesses … Application Data Third Party Application API Interoperability through an API facade Interoperability achieved by direct data access 159 ICDE Integration Needs Revolve around the need to support third party analysis tools. Well-defined and understood mechanism for third party tools to access data in the ICDE data store. 160 Misc. Quality Attributes Portability Can an application be easily executed on a different software/hardware platform to the one it has been developed for? Testability How easy or difficult is an application to test? Supportability How easy an application is to support once it is deployed? 161 Design Trade-offs QAs are rarely orthogonal They interact, affect each other highly secure system may be difficult to integrate highly available application may trade-off lower performance for greater availability high performance application may be tied to a given platform, and hence not be easily portable Architects must create solutions that makes sensible design compromises not possible to fully satisfy all competing requirements Must satisfy all stakeholder needs This is the difficult bit! 162 Summary QAs are part of an application’s nonfunctional requirements Many QAs Architect must decide which are important for a given application Understand implications for application Understand competing requirements and tradeoffs 163 Software Architecture And Design Session 5: A Guide to Middleware Architectures and Technologies 164 Introduction Middleware is the plumbing or wiring of IT applications Provides applications with fundamental services for distributed computing Insulates applications from underlying platform (OS, DBMS, etc) APIs Lots of middleware exists Different purposes Different vendors Different standards and proprietary technologies 165 Middleware Classification Business Process Orchestrators Message Brokers Application Servers Transport Message-Oriented Middleware, Distributed Objects Systems J2EE, CCM, .NET BizTalk, WebSphere Message Broker, SonicMQ BizTalk, TIBCO StaffWare, ActiveBPEL 166 Outline CORBA Message-oriented middleware J2EE Message brokers Business process orchestrators 167 CORBA Venerable distributed object technology Still widely used in telecomms, defense Many different implementations Network Client Object Reference request Server Servant reply client ORB server ORB 168 CORBA Code Example module ServerExample { interface MyObject { string isAlive(); }; }; class MyServant extends _MyObjectImplBase { public String isAlive() { return “\nLooks like it…\n”; } } ORB orb = ORB.init(args, null); MyServant objRef = new MyServant(); //server process orb.connect(objRef); ————————————————————————————- ORB orb = ORB.init(args, null); // Lookup is a wrapper that actually access the CORBA Naming // Service directory – details omitted for simplicity MyServant servantRef = lookup(“Myservant”) String reply = servantRef.isAlive(); CORBA IDL Server Client 169 CORBA – Some Thoughts Many associated services, eg Naming Notification Transactions Synchronous technology, client-server relatively tightly coupled Remote calls can/will fail State management in server objects creates ‘interesting’ recovery issues 170 Messaging – MOM Basic Message Oriented Middleware (MOM) provides features like: Asynchronous communications between processes, applications and systems Send-and-forget Delivering messages despite failures Transactional Messaging Deliver all messages in a transaction, or none Persistence Messages can be logged at the server and hence survive server failure 171 172 Basic Messaging Send (queue, message) Put message onto queue Receive (queue, message) Get message from queue No dependency on state of receiving application on message send send receive queue 173 Persistence send receive queue Receipt of message at queue implies message is written to disk log Removal of message from queue deletes message from disk log Trade-off performance versus reliability 174 MOM Server MOM Server Sending Applications Senders Message Handler Thread Pool Sending Applications Receivers Peer-to-peer MOM technologies are the alternative design 175 MOM Transactions Begin transaction … update database record put message on queue … commit transaction Begin transaction … get message from queue update database record … commit transaction 176 MOM Transactions Sender and receiver do *not* share a transaction Rollback on receiver does not affect the sender (already committed) ‘Synchronous’ operations are not atomic Request/response is 3 transactions not 1 Put to request queue Get from request queue, put to response queue Get from response queue send receive Request queue Response queue send receive 177 Scaling MOM MOM Server Senders Receivers MOM Server ApplicationQ ApplicationQ 178 Messaging – Some thoughts Highly attractive asynchronous technology Supports loosely-coupled, dynamic applications Scales well, high throughput possible Many implementations, various qualities of service caveat emptor 179 Publish-Subscribe Messaging Extension of MOM to provide 1-to-N, N-to-1, and N-toN communications Messages are ‘published’ to logical subjects or topics Subscribers receive all messages from subjects they subscribe to Pub Subject Sub Sub Sub Create/ Publish Register/ Subscribe 180 Publish-Subscribe with Multicast rvd rvd Publisher Subscriber rvd Subscriber rvd Subscriber rvrd rvd Subscriber rvd Subscriber rvrd Based on TIBCO Rendezvous 181 Performance 0 100 200 300 400 500 600 700 10 20 30 40 50 No. Of Subscribers Milliseconds MC1 MC2 QB 182 Subject/Topic Naming Sydney DevGroup SupportGroup Information Information work gossip work gossip Sydney Sydney/DevGroup Sydney/DevGroup/Information Sydney/DevGroup/Information/work Sydney/DevGroup/Information/gossip Sydney/SupportGroup Sydney/SupportGroup/Information Sydney/SupportGroup/Information/work Sydney/SupportGroup/Information/gossip Sydney/*/Information Sydney/DevGroup/*/* Sydney/DevGroup/** 183 Publish-Subscribe – Some Thoughts Highly decoupled messaging style Publishers don’t know about subscribers Subscribers don’t know who is publishing Publishers and Subscribers can dynamically appear and disappear Issues – Reliability Transactions Security Performance 184 J2EE Overview Browser-based client applications (HTML, applets, DHTML/scripting) Java client applications ERPs, CRMs, Mainframe TP systems Servlets, JSPs Web server HTTP Java RMI Application components EJBs Client tier Web Tier Business Component tier EIS Tier Container Services Components eg. JTS, JMS RDBMS JDBC JCA RMI Windows/COM client applications CAS COM Bridge, RMI over IIOP 185 J2EE Application Server In J2EE, the application server container provides the execution environment for the J2EE-specific components EJBs Message-driven beans Connectors Container provides additional services for hosted components Transactions Security Directory Threading Connection pooling 186 EJB Container Application Server EJB Container Transaction Service Directory Service Security Service Thread Pool Connection Pool Persistence Lifecycle Management EJB Pool 187 Beans and State EJB Container state Stateless bean pool Stateful beans state state state state state state EJB Clients 188 Deployment Descriptors EntityStock.BrokerHome db.entitystock.BrokerHome db.entitystock.Broker db.entitystock.BrokerBean Stateless Container EntityStock.BrokerHome Remote * Required 189 J2EE – Some Thoughts Standards-based, multiple vendors, portable Good open source technology available Quality of implementations varies considerably Java only, wide platform support Performance is good, but varies between suppliers Scalable, fail over support through clustering Good integration with web technologies Supports various design patterns, flexible but more complex (e.g. stateful beans/scalability, entity beans) Standards evolving, need to monitor 190 Message Brokers – Motivation Web Component Legacy System #1 Legacy System #2 Legacy System #3 Legacy System #4 In-format In-format In-format In-format In-format Key: Message = In-format Message Transform Legacyformat API call Queue Read 191 What if … the common In-format message format changes? any legacy system API changes? any of the transformations needs modifying? 192 Alternative Solution Web Component Legacy System #1 Legacy System #2 Legacy System #3 Legacy System #4 In-format L1-format L2-format L3-format L4-format Key: Message = Message Broker Transformations in broker Simplified endpoints Decouples Web and legacy components 193 Message Brokers Developed specifically for Enterprise Application Integration (EAI) Add new layers of functionality to MOM Message transformation Rules engine Intelligent routing Adapters Typically (but not necessarily) built on top of a MOM layer 194 Message Broker Features Message transformation – transform between different source/target formats Graphical message format definition and mapping tools High performance transformation engines Message format repositories Intelligent routing Route messages based on message content Rules Engine Scripting language, built-in functions Application programming environment 195 Message Brokers Transformation Routing Rules Processing Input Messages Output Messages Hub and Spoke Architecture 196 Example – WMQI 197 BizTalk Mapping Tool 198 Adapters An adapter is a component that resides between the message broker and the source/target systems Simplify complexity of end system interface through an abstraction layer Thin adapters – simple wrappers Thick adapters Programmable Abstract representation of services and meta-data Centralized adapters co-located with broker Distributed adapters execute in own process and may be located with source/target system 199 Message Brokers – Some Thoughts Embeds transformations/routing in broker Can get complex Possible scaling issues Need to replicate brokers Failure handling Lightweight, rarely designed to recover from failure Often proprietary technology Good open source, standards-based like Mule now available 200 Business Process Orchestration Commonly known as workflow Aim is to automate business processes which need to access data and business logic across disparate back-end applications Builds on EAI to ensure business processes are executed in the defined order using the required data Builds on middleware providing: Process execution engine Visual process definition tools Process monitoring tools 201 Typical Scenario Business process automation Customer Purchasing SAP Customer Receiving Siebel Sales desk Shipping Credit Validation Accounts Payable Accounts Receivable Oracle 202 Example – BizTalk 203 BPO Architecture Message Broker Adapter Adapter Adapter Business Systems Process State 204 BPEL Web Services standard for describing workflows Many design and execution tools Eg ActiveBPEL Version 2.0 is a significant improvement 205 Integration Issues – Point-to-Point Point-to-Point evolution Spaghetti architecture, hard to modify potentially (N2 -N) interfaces 1 business process = 4 interfaces 5 business processes = 20 interfaces 206 Broker Spaghetti No free lunch … Just relocates the spaghetti message broker 207 Enterprise Data Model Source sends message to target with common message format as payload. Target receives message and transforms common format into its own local data representation. 2xN transformations, no broker needed Getting agreement is the tough bit … Enterprise Data Model 208 Summary Middleware: makes building complex, distributed, concurrent applications simpler. institutionalizes proven design practices by supporting them in off-the-shelf middleware technologies. Architect’s job is to ‘mix n’match’ technologies to create appropriate solutions Analyze trade-offs Open-minded (no hammer/nail thinking) No good/evil, its just technology 209 Software Architecture And Design Session6: A Software Architecture Process 210 A Software Architecture Process Architects must be versatile: Work with the requirements team: The architect plays an important role in requirements gathering by understanding the overall systems needs and ensuring that the appropriate quality attributes are explicit and understood. Work with various application stakeholders: Architects play a pivotal liaison role by making sure all the application’s stakeholder needs are understood and incorporated into the design. Lead the technical design team: Defining the application architecture is a design activity. Work with the project management: Planning, estimates, budgets, schedules 211 An Architecture Process Highly iterative Can scale to small/large projects Determine Architectural Requirements Architecture Design Validation 212 Determine Architectural Requirements Sometime called: architecturally significant requirements architecture use cases essentially the quality and non-functional requirements for a system. Functional Requirements Stakeholder Requirements Architecture Requirements Determine Architecture Requirements 213 Examples A typical architecture requirement : “Communications between components must be guaranteed to succeed with no message loss” Some architecture requirements are constraints: “The system must use the existing IIS-based web server and use Active Server Page to process web requests” Constraints impose restrictions on the architecture and are (almost always) non-negotiable. They limit the range of design choices an architect can make. 214 Quality Attribute Requirements Quality Attribute Architecture Requirement Performance Application performance must provide sub-four second response times for 90% of requests. Security All communications must be authenticated and encrypted using certificates. Resource Management The server component must run on a low end office-based server with 512MB memory. Usability The user interface component must run in an Internet browser to support remote users. Availability The system must run 24x7x365, with overall availability of 0.99. Reliability No message loss is allowed, and all message delivery outcomes must be known with 30 seconds Scalability The application must be able to handle a peak load of 500 concurrent users during the enrollment period. Modifiability The architecture must support a phased migration from the current Forth Generation Language (4GL) version to a .NET systems technology solution. 215 Constraints Constraint Architecture Requirement Business The technology must run as a plug-in for MS BizTalk, as we want to sell this to Microsoft. Development The system must be written in Java so that we can use existing development staff. Schedule The first version of this product must be delivered within six months. Business We want to work closely with and get more development funding from MegaHugeTech Corp, so we need to use their technology in our application. 216 Priorities All requirements are not equal High: the application must support this requirement. Medium: this requirement will need to be supported at some stage Low: this is part of the requirements wish list. Tricky in face of conflicts, eg: Reusability of components in the solution versus rapid time-to-market. Making components generalized and reusable always takes more time and effort. Minimal expenditure on COTS products versus reduced development effort/cost. COTS products mean you have to develop less code, but they cost money. It’s design – not meant to be easy! 217 Architecture Design Design steps are iterative Risk identification is a crucial output of the design Architecture Requirements Architecture Views Choose Architecture Framework Allocate Components Architecture Document 218 Choosing the Architecture Framework Choose a architecture pattern/patterns that suit requirements No magic formula Analyze requirements and quality attributes supported by each pattern Complex architectures require creative blending of multiple patterns. 219 N-Tier Client Server Pattern Separation of concerns: Presentation, business and data handling logic are clearly partitioned in different tiers. Synchronous communications: Communications between tiers is synchronous request-reply. Each tier waits for a response from the other tier before proceeding. Flexible deployment: There are no restrictions on how a multi-tier application is deployed. All tiers could run on the same machine, or each tier may be deployed on its own machine. Databases Application Server Web Server Web Client Web Client Web Client Client Tier Web Server Tier Business Logic Tier Data Management Tier 220 N-Tier Client Server – Quality Attribute Analysis Quality Attribute Issues Availability Servers in each tier can be replicated, so that if one fails, others remain available. Overall the application will provide a lower quality of service until the failed server is restored. Failure handling If a client is communicating with a server that fails, most web and application servers implement transparent failover. This means a client request is, without its knowledge, redirected to a live replica server that can satisfy the request. Modifiability Separation of concerns enhances modifiability, as the presentation, business and data management logic are all clearly encapsulated. Each can have its internal logic modified in many cases without changes rippling into other tiers. Performance This architecture has proven high performance. Key issues to consider are the amount of concurrent threads supported in each server, the speed of connections between tiers and the amount of data that is transferred. As always with distributed systems, it makes sense to minimize the calls needed between tiers to fulfill each request. Scalability As servers in each tier can be replicated, and multiple server instances run on the same or different servers, the architecture scales out and up well. In practice, the data management tier often becomes a bottleneck on the capacity of a system. 221 Messaging Pattern Asynchronous communications: Clients send requests to the queue, where the message is stored until an application removes it. Configurable QoS: The queue can be configured for high-speed, non-reliable or slower, reliable delivery. Queue operations can be coordinated with database transactions. Loose coupling: There is no direct binding between clients and servers. Server Server Client Client Client Que ue Server 222 Messaging – Quality Attribute Analysis Quality Attribute Issues Availability Physical queues with the same logical name can be replicated across different messaging server instances. When one fails, clients can send messages to replica queues. Failure handling If a client is communicating with a queue that fails, it can find a replica queue and post the message there. Modifiability Messaging is inherently loosely coupled, and this promotes high modifiability as clients and servers are not directly bound through an interface. Changes to the format of messages sent by clients may cause changes to the server implementations. Self-describing, discoverable message formats can help reduce this dependency on message formats. Performance Message queuing technology can deliver thousands of messages per second. Nonreliable messaging is faster than reliable, with the different dependent of the quality of the messaging technology used. Scalability Queues can be hosted on the communicating endpoints, or be replicated across clusters of messaging servers hosted on a single or multiple server machines. This makes messaging a highly scalable solution. 223 Publish-Subscribe Pattern Many-to-Many messaging: Published messages are sent to all subscribers who are registered with the topic. Configurable QoS: In addition to non-reliable and reliable messaging, the underlying communication mechanism may be point-topoint or broadcast/multicast. Loose Coupling: As with messaging, there is no direct binding between publishers and subscribers. Subscriber Publisher Subscriber Subscriber Topic 224 Publish-Subscribe – Quality Attribute Analysis Quality Attribute Issues Availability Topics with the same logical name can be replicated across different server instances managed as a cluster. When one fails, publishers send messages to replica queues. Failure handling If a publisher is communicating with a topic hosted by a server that fails, it can find a live replica server and send the message there. Modifiability Publish-subscribe is inherently loosely coupled, and this promotes high modifiability. New publishers and subscribers can be added to the system without change to the architecture or configuration. Changes to the format of messages published may cause changes to the subscriber implementations. Performance Publish-subscribe can deliver thousands of messages per second, with nonreliable messaging faster than reliable. If a publish-subscribe broker supports multicast/broadcast, it will deliver multiple messages in a more uniform time to each subscriber. Scalability Topics can be replicated across clusters of servers hosted on a single or multiple server machines. Clusters of server can scale to provide very high message volume throughput. Also, multicast/broadcast solutions scale better than their point-to-point counterparts. 225 Broker Pattern Hub-and-spoke architecture: The broker acts as a messaging hub, and senders and receivers connect as spokes. Performs message routing: The broker embeds processing logic to deliver a message received on an input port to an output port. Performs message transformation: The broker logic transforms the source message type received on the input port to the destination message type required on the output port. Receiver-2 Sender-1 Receiver-1 Broker Sender-2 inPort1 inPort2 OutPort1 OutPort2 226 Broker Pattern – Quality Attribute Analysis Quality Attribute Issues Availability To build high availability architectures, brokers must be replicated. This is typically supported using similar mechanisms to messaging and publish-subscribe server clustering. Failure handling As brokers have typed input ports, they validate and discard any messages that are sent in the wrong format. With replicated brokers, senders can fail over to a live broker should one of the replicas fail. Modifiability Brokers separate the transformation and message routing logic from the senders and receivers. This enhances modifiability, as changes to transformation and routing logic can be made without affecting senders or receivers. Performance Brokers can potentially become a bottleneck, especially if they must service high message volumes and execute complex transformation logic. Their throughput is typically lower than simple messaging with reliable delivery. Scalability Clustering broker instances makes it possible to construct systems scale to handle high request loads. 227 Process Coordinator Pattern Process encapsulation: The process coordinator encapsulates the sequence of steps needed to fulfill the business process. The sequence can be arbitrarily complex. Loose coupling: The server components are unaware of their role in the overall business process, and of the order of the steps in the process. Flexible communications: Communications between the coordinator and servers can be synchronous or asynchronous. Server-2 Server-3 Server-4 Process Coordinator Server-1 step1 step2 step3 step4 Start process request Process results 228 Process Coordinator – Quality Attribute Analysis Quality Attribute Issues Availability The coordinator is a single point of failure. Hence it needs to be replicated to create a high availability solution. Failure handling Failure handling is complex, as it can occur at any stage in the business process coordination. Failure of a later step in the process may require earlier steps to be undone using compensating transactions. Handling failures needs careful design to ensure the data maintained by the servers remains consistent. Modifiability Process modifiability is enhanced because the process definition is encapsulated in the coordinator process. Servers can change their implementation without affecting the coordinator or other servers, as long as their external service definition doesn’t change. Performance To achieve high performance, the coordinator must be able to handle multiple concurrent requests and manage the state of each as they progress through the process. Also, the performance of any process will be limited by the slowest step, namely the slowest server in the process. Scalability The coordinator can be replicated to scale the application both up and out. 229 Allocate Components Need to: Identify the major application components, and how they plug into the framework. Identify the interface or services that each component supports. Identify the responsibilities of the component, stating what it can be relied upon to do when it receives a request. Identify dependencies between components. Identify partitions in the architecture that are candidates for distribution over servers in a network And independent development 230 Some Design Guidelines Minimize dependencies between components. Strive for a loosely coupled solution in which changes to one component do not ripple through the architecture, propagating across many components. Remember, every time you change something, you have to retest it. Design components that encapsulate a highly “cohesive” set of responsibilities. Cohesion is a measure of how well the parts of a component fit together. Isolate dependencies on middleware and any COTS infrastructure technologies. Use decomposition to structure components hierarchically. Minimize calls between components, as these can prove costly if the components are distributed. 231 A Simple Design Example Validate OrderInput read New Orders OrderQ Store Customer System Order System SendEmail Email Server Write Order Check Order Write Order Get Order Figure Key Existing Component New Component Dependency Database Persistent Queue Error Log 232 Example Design Based on messaging Application components are: OrderInput: responsible for accessing the new orders database, encapsulating the order processing logic, and writing to the queue. Validate: encapsulates the responsibility of interacting with the customer system to carry out validation, and writing to the error logs if an order is invalid. Store: responsibility of interacting with the order system to store the order data. SendEmail: removes a message from the queue, formats an email message and sends it via an email server. It encapsulates all knowledge of the email format and email server access. Clear responsibilities and dependencies 233 Architecture Validation Aim of the validation phase is to increase confidence of the design team that the architecture is fit for purpose. The validation has to be achieved within the project constraints of time and budget The trick is to be as rigorous and efficient as possible. Validating an architecture design poses tough challenges. ‘coz it’s a design that can’t be executed or tested consists of new and COTS components that have to be integrated Two main techniques: 1. manual testing of the architecture using test scenarios. 2. construction of a prototype that creates a simple archetype of the desired application aim of both is to identify potential flaws in the design so that they can be improved before implementation commences. Cheaper to fix before built 234 The ATAM SEI has developed the Architecture Tradeoff Analysis Method (ATAM) over several years. The purpose of ATAM is: to assess the consequences of architectural decision alternatives in light of quality attribute requirements. 235 Generate Quality Attribute Utility Tree Identify, prioritize, and refine the most important quality attribute goals by building a utility tree. • A utility tree is a top-down vehicle for characterizing the “driving” attribute-specific requirements • Select the most important quality goals to be the high-level nodes(typically performance, modifiability, security, and availability) • Scenarios are the leaves of the utility tree Output: a characterization and a prioritization of specific quality attribute requirements. High/Medium/Low importance for the success of the system High/Medium/Low difficulty to achieve (architect’s assessment) 236 Quality Attribute Utility Tree Construction -1 237 Quality Attribute Utility Tree Construction -2 238 Scenarios Scenarios are used to • Represent stakeholders’ interests • Understand quality attribute requirements Scenarios should cover a range of • Anticipated uses of (use case scenarios), • Anticipated changes to (growth scenarios), or • Unanticipated stresses (exploratory scenarios) to the system. A good scenario makes clear what the stimulus is that causes it and what responses are of interest. 239 Example Scenarios Use case scenario Remote user requests a database report via the Web during peak period and receives it within 5 seconds. Growth scenario Add a new data server to reduce latency in scenario 1 to 2.5 seconds within 1 person-week. Exploratory scenario Half of the servers go down during normal operation without affecting overall system availability. => Scenarios should be as specific as possible. 240 241 Scenarios Part of SEI’s ATAM work Involves defining: some kind of stimulus that will have an impact on the architecture. working out how the architecture responds to this stimulus. If the response is desirable, then a scenario is deemed to be satisfied by the architecture. If the response is undesirable, or hard to quantify, then a flaw or at least an area of risk in the architecture may have been uncovered. 242 Scenario Examples Quality Attribute Stimulus Response Availability The network connection to the message consumers fails. Messages are stored on the MOM server until the connection is restored. Messages will only be lost if the server fails before the connection comes back up. Modifiability A new set of data analysis components must be made available in the application. The application needs to be rebuilt with the new libraries, and the all configuration files must be updated on every desktop to make the new components visible in the GUI toolbox. Security No requests are received on a user session for ten minutes. The system treats this session as potentially insecure and invalidates the security credentials associated with the session. The user must logon again to connect to the application. Modifiability The supplier of the transformation engine goes out of business. A new transformation engine must be purchased. The abstract service layer that wraps the transformation engine component must be reimplemented to support the new engine. Client components are unaffected as they only use the abstract service layer. Scalability The concurrent user request load doubles during the 3 week enrollment period. The application server is scaled out on a two machine cluster to handle the increased request load. 243 Scenarios for Order Processing Example Quality Attribute Stimulus Response Modifiability The Customer System packaged application is updated to an Oracle database. The Validate component must be rewritten to interface to the Oracle system. Availability The email server fails. Messages build up in the OrderQ until the email server restarts. Messages are then sent by the SendEmail component to remove the backlog. Order processing is not affected. Reliability The Customer or Order systems are unavailable. If either fails, order processing halts and alerts are sent to system administrators so that the problem can be fixed. Needs fixing …. 244 Prototyping Scenarios can’t address everything: “On Friday afternoon, orders must be processed before closeof-business to ensure delivery by Monday. Five thousand orders arrive through various channels (Web/Call centre/business partners) five minutes before close-ofbusiness.” Only one way – build something! Proof-of-concept prototype: Can the architecture as designed be built in a way that can satisfy the requirements? Proof-of-technology prototype : Does the technology (middleware, integrated applications, libraries, etc) selected to implement the application behave as expected? 245 Prototyping Strategy Build minimal system required to validate architecture, eg: An existing application shows that the queue and email systems are capable of supporting five thousand messages in five minutes So: Write a test program that calls the Customer System validation APIs five thousand times, and time how long this takes. Write a test program that calls the Order System store APIs five thousand times, and time how long this takes. 246 Prototyping Thoughts Prototypes should be used judiciously to help reduce the risks inherent in a design. Only way to address: Performance Scalability Ease of integration Capabilities of off-the-shelf components Need to be carefully scoped and managed. Ideally take a day or two, a week or two at most. Usually thrown-away so keep them cheap Don’t let them acquire a life of their own 247 Summary 3 step, iterative architecture design process Can be customized to small/meduim/large projects Agnostic to overall process framework (ie RUP, agile, waterfall, etc) 248 Software Architecture And Design Session 7: Documenting a Software Architecture 249 Architecture Documentation Architecture documentation is a thorny issue Commonly there is no documentation covering the architecture. If it is, it’s out-of-date, inappropriate and basically not very useful. Also projects that have masses of architecture related information Sometimes invaluable, but often it’s out-of-date, inappropriate and not very useful! 250 Documenting an Architecture is good! Others can understand/evaluate the design. We can understand the design after a period of time. Others in the project team and development organization can learn from the architecture. We can do analysis on the design, perhaps to assess its likely performance, or to generate standard metrics. 251 But it’s difficult … No universally accepted architecture documentation standard. An architecture can be complex, and documenting it in a comprehensible manner is time consuming and non-trivial. An architecture has many possible views. Documenting all the potentially useful ones is time consuming and expensive. An architecture design often evolves Keeping the architecture documents current is often forgotten, especially with time and schedule pressures in a project. 252 Think carefully about what to document Project complexity A small project may only need a ‘marketecture’ Project longevity One-off stop gap software? Strategic, long-term, will evolve? Needs of stakeholders Small team, a whiteboard might be ok Large, dislocated team needs more Integrators? Testers? Programmers? Need to spend documentation dollars/euros wisely on high value products 253 UML 2.0 UML is a powerful way to document an architecture Provides a relatively formal, unambiguous description New features in UML 2.0 appropriate for architectures Good tools available, some free Can be used to depict various structural/behavioral architecture views 254 Component Diagram id Component View OrderProcessing MailQueue SendEmail MailServer OrderSystem CustomerSystem OrderQueue «table» NewOrders 1 validate 1 readQ 1 writeQ 1 read 1 send 1 1 readQ 1 1 writeQ 1 255 Class Diagram cd OrderProcessing OrderReader Validate Store QueueWriter 1 1 1 1 1 1 256 Sequence Diagram sd Interactions OrderReader MailQueue Validate OrderQueue Store QueueWriter NewOrders CustomerSystem readOrderData success:= validateOrder success:= newOrder success:= storeOrder success:= writeQueue success:= acknowledgeOrderSuccess success:= writeQueue 257 Deployment Diagram dd Deployment View OrdersDB OrderServer «executable» : OrderProcessing «table» :NewOrders MOMServer :MailQueue :OrderQueue MailServer :MailServer OrderSystem CustomerSystem «executable» : CustomerSystem «executable» : OrderSystem :SendEmail CRM ERP SOAP JDBC 258 Component Interfaces id Component View OrderProcessing MailQueue SendEmail MailServer OrderSystem CustomerSystem OrderQueue «table» NewOrders JDBC SMTP QueueRead QueueRead QueueWrite CustomerServices QueueWrite 259 Component Decomposition id Component View OrderProcessing validateOrder getOrders writeConfirmation writeOrder MailQueue SendEmail MailServer OrderSystem CustomerSystem validate ProvidedInterface1 OrderQueue «table» NewOrders JDBC QueueWrite QueueWrite CustomerServices SMTP QueueRead QueueRead cd Component View OrderProcessing getOrders validateOrder writeConfirmation writeOrder or: OrderReader val: Validate qw: QueueWriter st: Store «delegate» «delegate» «delegate» «delegate» 260 Document Template Documentation is easier if there’s a template to use Reduces start-up time for projects by providing ready-made document structures familiarity gained with the document structure aids in the efficient capture of project design details. help with the training of new staff 261 Template Headings Architecture Documentation Template Project Name: XXX 1 Project Context 2 Architecture Requirements 2.1 Overview of Key Objectives 2.2 Architecture Use Cases 2.3 Stakeholder Architectural Requirements 2.4 Constraints 2.5 Non-functional Requirements 2.6 Risks 3 Solution 3.1 Relevant Architectural Patterns 3.2 Architecture Overview 3.3 Structural Views 3.4 Behavioral Views 3.5 Implementation Issues 4 Architecture Analysis 4.1 Scenario analysis 4.2 Risks 262 Summary Some documentation is nearly always a good idea Trick is to produce ‘just enough’ and no more requires upfront planning and thinking Commitment to keeps docs current UML 2.0 makes architecture documentation easier Some good UML 2.0 tools, try ‘em out. 263 Software Architecture And Design Session 8: ICDE Case Study Design 264 Chapter 2: Case Study Context ICDE version 1.0 in production Basically a complex, raw information capture tool, GUI for looking at captured data 2 tier client-server, single machine deployment Java, Perl, SQL, Programmatic access to data through very complex SQL (38 tables, 46 views) 265 Architecturally Significant Requirements for ICDE v2.0 ICDE project requirements: Heterogeneous platform support for access to ICDE data Instantaneous event notification (local/distributed) Over the Internet, secure ICDE data access Ease of programmatic data access ICDE Project team requirements: Insulate 3rd party projects and ICDE tools from database evolution Reliability for multi-tool ICDE deployments Scalable infrastructure to support large, shared deployments Minimize license costs for a deployment Unknowns Minimize dependencies, making unanticipated changes potentially easier 266 Chapter 7: The Solution Problem with version 1 SELECT * FROM VeryBigTable Moving to a multi-user distributed n-tier environment Reduces licence costs, support costs, and hardware requirements on the client side Scalability with database connection pooling 267 Chapter 7: The Solution Must consider Database performance Thrashing and middle tier fall over. Performance – memory usage in middle tier Notification: of user actions and new event instances Could use database triggers, but vendor specific. Allow users to create event categories on demand. Data abstraction Tools may run on separate hardware to end-user session. 268 Chapter 7: API Issues Must provide a set of query interfaces ApplicationData myData[] = getApplicationEvents(SID, APPS_OPEN_EVENT,NULL) Where NULL = all applications Must provide a set of store interfaces Ok = write(myData, myClassifier, PUBLISH, myTopic) Easy to learn, support location transparency, be resilient to change. 269 Chapter 7: The Solution Objective for version 2 Provide a programming interface for 3rd party analytical tools to access the ICDE datastore. Scalable architecture so that it can support 100-150 users See ESA chapter 7 for: Architectural use cases. Stakeholder architectural requirements. Constraints. NFRs. Risks. 270 Chapter 7: The Solution Relevant architectural patterns Three tier Publish-subscribe Layered Both client and middle tier employ layering. Uses a page-by-page iterator design pattern to limit amount of data returned from a query SELECT TOP * (PAGESIZE) FROM X WHERE (a AND b AND c) Middle tier is EJB stateless session beans Java Messaging Service (JMS) 271 Chapter 7: The Solution ICDE API Architecture 272 ICDE API Architecture as component diagram perspective 273 ICDE Data Collection Components 274 ICDE Deployment Diagram 275 Sequence diagram for ICDE Query API use case 276 Sequence diagram for ICDE Write use case 277 Sequence diagram for the ICDE Storing User Generated Events use case
