1. Track 1: Summary Slides for POSA2 Patterns and Frameworks Distributed Real-Time Systems (TI-DRTS) Version: 14-12-2009

2. Slide 2 © Ingeniørhøjskolen i Århus DRTS Course Model POSA2 Patterns ACE/TAO/JAWS Frameworks General DRTS Theory POSA Pattern Exercises Medico DRTS Project Track 1 Track 2 Track 3 exercises

3. Slide 3 © Ingeniørhøjskolen i Århus POSA2 Pattern Categorization 1.Event Handling Patterns 2.Service Access and Configuration Patterns 3.Concurrency Patterns 4.Synchronization Patterns

4. Slide 4 © Ingeniørhøjskolen i Århus The POSA2 Pattern Language

5. Slide 5 © Ingeniørhøjskolen i Århus Wrapper Façade Abstract The Wrapper Facade Design Pattern encapsulates the functions and data provided by existing non-object-oriented APIs within more concise, robust, portable, maintainable, and cohesive object-oriented class interfaces

6. Slide 6 © Ingeniørhøjskolen i Århus Wrapper Façade Structure Application calls methods calls API FunctionA() calls API FunctionB() calls API FunctionC() void methodN(){ functionA(); } void method1(){ functionA(); } functionB(); Wrapper Facade data method1() … methodN()

7. Slide 7 © Ingeniørhøjskolen i Århus Reactor Abstract The Reactor Architectural Pattern allows event-driven applications to demultiplex & dispatch service requests that are delivered to an application from one or more clients

8. Slide 8 © Ingeniørhøjskolen i Århus Reactor Pattern – Structure Synchronous Event Demultiplexer +select() * 1 «uses» EventHandler + handle_event() + get_handle() Concrete EventHandlerA + handle_events() + register_handler() + remove_handler() Concrete EventHandlerB handle_event() get_handle() Handle owns Reactor handle_event() get_handle() 1 1 dispatches * 1 * 1 Application «creates»

9. Slide 9 © Ingeniørhøjskolen i Århus Reactor – Sequence Diagram Observations Note inversion of control Also note how long-running event handlers can degrade the QoS since callbacks steal the reactor’s thread! 1.Initialize phase 2.Event handling phase

10. Slide 10 © Ingeniørhøjskolen i Århus Acceptor-Connector Abstract The Acceptor-Connector Design Pattern decouples the connection and initialization of cooperating peer services in a networked system from the processing performed by the peer services after they are connected and initialized

11. Slide 11 © Ingeniørhøjskolen i Århus Acceptor/Connector Structure owns * uses > owns uses owns > * * * * * uses > Connector Connector() connect() complete() handle_event () Concrete Service Handler B Concrete Service Handler A Concrete Acceptor Concrete Connector Acceptor Acceptor() accept() handle_event () peer_acceptor_ Service Handler open() handle_event () set_handle() peer_stream_ Dispatcher +select() +handle_events() +register_handler() +remove_handler() Transport Handle Transport Handle Transport Handle > * 1 1 1 1 1 1 * 1

12. Slide 12 © Ingeniørhøjskolen i Århus Acceptor Dynamics : Application: Acceptor : Dispatcher register_handler() handle_events() open() ACCEPT_ EVENT Handle1Acceptor 1. Passive-mode endpoint initialize phase 1. handle_event() service() 3. Service processing phase 3. Event

13. Slide 13 © Ingeniørhøjskolen i Århus Proactor Abstract The Proactor Architectural Pattern allows event-driven applications to efficiently demultiplex and dispatch service requests triggered by the completion of asynchronous operations, to achieve the performance benefits of concurrency without incurring certain of its liabilities

14. Slide 14 © Ingeniørhøjskolen i Århus Proactor Structure Completion Handler Concrete Completion Handler handle_event() Proactor handle_events() Asynchronous Event Demuxer get_completion_event() Asynchronous Operation Processor execute_async_operation() Completion Event Queue Asynchronous Operation async_operation() Handle «dequeues» «enqueues» «executes» «demultiplexes & dispatches» * 11 1 1 1 1 Initiator «uses»

15. Slide 15 © Ingeniørhøjskolen i Århus Proactor Dynamics Completion Handler Completion :Asynchronous Operation : Proactor :Concrete Completion Handler exec_async_ :Asynchronous Operation Processor async_operation() Ev. Queue operation () :Completion Event Queue 1.Initiate operation 2.Process operation Result completion event 4. Generate & queue completion event 3. Run event loop handle_events() Result event Result handle_ service() event() 5. Dequeue completion event & perform completion processing :Initiator

16. Slide 16 © Ingeniørhøjskolen i Århus Asynchronous Completion Token Abstract The Asynchronous Completion Token (ACT) Design Pattern allows an application to demultiplex and process efficiently the responses of asynchronous operations it invokes on services

