Скачать презентацию E 81 CSE 532 S Advanced Multi-Paradigm Software Скачать презентацию E 81 CSE 532 S Advanced Multi-Paradigm Software

57c709ed94da24731b2c6c3446786d1e.ppt

  • Количество слайдов: 12

E 81 CSE 532 S: Advanced Multi-Paradigm Software Development Event Handling Pattern Languages Chris E 81 CSE 532 S: Advanced Multi-Paradigm Software Development Event Handling Pattern Languages Chris Gill Department of Computer Science and Engineering Washington University, St. Louis [email protected] wustl. edu Thanks to Carol Brickman for raising the UDP and simulation server issues covered here Thanks to Doug Schmidt for timer expiration example (ace-users post)

Review: What is a Pattern Language? • A narrative that composes patterns – Not Review: What is a Pattern Language? • A narrative that composes patterns – Not just a catalog of the patterns – Reconciles design forces among patterns – Provides an ordered outline for design steps • Not necessarily a procedure (details may be unspecified) • A generator for a complete design – Patterns may leave consequences – Other patterns can resolve them – Generative designs resolve all forces • Internal tensions don’t “pull design apart”

Pattern Language I: Logging Server • Want to collect and record system events – Pattern Language I: Logging Server • Want to collect and record system events – For example, printer out of paper, new clients, etc. • Events from many clients to a central server • Want to add event-specific processing – And add new processing flexibly From http: //www. cs. wustl. edu/~schmidt/patterns-ace. html

Pattern Language I: Logging Server Reactor Handler • Design forces – Server needs to Pattern Language I: Logging Server Reactor Handler • Design forces – Server needs to add/remove logging features dynamically – Logging actions are short lived, and event driven • Solution – Apply Reactor to manage registration and dispatching • Consequences – Need a way to match events to particular logging actions

Pattern Language I: Logging Server ACT Reactor Handler ACT • Design forces – Need Pattern Language I: Logging Server ACT Reactor Handler ACT • Design forces – Need a way to match events to particular logging actions – Clients can specify what events they will report • Solution – Apply ACT to identify the kinds of handlers to create • Consequences – Need to define how ACT is handled – Need to create correct handlers for the ACT

Pattern Language I: Logging Server ACT Acceptor ACT Reactor Handler ACT Connector • Design Pattern Language I: Logging Server ACT Acceptor ACT Reactor Handler ACT Connector • Design forces – Need to define how ACT is handled – Need to create correct handlers for the ACT – Clients (dynamic) need to tell server when they join • Solution – Apply Acceptor/Connector with server taking passive role and clients taking active role in connection establishment • Consequences – Reactive logging with dynamic connection establishment and dynamic identification/creation of events/handlers

Pattern Language I: Logging Server • One subtle design/implementation issue remains – How to Pattern Language I: Logging Server • One subtle design/implementation issue remains – How to pass ACT to acceptor so it knows what kind of handler to create? • Could use the new socket for additional handshaking between the connector and the acceptor – Like in lab 0 where client and server exchanged names – However, this lengthens the time spent in acceptor upcall • Another option – Acceptor binds a separate UDP port – Client connectors can “mail” it ACTs via UDP – Need to add retry, etc. above UDP level (see Stevens UNP)

( ) Pattern Language II: Simulation Server • Scripted simulation server (physics, avionics, etc. ( ) Pattern Language II: Simulation Server • Scripted simulation server (physics, avionics, etc. ) – Each simulation has (possibly distinct) set of clients – Clients may observe, provide control actions, inputs, etc. – Similar to previous pattern language, except last pattern

Pattern Language II: Simulation Server Listening port Client 1 Server Listening port Client 2 Pattern Language II: Simulation Server Listening port Client 1 Server Listening port Client 2 • Design forces – Clients are static and passive (known set of simulation components) – Server is dynamic and active (runs different simulation scenarios) – Server (dynamic) needs to tell clients when to start, reset, run, etc. • Solution – Apply Acceptor/Connector with clients taking passive role and server taking active role in connection establishment (reverse of lab 1 roles) • Consequences – Similarly reactive simulation but with dynamic connection establishment triggered by server

Pattern Language II: Simulation Server data structure Code that schedules Timer ACT Handler Timer Pattern Language II: Simulation Server data structure Code that schedules Timer ACT Handler Timer Queue • Design forces – Simulation client or server logic may need to respond to passage of time – Reactor can dispatch handlers when timers expire – How can application pass data to handler, and vice versa? • Solution – Apply ACT pattern (pass address: schedule call’s timer_act parameter); • Consequences – Arbitrary data structure can pass between application and handler – Creates a critical section (access to data structure) if multi-threaded

( ) Pattern Language III: Data Streams • Want to coordinate groups of different ( ) Pattern Language III: Data Streams • Want to coordinate groups of different data streams – For example, display multiple streams consistently locally • Water temperatures and flow rates across a river basin • Video frames from multiple cameras tracking an animal • Poker hands dealt from multiple games at once – Also, may pass-through streams to other endsystems • Apply ACT to identify each stream’s source, id, etc. – Lets end-user switch among streams transiting endsystem – Lets end-user buffer/write related messages together • Need high throughput for content rich data streams – Apply Proactor to manage registration and dispatching • Need to update streaming topology dynamically – Apply Acceptor/Connector to set up remote connections – May involve both active and passive roles on an endsystem

Concluding Remarks • A single pattern is often insufficient – May leave unresolved design Concluding Remarks • A single pattern is often insufficient – May leave unresolved design consequences • Understand how patterns fit together – How one may reconcile forces from another … – … and/or leave/introduce un-reconciled forces • Successful pattern languages in a context can generate complete designs – Weave patterns together coherently • There are many more pattern languages than patterns (cardinality argument)