Motivation Using Design Patterns and Frameworks to Develop Developing ecient, robust, extensible, portable, and reusable communication software is Object-Oriented Communication hard Systems It is essential to understand successful tech- niques that have proven e ective to solve Douglas C. Schmidt common development challenges www.cs.wustl.edu/schmidt/ Design patterns and frameworks help to [email protected] capture, articulate, and instantiate these Washington University, St. Louis successful techniques 2 1 Observations Design Patterns Develop ers of communication software con- front recurring challenges that are largely Design patterns represent solutions to prob- application-indep endent lems that arise when developing software within a particular context { e.g., service initialization and distribution, error handling, ow control, event demultiplexing, { i.e., \Patterns == problem/solution pairs in a concurrency control context" Patterns capture the static and dynamic Successful develop ers resolve these chal- structure and collab oration among key par- lenges by applying appropriate design pat- ticipants in software designs terns { They are particularly useful for articulating how and why to resolve non-functional forces However, these patterns have traditionally b een either: Patterns facilitate reuse of successful soft- 1. Lo cked inside heads of exp ert develop ers ware architectures and designs 2. Buried in source co de 3 4 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 object that controls access to it 5 6 Frameworks A framework is: More Observations { \An integrated collection of comp onents that collab orate to pro duce a reusable architecture Reuse of patterns alone is not sucient for a family of related applications" { Patterns enable reuse of architecture and de- sign knowledge, but not co de directly Frameworks di er from conventional class libraries: 1. Frameworks are \semi-complete" applications To be pro ductive, develop ers must also reuse detailed designs, algorithms, inter- 2. Frameworks address particular application do- mains faces, implementations, 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 Tutorial Outline Di erences Between Class Libraries and Frameworks Outline key challenges for developing com- NETWORKING software APPLICATION munication SPECIFIC LOGIC INVOKES MATH ADTS Present the key reusable design patterns framework comp onents in high-p erformance EVENT USER and eb clients and servers DATA W LOOP INTERFACE BASE { Both single-threaded and various multi-threaded are presented (A) CLASS LIBRARY solutions ARCHITECTURE { The patterns and frameworks covered general- ize to other communication software systems NETWORKING USER MATH e.g., ORBs, video-on-demand, medical imag- INTERFACE APPLICATION ing CALL INVOKES SPECIFIC BACKS LOGIC EVENT LOOP Discuss lessons learned from using pat- ADTS and frameworks on pro duction soft- DATABASE terns ware systems (B) APPLICATION FRAMEWORK e.g., telecom, avionics, medical systems ARCHITECTURE { 10 9 Concurrency vs. Parallelism Stand-alone vs. Distributed Application Architectures SERVER PRINTER maxfdp1 read_fds COMPUTER CLIENT WORK FILE REQUEST CD ROM SYSTEM WORK WORK WORK CLIENT REQUEST REQUEST REQUEST (1) STAND-ALONE APPLICATION ARCHITECTURE CLIENT CLIENT TIME CONCURRENT SERVER NAME SERVICE CYCLE SERVICE SERVICE SERVER DISPLAY SERVICE CPU1 CPU2 CPU3 CPU4 FI LE CLIENT NETWORK SERVICE WORK REQUEST PRINT SERVICE WORK WORK WORK CD ROM CLIENT REQUEST REQUEST REQUEST PRINTER FILE SYSTEM CLIENT CLIENT (2) PARALLEL SERVER DISTRIBUTED APPLICATION ARCHITECTURE 11 12 Sources of Complexity Sources of Complexity cont'd Distributed application development exhibits b oth inherent and accidental complexity Accidental complexity results from limita- tions with to ols and techniques, e.g., Inherent complexity results from funda- mental 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 de- Race conditions veloping large-scale distributed applications Deadlo ck avoidance { Continuous rediscovery and reinvention of core concepts and comp onents Fair scheduling Performance optimization and tuning 14 13 OO Contributions Concurrent Web Client/Server Example Communication software has traditionally b een p erformed using low-level OS mech- anisms, e.g., The following example illustrates a con- { fork/exec current OO architecture for a high-p erformance { Shared memory Web client/server { Signals Key system requirements are: { So ckets and select 1. Robust implementation of HTTP proto col { POSIX pthreads, Solaris threads, Win32 threads { i.e., resilient to incorrect or malicious Web clients/servers OO design patterns and frameworks ele- vate fo cus to application concerns, e.g., 2. Extensible for use with other proto cols { Service functionality and p olicies { e.g., DICOM, HTTP 1.1, SFP { Service con guration 3. Leverage multi-pro cessor hardware and OS soft- { Concurrent event demultiplexing and event han- ware dler dispatching { e.g., Supp ort various concurrency mo dels { Service concurrency and synchronization 16 15 Web Server Software Architecture General Web Client/Server Interactions HTTP HTTP Handler Handler 1: GET ~schmidt WWW HTTP/1.0 WWW Sock Sock HTTP Stream Stream CLIENT SERVER Handler 2: index.html HTTP Sock Acceptor PROTOCOL Stream HTML HANDLERS Event Sock PARSER Dispatcher Acceptor GUI DISPATCHER REQUESTER Event Dispatcher GRAPHICS COMMUNICATION PROTOCOL Encapsulates Web server concurrency and dis- ADAPTER (E.G., HTTP) { patching strategies HTTP Handlers OS KERNEL OS KERNEL Parses HTTP headers and pro cesses requests OS I/O SUBSYSTEM OS I/O SUBSYSTEM { HTTP Acceptor NETWORK ADAPTERS NETWORK ADAPTERS NETWORK { Accepts connections and creates HTTP Han- dlers 17 18 Tactical Patterns Design Patterns in the Web Server Implementation Proxy { \Provide a surrogate or placeholder for another to control access to it" Thread object Thread-per Acceptor Request Pool Strategy Active Connector \De ne a family of algorithms, encapsulate each Object { and make them interchangeable" Thread-per one, Session Service Adapter Half-Sync/ Configurator \Convert the interface of a class into another Half-Async { client exp ects" Asynchronous interface Completion Reactor/ Double Checked Singleton Token Proactor Locking \Ensure a class only has one instance and pro- STRATEGIC PATTERNS { vide a global p oint of access to it" TACTICAL PATTERNS Abstract State State Strategy Adapter Singleton Factory { \Allow an object to alter its b ehavior when its internal state changes" 20 19 Concurrency Patterns Event Handling Patterns Active Object Reactor { \Decouples metho d execution from metho d in- vo cation and simpli es synchronized access to { \Decouples synchronous event demultiplexing shared resources by concurrent threads" and event handler initiation dispatching from services p erformed in resp onse to events" Half-Sync/Half-Async Proactor { \Decouples synchronous I/O from asynchronous I/O in a system to simplify concurrent pro- { \Decouples asynchronous event demultiplexing gramming e ort without degrading execution and event handler completion dispatching from eciency" services p erformed in resp onse to events" Double-Checked Lo cking Optimization Pat- Asynchronous Completion Token tern { \Eciently asso ciates state with the comple- { \Ensures atomic initialization of objects and tion of asynchronous op erations" eliminates unnecessary lo cking overhead on each access" 21 22 Concurrency Architecture Service Initialization Patterns Patterns Connector Thread-p er-Request { \Decouples active connection establishment from the service p erformed once the connection is { \Allows each client request to run concurrently established" in a separate thread" Acceptor Thread Pool { \Decouples passive connection establishment { \Allows up to N requests to execute concur- from the service p erformed once the connec- rently within a pool of threads " tion is established" Thread-p er-Connection Service Con gurator { \Allows each client connection to run concur- { \Decouples the b ehavior of network services rently" from p oint in time at which services are con- gured into an application" Suited for HTTP 1.1, but not HTTP 1.0 23 24 Alternative Web Server Selecting the Server's Concurrency Patterns Concurrency Architecture Problem The following example illustrates the de- sign patterns and framework comp onents { A very strategic design decision for high-p erformance Web servers is selecting an ecient concur- in an OO implementation of a concurrent rency architecture Web Server The following are the key concurrency pat- Forces tern alternatives: { No single concurrency architecture is optimal 1. Reactive { Key factors include