17. Slide 17 © Ingeniørhøjskolen i Århus ACT Structure Asynchronous Completion Token 0..* Initiator completion_action() 0..* Service async_operation() calls operations 1 1 1 Completion Handler +handle_event() 1..* «uses» «demultiplexes»

18. Slide 18 © Ingeniørhøjskolen i Århus ACT Dynamic :Initiator :Completion Handler :Service operation() ACT notify() ACTresult completion_action() handle_event() result :ACT «create»

19. Slide 19 © Ingeniørhøjskolen i Århus Half-Sync/Half-Async Abstract The Half-Sync/Half-Async Architectural Pattern decouples asynchronous and synchronous service processing in concurrent systems, to simplify programming without unduly reducing performance The pattern introduces two intercommunicating layers, one for asynchronous and one for synchronous service processing

20. Slide 20 © Ingeniørhøjskolen i Århus Half-Sync/Half-Async Structure «dequeue/enqueue» Queue «read/write» Queueing Layer Async Service External Event Source «interrupt» Asynchronous Service Layer Sync Service 1 Sync Service 2 Sync Service 3 Synchronous Service Layer

21. Slide 21 © Ingeniørhøjskolen i Århus Half-Sync/Half-Async Dynamics : External Event Source : Async Service: Queue: Sync Service read() message work() notification enqueue() message notification read() message work()

22. Slide 22 © Ingeniørhøjskolen i Århus Active Object Abstract The Active Object Design Pattern decouples method execution from method invocation to enhance concurrency and simplify synchronized access to objects that reside in their own threads of control

23. Slide 23 © Ingeniørhøjskolen i Århus Active Object Structure Proxy +method_1() +method_N() Client «invoke» «write to» «obtain result from» Future «instantiate» Servant +method_1() +method_N() «execute» Method Request +can_run() +call() Concrete MethodReq1 Concrete MethodReqN «instantiate» Scheduler #dispatch() +insert() Activation List +insert() +remove() 1111 *

24. Slide 24 © Ingeniørhøjskolen i Århus Active Object Dynamics :Future method insert :Proxy :Scheduler :Servant :Method Request :Client dispatchcall method write 2. Method execution 1. Method request and scheduling read 3. Completion

25. Slide 25 © Ingeniørhøjskolen i Århus Monitor Object Abstract 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 method to cooperatively schedule their execution sequences The Scoped Locking C++ Idiom ensures that a lock is acquired when control enters a scope and released automatically when control leaves the scope, regardless of the return path form the scope

26. Slide 26 © Ingeniørhøjskolen i Århus Monitor Object Pattern Structure ClientMonitor Object +sync_method1() +sync_methodN() 2..* Monitor Lock uses +acquire() +release() 1 * 1 Monitor Condition uses +wait() +notify() +notify_all() Needed to implement wait in a monitor

27. Slide 27 © Ingeniørhøjskolen i Århus Monitor Object Dynamics :Monitor Object :Monitor Lock :Monitor Condition :Client Thread2 :Client Thread1 sync_method1() acquire() dowork() sync_method2() acquire() dowork() notify() release() wait() release() dowork() release() acquire()

28. Slide 28 © Ingeniørhøjskolen i Århus Leader/Followers Abstract 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, and process service requests that occur on the event sources

29. Slide 29 © Ingeniørhøjskolen i Århus Leader/Followers Structure Thread Pool join() promote_new_leader() synchronizer uses Handle * Handle Set handle_events() deactivate_handle() reactivate_handle() select() 1 demultiplexes * Event Handler handle_event() get_handle() Concrete Event Handler A Concrete Event Handler B handle_event() get_handle() handle_event() get_handle() Thread joins 1 *

30. Slide 30 © Ingeniørhøjskolen i Århus Thread State Chart LEADING become new leader PROCESSING new event processing completed [no current leader] FOLLOWING processing completed [there is a current leader]

31. Slide 31 © Ingeniørhøjskolen i Århus Leader/Followers Dynamics handle_events() new_leader() promote_

32. Slide 32 © Ingeniørhøjskolen i Århus Component Configurator Abstract The Component Configurator Design Pattern allows an application to link and 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 and re-start running processes.

33. Slide 33 © Ingeniørhøjskolen i Århus Component Configurator Structure Concrete Component A Concrete Component B Component Repository Component Configurator +insert() +remove() +find() +suspend() +resume() Component +init() +fini() +suspend() +resume() +info() * components «controls» 1 Application

34. Slide 34 © Ingeniørhøjskolen i Århus Component Configurator Dynamics :Component Configurator :Concrete Component A :Component Repository run_component() 2. Component processing :Concrete Component B

35. Slide 35 © Ingeniørhøjskolen i Århus State Chart for a Component Life Cycle IDLE fini() TERMINATE/ fini() TERMINATE/ suspend() SUSPEND/ SUSPENDED RECONFIGURE/ init() EXECUTE/ run_component() CONFIGURE/ init() RUNNING resume() RESUME/

