1. Pattern-Oriented Software Architectures Patterns & Frameworks for Concurrent & Distributed Systems Dr. Douglas C. Schmidt [email_address] www.dre.vanderbilt.edu/~schmidt/ Professor of EECS Vanderbilt University Nashville, Tennessee
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26. Taxonomy of Patterns & Idioms Active Object, Bridge, Proxy, Wrapper Façade, & Visitor Capture the static & dynamic roles & relationships in solutions that occur repeatedly Design patterns Half-Sync/Half-Async, Layers, Proactor, Publisher-Subscriber, & Reactor Express a fundamental structural organization for software systems that provide a set of predefined subsystems, specify their relationships, & include the rules & guidelines for organizing the relationships between them Architectural patterns Optimize for common case, pass information between layers Document rules for avoiding common design & implementation mistakes that degrade performance Optimization principle patterns Scoped locking Restricted to a particular language, system, or tool Idioms Examples Description Type
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43. Comparing Class Libraries, Frameworks, & Components Class Libraries Frameworks Macro-level Meso-level Micro-level Borrow caller’s thread Inversion of control Borrow caller’s thread Domain-specific or Domain-independent Domain-specific Domain-independent Stand-alone composition entities “ Semi-complete” applications Stand-alone language entities Components Class Library Architecture ADTs Strings Locks IPC Math LOCAL INVOCATIONS APPLICATION- SPECIFIC FUNCTIONALITY EVENT LOOP GLUE CODE Files GUI A class is a unit of abstraction & implementation in an OO programming language Framework Architecture ADTs Locks Strings Files INVOKES A framework is an integrated set of classes that collaborate to produce a reusable architecture for a family of applications Reactor GUI DATABASE NETWORKING APPLICATION-SPECIFIC FUNCTIONALITY CALLBACKS Middleware Bus Component Architecture A component is an encapsulation unit with one or more interfaces that provide clients with access to its services Naming Locking Logging Events
44.
45.
46.
47. Key Capabilities Provided by ACE Service Access & Control Event Handling Concurrency Synchronization
48.
49. POSA2 Pattern Abstracts Service Access & Configuration Patterns The Wrapper Facade design pattern encapsulates the functions & data provided by existing non-object-oriented APIs within more concise, robust, portable, maintainable, & cohesive object-oriented class interfaces. The Component Configurator design pattern allows an application to link & unlink its component implementations at run-time without having to modify, recompile, or statically relink the application. Component Configurator further supports the reconfiguration of components into different application processes without having to shut down & re-start running processes. The Interceptor architectural pattern allows services to be added transparently to a framework & triggered automatically when certain events occur. The Extension Interface design pattern allows multiple interfaces to be exported by a component, to prevent bloating of interfaces & breaking of client code when developers extend or modify the functionality of the component. Event Handling Patterns The Reactor architectural pattern allows event-driven applications to demultiplex & dispatch service requests that are delivered to an application from one or more clients. The Proactor architectural pattern allows event-driven applications to efficiently demultiplex & dispatch service requests triggered by the completion of asynchronous operations, to achieve the performance benefits of concurrency without incurring certain of its liabilities. The Asynchronous Completion Token design pattern allows an application to demultiplex & process efficiently the responses of asynchronous operations it invokes on services. The Acceptor-Connector design pattern decouples the connection & initialization of cooperating peer services in a networked system from the processing performed by the peer services after they are connected & initialized.
50. POSA2 Pattern Abstracts (cont’d) Synchronization Patterns The Scoped Locking C++ idiom ensures that a lock is acquired when control enters a scope & released automatically when control leaves the scope, regardless of the return path from the scope. The Strategized Lockin g design pattern parameterizes synchronization mechanisms that protect a component’s critical sections from concurrent access. The Thread-Safe Interface design pattern minimizes locking overhead & ensures that intra-component method calls do not incur ‘self-deadlock’ by trying to reacquire a lock that is held by the component already. The Double-Checked Locking Optimization design pattern reduces contention & synchronization overhead whenever critical sections of code must acquire locks in a thread-safe manner just once during program execution. Concurrency Patterns The Active Object design pattern decouples method execution from method invocation to enhance concurrency & simplify synchronized access to objects that reside in their own threads of control. The Monitor Object design pattern synchronizes concurrent method execution to ensure that only one method at a time runs within an object. It also allows an object’s methods to cooperatively schedule their execution sequences. The Half-Sync/Half-Async architectural pattern decouples asynchronous & synchronous service processing in concurrent systems, to simplify programming without unduly reducing performance. The pattern introduces two intercommunicating layers, one for asynchronous & one for synchronous service processing. The Leader/Followers architectural pattern provides an efficient concurrency model where multiple threads take turns sharing a set of event sources in order to detect, demultiplex, dispatch, & process service requests that occur on the event sources. The Thread-Specific Storage design pattern allows multiple threads to use one ‘logically global’ access point to retrieve an object that is local to a thread, without incurring locking overhead on each object access.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79. Broker Pattern Dynamics method (proxy) locate_server server port send_request marshal unmarshal dispatch method (impl.) result marshal receive_reply unmarshal result start_up register_service : Broker : Client Proxy : Server Proxy : Client : Server assigned port Broker middleware generates the necessary client & server proxies from higher level interface definitions Proxy Generator Proxy Code Interface Specif.
80.
81.
82.
83.
84. Messaging Pattern Dynamics : Client : Message create store Message forward Message : Message Processor create receive receive Message Message exec send Message : Message API : Local Queue : Remote Queue : Message API Reply store forward Reply recv Reply send Reply recv Other processing
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116. Reconfiguring an Image Server Image servers can also be reconfigured dynamically to support new components & new component implementations IDLE RUNNING SUSPENDED CONFIGURE init() RECONFIGURE init() fini() fini() resume() suspend() EXECUTE run_component() SUSPEND RESUME TERMINATE TERMINATE Reconfiguration State Chart LRU File Cache Image Server # Configure an image server. dynamic File_Cache Component * img_server.dll:make_File_Cache() "-t LRU" INITIAL CONFIGURATION AFTER RECONFIGURATION LFU File Cache Image Server # Reconfigure an image server. remove File_Cache dynamic File_Cache Component * img_server.dll:make_File_Cache() "-t LFU"