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

Track 1: Summary Slides for POSA2 Patterns and Frameworks

Distributed Real-Time Systems (TI-DRTS)

Version: 14-12-2009

Slide 2© Ingeniørhøjskolen i Århus

DRTS Course Model

POSA2 PatternsACE/TAO/JAWS

Frameworks

General DRTS Theory

POSA Pattern ExercisesMedico

DRTS Project

Track 1

Track 2

Track 3exercises


POSA2 Pattern Categorization

1. Event Handling Patterns

2. Service Access and Configuration Patterns

3. Concurrency Patterns

4. Synchronization Patterns


The POSA2 Pattern Language


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


Wrapper Façade Structure

Applicationcalls methods

calls API FunctionA()

calls API FunctionB()

calls API FunctionC()

void methodN(){functionA();

}

void method1(){

functionA();

}functionB();

Wrapper Facade

data

method1()…methodN()


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


Reactor Pattern – Structure

SynchronousEvent

Demultiplexer

+select()

*

1

«uses»

EventHandler

+handle_event()+get_handle()

ConcreteEventHandlerA

+handle_events()+register_handler()+remove_handler()

ConcreteEventHandlerB

handle_event()get_handle()

Handle

owns

Reactor


1

1

dispatches *1

*

1

Application«creates»


Reactor – Sequence Diagram

: Main Program : ConcreteEvent Handler

: Reactor : Synchronous Event

Demultiplexer

register_handler()

get_handle()

handle_events() select()handle_event()

Handle

Handles

Handles

Con. EventHandler Events

service()

event

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


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


Acceptor/Connector Structure

owns

*

usesuses

<<creates>>

owns

uses

owns

<<activate>>

* *

**

*

uses <<notifies>>

<<notifies>><<notifies>>

Connector

Connector()connect()complete()handle_event ()

Concrete Service Handler B

Concrete Service Handler A

ConcreteAcceptor

ConcreteConnector

Acceptor

Acceptor()accept()handle_event ()

peer_acceptor_

Service Handler

open()handle_event ()set_handle()

peer_stream_

Dispatcher

+select()+handle_events()+register_handler()+remove_handler()

TransportHandle

TransportHandle

TransportHandle

<<activate>>

*

1

1

1

1

1

1

*

1


Acceptor Dynamics: Application : Acceptor : Dispatcher

register_handler()

handle_events()

open() ACCEPT_EVENTHandle1Acceptor

1. Passive-mode endpoint initialize phase

1.accept()

ServiceHandler Events

register_handler()

: ServiceHandler

open()

: Handle2

Handle2

Handle2

2. Service handler initialize phase

2.

handle_event()

service()

3. Service processing phase

3.

Event

Event


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


Proactor Structure

CompletionHandler

ConcreteCompletion

Handler

handle_event()

Proactor

handle_events()

AsynchronousEvent Demuxer

get_completion_event()

AsynchronousOperation Processor

execute_async_operation()

CompletionEvent Queue

AsynchronousOperation

async_operation()

Handle

«dequeues»

«enqueues»

«executes»

«demultiplexes& dispatches»

*

1 1

1

1

1

1

Initiator«uses»«uses»

«uses»

«uses»


Proactor Dynamics

CompletionHandler

Completion

:AsynchronousOperation

: Proactor :ConcreteCompletionHandler

exec_async_

:AsynchronousOperationProcessor

async_operation()Ev. Queue

operation ()

:Completion

Event Queue

1. Initiate operation

2. Process operation

Result

Result

completionevent

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


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


ACT Structure

AsynchronousCompletion

Token

0..*

Initiator

completion_action()

0..*

Service

async_operation()

calls operations

1 1

1

CompletionHandler

+handle_event()

1..*

«uses»

«demultiplexes»


ACT Dynamic

:Initiator:Completion

Handler:Service

operation()ACT

notify() ACT result

completion_action()

handle_event()

result

:ACT«create»


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


Half-Sync/Half-Async Structure

«dequeue/enqueue»

Queue«read/write» «read/write»

«read/write»

QueueingLayer

Async ServiceExternal

Event Source«interrupt»Asynchronous

ServiceLayer

Sync Service 1

Sync Service 2

Sync Service 3

SynchronousServiceLayer


Half-Sync/Half-Async Dynamics

: External Event

Source

: Async Service : Queue : Sync Service

read()

message

work()

notification

enqueue()

message

notification

read()

message

work()


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


Active Object Structure

Proxy

+method_1()+method_N()

Client

«invoke»

«write to»«obtain

result from»

Future

«instantiate»

Servant

+method_1()+method_N()

«execute»

MethodRequest

+can_run()+call()

ConcreteMethodReq1

ConcreteMethodReqN

«instantiate»

Scheduler

#dispatch()+insert()

ActivationList

+insert()+remove()

1 1 1 1

*


Active Object Dynamics

:Future

method

insert

:Proxy :Scheduler :Servant

:MethodRequest

:Client

dispatch call method

write

2. Method execution

1. Method requestand scheduling

read3. Completion


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


Monitor Object Pattern Structure

Client Monitor 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


