Architectural Tactics and Patterns + An architectural pattern is + is a package of design decisions that is found repeatedly in practice, + has known properties that permit reuse, and + describes a class of architectures + Patterns are found in practice, not invented, they are discovered. * There will never be a complete list of patterns. Patterns spontaneously emerge in reaction of environmental conditions, and as long as those conditions change, new patterns will emerge. * Architectural design seldom starts from first principles. Experienced architects typically think of creating an architecture as process of selecting, tailoring, and combining patterns + Patterns package tactics. Most of patterns consists of (are constructed from) several different tactics. Tactics are building blocks of design from which architectural patterns are created. * Multiple patterns can be used in architecture design of a complex systemArchitectural Tactics and Patterns Description of an architectural pattern: * Context: a recurring, common situation that gives rise to a problem. * Problem: a generalized problem that arises in the given context, including * problem outline and its variants + complementary or opposing forces + quality attributes that must be met + Solution: abstract description of the architectural structures that solve the problem by balancing many forces at work. * a set of element types (e.g. data repositories, processes, and objects) * a set of interaction mechanisms or connectors (e.g. method calls, events, and message bus)Module Patterns Layered Pattern * Context: to develop and evolve portions of the system independently * Problem: modules can be developed and evolved separately with little interaction among the parts, supporting portability, modifiability, and reuse. + Solution A Key: Layer c A layers allowed to use the next lower layer FIGURE 13.1 Stack-of-boxes notation for layered designsLayered Pattern Module Patterns * Context: to develop and evolve portions of the system independently + Problem: modules can be developed and evolved separately with little interaction among the parts, supporting portability, modifiability, and reuse. + Solution TABLE 13.1 Layered Pattern Solution Overview Elements Relations Constraints Weaknesses ‘The layered pattern defines layers (groupings of modules that offer a cohesive set of services) and a unidirectional allowed-to-use relation among the layers. The patter is usually shown graphically by stacking boxes representing layers on top of each other. Layer, a kind of module. The description of a layer should define what modules the layer contains and a characterization of the cohesive set of services that the layer provides. Allowed to use, which is a specialization of a more generic depends-on relation. The design should define what the layer usage rules are (e.9., ‘a layer is allowed to use any lower layer” or ‘a layer is allowed to use only the layer immediately below it") and any allowable exceptions. * Every piece of software is allocated to exactly one layer. * There are at least two layers (but usually there are three or more). "The allowed-to-use relations should not be circular (i.e., a lower layer cannot use a layer above). * The addition of layers adds up-front cost and complexity to a system. = Layers contribute a performance penalty.Module Patterns Layered Pattern * Context: to develop and evolve portions of the system independently + Problem: modules can be developed and evolved separately with little interaction among the parts, supporting portability, modifiability, and reuse. + Solution Applications Sonicos Data Bank Envronmertal Models Securty Environment Sensing Ke: aM toe 08 and Haraware teens FIGURE 13.2 A simple layer diagram, with a simple key answering the uses questionModule Patterns Layered Pattern * Context: to develop and evolve portions of the system independently + Problem: modules can be developed and evolved separately with little interaction among the parts, supporting portability, modifiability, and reuse. + Solution Key: Layer OF De > —> Allowed to use FIGURE 13.3 A wolf in layer's clothingModule Patterns Layered Pattern * Context: to develop and evolve portions of the system independently + Problem: modules can be developed and evolved separately with little interaction among the parts, supporting portability, modifiability, and reuse. + Solution Ul 1 Business Logic ———— Key: | ee Data Access Layer Local Data Remote Data segment ‘Access Access —+ Allowed to use FIGURE 13.5 Layered design with segmented layersComponent-and-Connector Patterns Broker Pattern + Context: implementing systems with collaborative services: interoperation, connection, information exchange, and service availability. * Problem: How to structure distributed software so that service users do not need to know the nature and location of service providers, to make it easy to dynamically change the bindings between users and providers. * Solution TABLE 13.2 Broker Pattern Solution Overview The broker pattern defines a runtime component, called a broker, that mediates the communication between a number of clients and servers. Elements Client, a requester of services Server, a provider of services Broker, an intermediary that locates an appropriate server to fulfil a client's request, forwards the request to the server, and returns the results to the client Client-side proxy, an intermediary that manages the actual ‘communication with the broker, iaciuding marshaling, sending, and tUnmarshaling of messages ‘Server-side proxy, an intermediary that manages the actual communication with the broker, including marshaling, sending, and tUnmarshaling of messages Relations The attachment relation associates clionts (and, optionally, client-side proxies) and servers (and, optionally, server-side proxies) with brokers. Constraints The cllent can only attach to a broker (potentially via a olient-side proxy). The server can only attach to @ broker (potentially via a server- Eide proxy) Weaknesses Brokers add a layer of indirection, and hence latency, between clients and servers, and that layer may be a communication bottleneck. ‘The broker can be a single point of failure. A broker adds up-front complexity. ‘A broker may be a target for security attacks. A broker may be difficult to test.Component-and-Connector Patterns Broker Pattern + Context: implementing systems with collaborative services information exchange, and service availability. * Problem: How to structure distributed software so that service users do not need to know the nature and location of service providers, to make it easy to dynamically change the bindings between users and providers. * Solution interoperation, connection, stranefers* 1 Broker 1 ranctors + [Client-Side Proxy) { emasenerp : ‘Server-Side Proxy | ocateciienty) pack aatag registerserverg ripack data Jsunpack datad) [sunregistorServar | |sunpack data() [seend request) Hteallservice) rotund) cca | 1 {send response() ot + | cat 4 | cat -uses| Bridge . Server Client , |=packdatat) uses foi {reall server [Panpackdata() [Center_main_toop() stat task [Storware message) erin service) [Suse _Broker_APIO [stransmit_message() [ruee Broker APIO FIGURE 13.6 The broker patternComponent-and-Connector Patterns Model-View-Controller (MVC) Pattern + Context: for interactive GUI based systems, to keep modifications to the user interface separate from the rest of the system, and support multiple or alternative views of computing results or current state of data. + Problem: + How can user interface functionality ne kept separate from application functionality and still be responsive to user input, or changes in the underlying application’s data? * How can multiple views of user interface be created, maintained, and coordinated when the underlying application data changes? + Solution Peete FIGURE 13.7 The model-view-controlier patternComponent-and-Connector Patterns Model-View-Controller (MVC) Pattern + Solution TABLE 13.3 Model-View-Controller Pattern Solution Overview Elements Relations Constraints Weaknesses The MVC pattern breaks system functionality into three components: a model, a view, and a controller that mediates between the model and the view. The modefis a representation of the application data or state, and it contains (or provides an interface to) application logic. The viewis a user interface component that either produces a representation of the model for the user or allows for some form of user input, or both. The controller manages the interaction between the model and the view, translating user actions into changes to the model or changes to the view. The notifies relation connects instances of model, view, and controller, notifying elements of relevant state changes. There must be at least one instance each of model, view, and controller. The model component should not interact directly with the controller. The complexity may not be worth it for simple user interfaces. The model, view, and controller abstractions may not be good fits for some user interface toolkits.Component-and-Connector Patterns Pipe-and-Filter Pattern + Context: transform streams of data items from input to output, using reusable component: + Problem: divide a system into reusable, loosely coupled components with simple, generic interaction mechanisms with flexible and dynamic combination of such reusable components, also support parallel executions of components * Solution [eapacty=40 eapacty=4SSCS«SN ‘ond-of data = empty record lend-of-data = empty record ‘when full = blook for 2 sec and retry wher ful = block for 2 ee and retry when-empty = block for 30sec and retry when-empty = blook for 30 sec and retry «titers 2) fitern ©) Sh ‘Calculate yf "Format DirectDeposit |

" | DirectDeposit iter 2 FormatRejected *EOT" Sting Records lack for 2 sec and retry \when-empiy = block for 20 sec and retry when full = black for 2 see and retry hen-ompty = block for 60 sac and retry FIGURE 13.8 A UML diagram of a pipe-and-filter-based systemComponent-and-Connector Patterns TABLE 13.4 Pipe-and-Filter Pattern Solution Pipe-and-Filter Pattern + Solution Overview Elements Relations Constraints. Weaknesses Data is transformed from a system's external inputs to its external outputs through a series of transformations performed by its filters connected by pipes. Filter, which is a component that transforms data read on its input port(s) to data written on its output port(s). Filters can execute concurrently with each other. Filters can incrementally transform data; that is, they can start producing output as soon as they start processing input. Important characteristics include processing rates, input/output data formats, and the transformation executed by the filter. Pipe, which is a connector that conveys data from a filter’s output port(s) to another filter’s input port(s). A pipe has a single source for its input and a single target for its output. A pipe preserves the sequence of data items, and it does not alter the data passing through. Important characteristics include buffer size, protocol of interaction, transmission speed, and format of the data that passes. through a pipe. ‘The attachment relation associates the output of filters with the input of pipes and vice versa. Pipes connect filter output ports to filter input ports. Connected filters must agree on the type of data being passed along the connecting pipe. Specializations of the pattern may restrict the association of components to an acyclic graph or a linear sequence, sometimes called a pipeline. Other specializations may prescribe that components have certain named ports, such as the stdin, stdout, and stderr ports of UNIX filters. ‘The pipe-and-filter pattern is typically not a good choice for an interactive system. Having large numbers of independent filters can add substantial amounts of computational overhead, Pipe-and-filter systems may not be appropriate for long-running computations.Component-and-Connector Patterns Client-Server Pattern + Context: There are shared resources and services that large numbers of distributed clients wish to access, and for which we wish to control access or quality of service. + Problem: + for modifiability and reuse, factor out common services and modify them in a single location or small number of locations. * for scalability and availability, centralize the control of these resources and services while distributing the resources themselves across multiple physical servers. * Solution Bank AT™ AT™ transaction monitoring reconfiguration ‘Guthorizer Server Server Monitoring Station Fieconfigure and update | process program, Key: “er cocker connestor with hone Sonet cliont and server pores ea Ex a=. FIGURE 13.9 The client-server architecture of an ATM banking systemComponent-and-Connector Patterns Client-Server Pattern + Solution TABLE 13.5 Client-Server Pattern Solution Overview Elements Relations Constraints Weaknesses Clients initiate interactions with servers, invoking services as needed from those servers and waiting for the results of those requests. Client, a component that invokes services of a server component. Clients have ports that describe the services they require. Server, a component that provides services to clients. Servers have ports that describe the services they provide, Important characteristics include intormation about the nature of the server ports (such as how many clients can connect) and performance characteristics (e.g., maximum rates of service invocation) Request/reply connector, a data connector employing a request/reply protocol, used by a client to invoke services on a server. Important characteristics include whether the calls are local or remote, and whether data is encrypted. The attachment relation associates clients with servers. Clients are connected to servers through request/reply connectors. ‘Server components can be clients to other servers. Specializations may impose restrictions: = Numbers of attachments to a given port + Allowed relations among servers Components may be arranged in tiers, which are logical groupings of related functionality or functionality that will share @ host computing environment (covered more later in this chapter). Server can be a performance bottleneck. Server can be a single point of failure. Decisions about where to locate functionality (in the client or in the server) are often complex and costly to change after a system has been built.Component-and-Connector Patterns Peer-to-Peer Pattern + Context: Distributed computing entities with independent resources need to cooperate and collaborate to provide a service to a distributed community of users. + Problem: How can a set of “equal” distributed computing entities be connected to each other via a common protocol, so that they can organize and share their services with high availability and scalability? * Solution — ‘ moldy 69.95.6349 naboo 15766 24.26 — “ Key!) teat poor im ruta port Utrapecr @--@ Requestepiy using Gnutella protocol over TCP or UDP HTTP fie tranctor FIGURE 13.10 A peer-to-peer view of a Gnutella network using an Informal C&C. notation. For brevity, only @ few peers are identified. Each of the identified leaf peers uploads and downloads files directly from other peers.+ Solution Component-and-Connector Patterns Peer-to-Peer Pattern TABLE 13.6 Peer-to-Peer Pattern Solution Overview Elements Relations Constraints Weaknesses Computation is achieved by cooperating peers that request service from and provide services to one another across a network Peer, which is an independent component running on a network node. Special peer components can provide routing, indexing, and peer search capability Request/reply connector, which is used to connect to the peer network, search for other peers, and invoke services from other peers. In some cases, the need for a reply is done away with The relation associates peers with their connectors. Attachments may change at runtime. Restrictions may be placed on the following: "The number of allowable attachments to any given peer = The number of hops used for searching for a peer = Which peers know about which other peers ‘Some P2P networks are organized with star topologies, in which peers only connect to supernodes Managing security, data consistency, data/service availability, backup, and recovery are all more complex. Small peer-to-peer systems may not be able to consistently achieve quality goals such as performance and availability.Component-and-Connector Patterns Service-Oriented Architecture Pattern + Context: A number of services are offered (and described) by service providers and consumed by service consumers. Service consumers need to be able to understand and use these services without any detailed knowledge of their implementation. + Problem: + To support interoperability of distributed components running on different platforms and written in different implementation languages, provided by different organizations, and distributed across the internet. * To locate services and combine (and dynamically recombine) them into meaningful coalitions while achieving reasonable performance, security, and availability. * Solution fey Chae —> imPnres peen Seni —> wal ‘ppeaten — dense [a Eee sever "1 — Wensenees| a ooo S| | plot pa ‘ai be =l acampeet soy FIGURE 13:11 Diagram ofthe SOA view for the Adventure Buder system, OPC stands or"Order Processing Cente”Component-and-Connector Patterns Service-Oriented Architecture Pattern + Solution TABLE 137 Service-Oriented Architecture Pattern Solution Overview __Computationis achieved by ast of cooperating components that provide and/or consume services over a network. The computatonis often desorived usin a workow language, Elements ‘Components: ‘Service providers, which provide one or more services through published interfaces. Concems are often tied to the chosen implementation technology, and include perfor. mance, authorization constants, avaiablty, and cost. In some cases these properties ae specifiedin a service-level yatnng agreement Service consumers, which invoke services directly or through anintermeciary. ‘Service providers may aso be sarvice consumers. ESB, which is an intermediary element that can route and ‘transform messages between service providers and consum- as, Weaknesses "Registry of services, which may be used by providers to register tei services and by consumers to discover senvioes atruntime. Orchestration server, which coordinates the interactions between senice consumers and providers based on languages for business processes and wordfons. Connectors: "SOAP connector, whch uses the SOAP protocol fo ‘synchronous communication between webservices, tpicaly ver HTTP, "REST connector which relies onthe basic requesteg\y pertions ofthe HTTP protocol "Asynchronous messaging connector, which uses & ‘messaging system to fet point-o-point or pubish-subserbe asynchronous message exchanges ‘Atachment ofthe diferent kinds of components avalabe to the respective comectrs ‘Service consumers are connected to service providers, but intermediary components (2.9, ESB, registry, orcheshaton server maybe used. ‘S0A-tased systems are typically complex io buid ‘Youdor’tcontl he evolution of independent serves. ‘Thete sa performance overiead associated wit he middleware, and services may be performance botnets, and ‘ypicaly do not provide perormance guarantees,Component-and-Connector Patterns Publish-Subscript Pattern + Context: There are a number of independent producers and consumers of data that must interact. The precise number and nature of the data producers and consumers are not predetermined or fixed, nor is the data that they share. * Problem: To create integration mechanisms that support the ability to transmit messages among the producers and consumers in such a way that they are unaware if each other’s identity, or potentially even their existence. * Solution Register Bee (a - — 5 of reat he , ss sips Ul evnt manager Uren, [TT ection pa mre Sew Ltacace) seem” Key: Be @8e" Ose — hehe Component Map instance /| Co = on | | Oaks FIGURE 13.14 A component-and-connector view of map-reduce showing how the data processed by map is partitioned and subsequently processed by reduceAllocation/C&C Patterns Map-Reduce Pattern Solution Map-Reduce Pattern * Solution TABLE 13.10 Overview Elements, Relations Constraints Weaknesses ‘The map-reduce pattern provides a framework for analyzing a large distributed set of data that will execute in parallel, on a set of processors. This parallelization allows for low latency and high availability. The map performs the extract and transform portions of the analysis and the reduce performs the /oading of the results. (Extract-transform-load is sometimes used to describe the functions of the map and reduce.) Maps a function with multiple instances deployed across multiple processors that performs the extract and transformation portions of the analysis. Reduce is a function that may be deployed as a single instance or as multiple instances across processors to perform the load portion of extract-transform-load, The infrastructure is the framework responsible for deploying map and reduce instances, shepherding the data between them, and detecting and recovering from failure. Deploy onis the relation between an instance of a map or reduce function and the processor onto which it is installed. Instantiate, monitor, and controls the relation between the infrastructure and the instances of map and reduce. The data to be analyzed must exist as a set of files. ‘The map functions are stateless and do not communicate with each other. The only communication between the map instances and the reduce instances is the data emitted from the map instances as pairs. If you do not have large data sets, the overhead of map-reduce is not justified. If you cannot divide your data set into similar sized subsets, the advantages of parallelism are lost. Operations that require multiple reduces are complex to orchestrate.