36. Slide 36 © Ingeniørhøjskolen i Århus Interceptor Abstract The Interceptor Architectural Pattern allows services to be added transparently to a framework and triggered automatically when certain events occur

37. Slide 37 © Ingeniørhøjskolen i Århus Interceptor Structure Interceptor +event1_callback() +event2_callback() Concrete Interceptor +event1_callback() +event2_callback() Application do_work() * 1 «use» «register» «remove» * Dispatcher List of Interceptors +dispatch() +register() +remove() +iterate_list() Concrete Framework +event() +access_internals() +service() Context +set_value() +get_value() +consume_service() * «create» 1

38. Slide 38 © Ingeniørhøjskolen i Århus Interceptor Dynamics :Concrete Framework :Dispatcher co:Context object event() :Application ci:Concrete Interceptor register(ci) consume_ service() get_value() access_internals() event_callback(co) dispatch(co) iterate_ list()

39. Slide 39 © Ingeniørhøjskolen i Århus Extension Interface Abstract The Extension Interface Design Pattern allows multiple interfaces to be exported by a component, to prevent bloating of interfaces and breaking of client code when developers extend or modify the functionality of the component

40. Slide 40 © Ingeniørhøjskolen i Århus Extension Interface Structure * Extension Interface +service() Root Interface +getExtension() Client «invoke» Component Factory +create() +find() «instantiate» Component +service() -implementation() «new»

41. Slide 41 © Ingeniørhøjskolen i Århus Extension Interface Dynamics (1) :Client :Component Factory :Imp. Extension Interface create() Interface ID :Component getExtension() Interface ID Interface

42. Slide 42 © Ingeniørhøjskolen i Århus Extension Interface Dynamics (2) :Client :Imp. Extension Interface A service1() getExtension() Interface ID B Interface B :Imp. Extension Interface B service2()

43. Slide 43 © Ingeniørhøjskolen i Århus Thread-Specific Storage Abstract 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 the locking overhead on each object access

44. Slide 44 © Ingeniørhøjskolen i Århus Thread-Specific Storage Structure Application Thread Key Factory +create_key() 1 Thread-Specific Object Set +get(key) +set(key, object) threadId {0..m} 0..1 Thread-Specific Object Proxy -key «uses» +method1().. +methodN() 0..m 0..n Thread-Specific Object +method1().. +methodN() maintains key 0..1 {0..n}

45. Slide 45 © Ingeniørhøjskolen i Århus Thread-Specific Storage Dynamics (1) :Application Thread :ThreadSpecific ObjectProxy :ThreadSpecific ObjectSet :Key Factory method() createKey() key ts :ThreadSpecific Object create () set() tskey method()

46. Slide 46 © Ingeniørhøjskolen i Århus Thread-Specific Storage Dynamics (2) :Application Thread :ThreadSpecific ObjectProxy :ThreadSpecific ObjectSet ts :ThreadSpecific Object get() key ts method() result

47. Slide 47 © Ingeniørhøjskolen i Århus Overview of the ACE Framework

48. Slide 48 © Ingeniørhøjskolen i Århus TAO (The Ace Orb) TAO is a high-performance real-time ORB endsystem TAO supports: –the standard OMG CORBA reference model –the Real-Time CORBA specification –enhancements for predictable, and scalable QoS for high-performance and real-time applications

49. Slide 49 © Ingeniørhøjskolen i Århus Components in the TAO Real-time ORB Endsystem

50. Slide 50 © Ingeniørhøjskolen i Århus Applying a Pattern Language to TAO POSA2 & GoF Patterns IDL Stub IDL Skeleton

51. Slide 51 © Ingeniørhøjskolen i Århus Using the Reactor Pattern in TAO’s Event Loop GIOP Solution – the Reactor Pattern: An effective way to reduce coupling and increase the extensibility of an ORB core

52. Slide 52 © Ingeniørhøjskolen i Århus Using the Acceptor-Connector in TAO’s Connection Management TAO’s Acceptors and Connectors can be configured with any transport mechanisms and with custom concurrency strategies

53. Slide 53 © Ingeniørhøjskolen i Århus Using the Leader/Followers Pattern in TAO Running GIOP Connection Handlers Solution: Leader/Followers An efficient concurrency model

54. Slide 54 © Ingeniørhøjskolen i Århus Using the Component Configurator Pattern in TAO

55. Slide 55 © Ingeniørhøjskolen i Århus JAWS High-performance Web Server called JAWS JAWS is both a Web Server and a Framework from which other types of serves can be built JAWS was developed using the ACE Framework

56. Slide 56 © Ingeniørhøjskolen i Århus Architectural Overview of JAWS

57. Slide 57 © Ingeniørhøjskolen i Århus JAWS Web Server Framework