Monitor Object Dynamics:MonitorObject

:MonitorLock

:MonitorCondition

:ClientThread2

:ClientThread1

sync_method1() acquire()

dowork()

sync_method2() acquire()

dowork()notify()

release()

wait()

release()

dowork()

release()

acquire()


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


Leader/Followers Structure

Thread Pool

join()promote_new_leader()

synchronizer

usesHandle*Handle Set

handle_events()deactivate_handle()reactivate_handle()select()

1

demultiplexes

*Event Handler


Concrete EventHandler A

Concrete EventHandler B



Threadjoins

1*


Thread State Chart

LEADING

become new leader PROCESSING

newevent

processingcompleted

[no current leader]

FOLLOWING

processingcompleted

[there is a current leader]


Leader/Followers Dynamics:Concrete

Event Handler

join()

handle_event()

:ThreadPool

:HandleSet

join()

thread 2 sleepsuntil it becomesthe leader

event

thread 1 sleepsuntil it becomesthe leader

deactivate_handle()

Thread 1 Thread 2

handle_events() reactivate_

handle()

handle_event()

event

thread 2waits for anew event,thread 1processescurrentevent

deactivate_handle()

handle_events()

new_leader()promote_


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.


Component Configurator Structure

ConcreteComponent A

ConcreteComponent B

ComponentRepository

ComponentConfigurator

+insert()+remove()+find()+suspend()+resume()

Component

+init()+fini()+suspend()+resume()+info()

*components

«controls»

1

Application


Component Configurator Dynamics

:ComponentConfigurator

:ConcreteComponent A

:ComponentRepository

run_component()

run_component()2. Component processing

fini()

remove()

remove()

fini()

ConcreteComp. A

ConcreteComp. B

3. Component termination

init()

insert()

insert()

init()

ConcreteComp. A

ConcreteComp. B

1. Component initalization

:ConcreteComponent B


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/


Interceptor Abstract

The Interceptor Architectural Pattern allows services to be added transparently to a framework and triggered automatically when certain events occur


Interceptor Structure

Interceptor

+event1_callback()+event2_callback()

ConcreteInterceptor

+event1_callback()+event2_callback()

Application

do_work()

*1

«use»

«register»

«remove»

* Dispatcher

List of Interceptors

+dispatch()+register()+remove()+iterate_list()

ConcreteFramework

+event()+access_internals() +service()

Context+set_value()+get_value()+consume_service()

*

«create»1


Interceptor Dynamics:Concrete

Framework

:Dispatcher

co:Contextobject

event()

:Application

ci:ConcreteInterceptor

register(ci)

consume_service()

service()

get_value()

access_internals()

event_callback(co)

dispatch(co)

iterate_list()


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


Extension Interface Structure

*ExtensionInterface

+service()

Root Interface

+getExtension()Client

«invoke»

ComponentFactory

+create()+find()

«instantiate»

Component

+service()-implementation()

«new»


Extension Interface Dynamics (1)

:Client:Component

Factory:Imp. Extension

Interface

create()

Interface ID

:Component

getExtension() Interface ID

Interface

Interface


Extension Interface Dynamics (2)

:Client:Imp. Extension

Interface A

service1()

getExtension()

Interface ID B

Interface B

:Imp. ExtensionInterface B

service2()


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


Thread-Specific Storage Structure

ApplicationThread

Key Factory

+create_key()

1

Thread-SpecificObject Set

+get(key)+set(key, object)

threadId

{0..m}

0..1

Thread-SpecificObject Proxy

-key

«uses»

+method1()..+methodN()

0..m

0..n

Thread-SpecificObject

+method1()..

+methodN()

maintains

key

0..1

{0..n}


Thread-Specific Storage Dynamics (1)

:ApplicationThread

:ThreadSpecificObjectProxy

:ThreadSpecificObjectSet

:KeyFactory

method()createKey()

keyts

:ThreadSpecificObject

create ()

set()

ts key

method()


Thread-Specific Storage Dynamics (2)

:ApplicationThread

:ThreadSpecificObjectProxy

:ThreadSpecificObjectSet

ts:ThreadSpecific

Object

get() key

ts

method()

method()

resultresult


Overview of the ACE Framework


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


Components in the TAO Real-time ORB Endsystem


Applying a Pattern Language to TAO

POSA2 &GoFPatterns

IDLStub

IDLSkeleton


Using the Reactor Pattern in TAO’s Event Loop

GIOP

Solution – the ReactorPattern:

An effective way to reduce couplingand increase the extensibilityof an ORB core


Using the Acceptor-Connector in TAO’sConnection Management

TAO’sAcceptorsand Connectorscan be configuredwith anytransportmechanismsand withcustom concurrencystrategies


Using the Leader/Followers Pattern in TAO

RunningGIOPConnectionHandlers

Solution:Leader/Followers

An efficientconcurrency model


Using the Component Configurator Pattern in TAO


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


Architectural Overview of JAWS


JAWS Web Server Framework

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

Documents

posa2 pattern languageslide

eventdriven applications

service handleropenhandle

event set

acceptor dynamics

event handlers

e peer

useseventhandler handle