Motivation Design Patterns and Frameworks for Object-oriente d Developing ecient, robust, extensible, and Communicatio n Systems reusable communication software is hard It is essential to understand successful tech- Douglas C. Schmidt niques that have proven e ective to solve common development challenges http://www.cs.wustl.ed u/s chmi dt/ Design patterns and frameworks help to cap- [email protected] u ture, articulate, and instantiate these suc- cessful techniques Washington University, St. Louis 1 2 Observations Design Patterns Develop ers of communication software con- Design patterns represent solutions to prob- front recurring challenges that are largely lems that arise when developing software application-indep endent within a particular context { e.g., service initialization and distribution, error { i.e.,\Patterns == problem/solution pairs in a con- handling, ow control, event demultiplexing, con- text" currency control Patterns capture the static and dynamic struc- Successful develop ers resolve these challenges ture and collab oration among key partici- pants in software designs by applying appropriate design patterns { They are particularly useful for articulating how and why to resolve non-functional forces However, these patterns have traditionally b een either: 1. Lo cked inside heads of exp ert develop ers Patterns facilitate reuse of successful soft- ware architectures and designs 2. Buried in source co de 4 3 Proxy Pattern Graphical Notation 1: METHOD : BROKER CALL : QUOTER 4: METHOD OBJECT PROXY RETURN PROCESS : CLASS 2: FORWARD THREAD REQUEST 3: RESPONSE CLASS CLIENT CLASS TEMPLATE UTILITY : QUOTER CLASS NETWORK CLASS CATEGORY INHERITS INSTANTIATES SERVER ABSTRACT CLASS A CONTAINS USES Intent: provide a surrogate for another ob- ject that controls access to it 5 6 Frameworks A framework is: More Observations { \An integrated collection of comp onents that col- lab orate to pro duce a reusable architecture for a Reuse of patterns alone is not sucient family of related applications" { Patterns enable reuse of architecture and design knowledge, but not co de directly Frameworks di er from conventional class libraries: 1. Frameworks are \semi-complete" applications Tobepro ductive, develop ers must also reuse detailed designs, algorithms, interfaces, im- 2. Frameworks address a particular application do- main plementations, etc. 3. Frameworks provide \inversion of control" Application frameworks are an e ective way to achieve broad reuse of software Typically, applications are develop ed by in- heriting from and instantiating framework comp onents 7 8 Di erences Between Class Libraries and Frameworks Tutorial Outline APPLICATION NETWORKING SPECIFIC LOGIC INVOKES MATH ADTS Outline key challenges for developing com- software EVENT USER munication DATA LOOP INTERFACE BASE Present the key reusable design patterns in CLASS distributed medical imaging system LIBRARIES a { Both single-threaded and multi-threaded solutions are presented NETWORKING MATH USER INTERFACE APPLICATION CALL INVOKES SPECIFIC Discuss lessons learned from using patterns BACKS LOGIC EVENT LOOP on pro duction software systems ADTS DATABASE OBJECT-ORIENTED FRAMEWORK 9 10 Concurrency vs. Parallelism Stand-alone vs. Distribut ed Application Architectures SERVER PRINTER maxfdp1 read_fds COMPUTER CLIENT WORK REQUEST FILE CD ROM SYSTEM WORK WORK WORK CLIENT REQUEST REQUEST REQUEST (1) STAND-ALONE APPLICATION ARCHITECTURE CLIENT CLIENT DISPLAY CYCLE CONCURRENT SERVER SERVICE SERVICES FI LE SERVER SERVICE CPU1 CPU2 CPU3 CPU4 PRINT NETWORK SERVICE CLIENT WORK REQUEST PRINTER CD ROM FILE SYSTEM WORK WORK WORK CLIENT REQUEST REQUEST REQUEST (2) DISTRIBUTED APPLICATION ARCHITECTURE CLIENT CLIENT PARALLEL SERVER 11 12 Sources of Complexity Sources of Complexity cont'd Distributed application development exhibits b oth inherent and accidental complexity Accidental complexity results from limi ta- tions with to ols and techniques, e.g., Inherent complexity results from fundamen- tal challenges, e.g., { Low-level to ols { Distributed systems . e.g., Lack of typ e-secure, portable, re-entrant, and extensible system call interfaces and com- . Latency p onent libraries . Error handling { Inadequate debugging supp ort . Service partitioning and load balancing { Widespread use of algorithmic decomp osition { Concurrent systems . Fine for explaining network programming con- cepts and algorithms but inadequate for devel- . Race conditions oping large-scale distributed applications . Deadlo ck avoidance { Continuous rediscovery and reinvention of core con- cepts and comp onents . Fair scheduling . Performance optimization and tuning 13 14 OO Contributio ns Concurrent and distributed programming has Distributed Medical Imaging traditionally b een p erformed using low-level OS mechanisms, e.g., Example { fork/exec { Shared memory This example illustrates the reusable design { Signals patterns and framework comp onents used in an OO architecture foradistributed medical { So ckets and select imaging system { POSIX pthreads, Solaris threads, Win32 threads Application clients uses Blob Servers to store OO design patterns and frameworks elevate development to fo cus on application con- and retrieve medical images cerns, e.g., { Service functionality and p olicies Clients and Servers communicate via a connection- oriented transp ort proto col { Service con guration { e.g., TCP/IP, IPX/SPX, TP4 { Concurrent event demultiplexing and event han- dler dispatching { Service concurrency and synchronization 16 15 Distributed Electronic Medical Architecture of the Blob Server Imaging Architecture BLOB SERVER MODALITIES LOCAL (CT, MR, CR) STORE svc_run svc_run svc_run svc_run ATM LAN DIAGNOSTIC STATIONS : Blob : Msg NAME Queue : Options SERVER Processor ATM ATM : Blob : Blob : Blob LAN MAN ROUTING Handler Handler Handler SERVICE : Blob Acceptor : Reactor CLUSTER TIME STORE SERVER LOCATIONLOCATION SERVICESERVICE CENTRAL STORE MODALITIES (CT, MR, CR) * Manage short-term and long-term blob p ersistence * Resp ond to queries from Blob Lo cators 17 18 Tactical Patterns Design Patterns in the Blob Server Proxy { \Provide a surrogate or placeholder for another Thread-per object to control access to it" Thread-per Session Request Acceptor Strategy Active Object Thread \De ne a family of algorithms, encapsulate each Pool Connector { one, and make them interchangeable" Half-Sync/ Service Half-Async Adapter Configurator \Convert the interface of a class into another in- STRATEGIC Double Checked { Reactor terface client exp ects" PATTERNS Locking TACTICAL Singleton PATTERNS Proxy Strategy Adapter Singleton { \Ensure a class only has one instance and provide a global p oint of access to it" 20 19 Concurrency Patterns Reactor Concurrency Architecture { \Decouples event demultiplexing and event han- dler dispatching from application services p erformed Patterns in resp onse to events" Thread-p er-Request Active Object { \Allows each client request to run concurrently" { \Decouples metho d execution from metho d invo- cation and simpli es synchronized access to shared resources by concurrent threads" Thread-Pool Half-Sync/Half-Async { \Allows up to N requests to execute concurrently" { \Decouples synchronous I/O from asynchronous I/O in a system to simplify concurrent program- ming e ort without degrading execution eciency" Thread-p er-Session { \Allows each client session to run concurrently" Double-Checked Lo cking Pattern { \Ensures atomic initialization of objects and elim- inates unnecessary lo cking overhead on each ac- cess" 22 21 Concurrency Patterns in the Blob Service Initializati on Patterns Server Connector { \Decouples active connection establishment from The following example illustrates the design the service p erformed once the connection is es- patterns and framework comp onents in an tablished" OO implementation of a concurrent Blob Server Acceptor There are various architectural patterns for { \Decouples passive connection establishment from structuring concurrency in a Blob Server the service p erformed once the connection is es- tablished" 1. Reactive 2. Thread-p er-request Service Con gurator 3. Thread-p er-session { \Decouples the b ehavior of network services from p oint in time at which services are con gured into an application" 4. Thread-p o ol 24 23 Thread-p er-Req ues t Blob Server Reactive Blob Server Architecture Architecture 2: HANDLE INPUT BLOB SERVER 3: CREATE PROCESSOR BLOB SERVER 2: HANDLE INPUT 4: ACCEPT CONNECTION 3: CREATE PROCESSOR : Blob 5: ACTIVATE PROCESSOR : Blob 4: ACCEPT CONNECTION Processor Processor 5: SPAWN THREAD : Blob : Blob Acceptor Processor : Blob : Blob Acceptor : Blob Processor Processor : Reactor : Reactor 6: PROCESS BLOB REQUEST 6: PROCESS BLOB REQUEST SERVER 1: CONNECT 1: CONNECT SERVER CLIENT CLIENT CLIENT CLIENT CLIENT CLIENT 25 26 Thread-Pool Blob Server Thread-p er-Sess ion Blob Server Architecture Architecture BLOB SERVER : Msg 2: HANDLE INPUT BLOB SERVER : Blob Queue 2: CREATE, ACCEPT, Processor 3: ENQUEUE REQUEST AND ACTIVATE 3: SPAWN THREAD worker BLOB_PROCESSOR : Blob thread : Blob : Blob Handler : Blob : Blob : Blob 5: DEQUEUE & Handler Processor Processor : Blob Processor Acceptor worker PROCESS Handler thread REQUEST : Blob : Reactor Acceptor worker worker thread thread : Reactor 4: PROCESS BLOB REQUEST 6: PROCESS BLOB REQUEST 1: BIND SERVER CLIENT 1: BLOB REQUEST SERVER CLIENT CLIENT CLIENT CLIENT CLIENT 27 28 The ADAPTIVE Communication The Reactor Pattern Environment ACE Intent