using and developing r fo atterns p - vanderbilt universityschmidt/pdf/tao2.pdf · using and...

Design Patterns for Developing and Using

Real-time CORBA Object Request Brokers

Douglas C. [email protected]

Washington University, St. Louiswww.cs.wustl.edu/�schmidt/TAO4.ps.gz

SponsorsBellcore, Boeing, CDI, DARPA, Kodak,

Lucent, Motorola, NSF, OTI, SAIC,Siemens SCR, Siemens MED, Siemens ZT, and Sprint

Douglas C. Schmidt High-performance, Real-time ORBs

Motivation: the Distributed Software Crisis

DDIIAAGGNNOOSSTTIICC

SSTTAATTIIOONNSS

AATTMMMMAANN

AATTMMLLAANN

AATTMMLLAANN

MMOODDAALLIITTIIEESS

((CCTT,, MMRR,, CCRR)) CCEENNTTRRAALL

IIMMAAGGEESSTTOORREE

CCLLUUSSTTEERRIIMMAAGGEESSTTOORREE

DDXXIIMMAAGGEESSTTOORREE

� Symptoms

{ Hardware gets smaller,faster, cheaper{ Software gets larger, slower,

more expensive

� Culprits

{ Accidental and inherent

complexity

� Solutions

{ Middleware, frameworks,components, and patterns

Washington University, St. Louis 1


Sources of Complexity for Distributed Applications

PRINTER

FILESYSTEM

PRINTER FILE SYSTEM

COMPUTERCOMPUTER

(1)(1) STAND-ALONESTAND-ALONE APPLICATIONAPPLICATION ARCHITECTUREARCHITECTURE

(2)(2) DISTRIBUTEDDISTRIBUTED APPLICATIONAPPLICATION ARCHITECTUREARCHITECTURE

CD ROM

CD ROM

NETWORK

FI LE

SERVICE

CYCLE

SERVICE

DISPLAY

SERVICE

PRINT

SERVICE

NAME

SERVICE

TIME

SERVICE

� Inherent complexity

{ Latency{ Reliability{ Partitioning{ Ordering

� Accidental Complexity

{ Low-level APIs{ Poor debugging tools{ Algorithmic

decomposition{ Continuous re-invention



Techniques for Improving Software

Quality and Productivity

APPLICATIONAPPLICATION

SPECIFICSPECIFIC

LOGICLOGIC

USERUSER

INTERFACEINTERFACE

((AA)) CLASS LIBRARY CLASS LIBRARY

ARCHITECTUREARCHITECTURE

NETWORKINGNETWORKING

MATHMATH ADTADTSS

DATADATA

BASEBASE


SPECIFICSPECIFIC

LOGICLOGIC

MATHMATH

((BB)) APPLICATION FRAMEWORK APPLICATION FRAMEWORK

ARCHITECTUREARCHITECTURE

ADTADTSS

INVOKESINVOKES

CALLCALL

BACKSBACKS

NETWORKINGNETWORKING USERUSER

INTERFACEINTERFACE

DATABASEDATABASE

INVOKESINVOKES

EVENTEVENT

LOOPLOOP

EVENTEVENT

LOOPLOOP

� Proven solutions

{ Components

� Self-contained, \pluggable"ADTs

{ Frameworks

� Reusable, \semi-complete"applications

{ Patterns

� Problem/solution pairs in acontext

{ Architecture

� Families of related patternsand components



Motivation for Real-time Middleware

WIDE AREA

NETWORK

SATELLITESSATELLITESTRACKINGTRACKINGSTATIONSTATION

PEERSPEERS

STATUS INFO

COMMANDS BULK DATA

TRANSFER

LOCAL AREA NETWORK

GROUNDSTATION

PEERS

GATEWAY

� Many applications requireQoS guarantees

{ e.g., telecom, avionics,WWW

� Existing middleware doesn'tsupport QoS e�ectively

{ e.g., CORBA, DCOM, DCE

� Solutions must be integrated

{ Vertically and horizontally



Candidate Solution: CORBA

DII ORBINTERFACE

ORBCORE

operation()

IDLSTUBS

OBJECT

ADAPTER

IDLSKELETON

DSI

in args

out args + return value

CLIENT

GIOP/IIOP

SERVANT

STANDARD INTERFACE STANDARD LANGUAGE

MAPPING

ORB-SPECIFIC INTERFACE STANDARD PROTOCOL

www.cs.wustl.edu/�schmidt/corba.html

� Goals of CORBA

{ Simplify distributionby automating� Object location

and activation� Parameter

marshaling� Demultiplexing� Error handling{ Provide foundation

for higher-levelservices



Limitations of CORBA for Real-time Systems

DII ORBINTERFACE

ORBCORE

operation()

IDLSTUBS

OBJECT

ADAPTER

IDLSKELETON

DSI

in args

out args + return value

CLIENT

GIOP/IIOP

SERVANT

STANDARD INTERFACE STANDARD LANGUAGE

MAPPING

ORB-SPECIFIC INTERFACE STANDARD PROTOCOL

www.cs.wustl.edu/�schmidt/ORB-endsystem.ps.gz

� Limitations

{ Lack of QoSspeci�cations{ Lack of QoS

enforcement{ Lack of real-time

programmingfeatures{ Lack of performance

optimizations



The ACE ORB (TAO)

NETWORKNETWORK

ORBORB QQOOSSINTERFACEINTERFACE

REALREAL--TIMETIMEORBORB CORECORE

operation()operation()

RIDLRIDLSTUBSSTUBS

REALREAL--TIMETIME

OBJECTOBJECT

ADAPTERADAPTER

RIDLRIDLSKELETONSKELETON

in argsin args

out args + return valueout args + return value

CLIENTCLIENT

OS KERNELOS KERNEL

HIGHHIGH--SPEEDSPEED

NETWORK ADAPTERSNETWORK ADAPTERS

REALREAL--TIME ITIME I//OOSUBSYSTEMSUBSYSTEM

RIOPRIOP

SERVANTSERVANT

OS KERNELOS KERNEL

HIGHHIGH--SPEEDSPEED


REALREAL--TIME ITIME I//OOSUBSYSTEMSUBSYSTEM

www.cs.wustl.edu/�schmidt/TAO.html

� TAO Overview

{ A high-performance,real-time ORB� Telecom and

avionics focus{ Leverages the ACE

framework� Runs on RTOSs,

POSIX, and Win32

� Related work

{ QuO at BBN{ ARMADA at U.

Mich.


DouglasC.SchmidtHigh-performance,Real-timeORBs

TheADAPTIVECommunicationEnvironment(ACE)

PROCESSES PROCESSES//THREADS THREADS

DYNAMIC DYNAMIC

LINKING LINKING

MEMORY MEMORY

MAPPING MAPPING

SELECT SELECT//IO COMP IO COMP

SYSTEM SYSTEM

VV IPC IPCSTREAM STREAM

PIPES PIPES

NAMED NAMED

PIPES PIPES

CAPIS

SOCKETS SOCKETS//TLI TLI

COMMUNICATION COMMUNICATION

SUBSYSTEM SUBSYSTEM

VIRTUAL MEMORY VIRTUAL MEMORY

SUBSYSTEM SUBSYSTEM

GENERAL POSIX AND WIN32 SERVICES

PROCESS PROCESS//THREAD THREAD

SUBSYSTEM SUBSYSTEM

FRAMEWORKSACCEPTOR ACCEPTORCONNECTOR CONNECTOR

SELF-CONTAINED

DISTRIBUTED

SERVICE

COMPONENTS

NAME NAME

SERVER SERVER

TOKEN TOKEN

SERVER SERVER

LOGGING LOGGING

SERVER SERVER

GATEWAY GATEWAY

SERVER SERVER

SOCK SOCK__SAP SAP//TLI TLI__SAP SAP

FIFO FIFO

SAP SAP

LOG LOG

MSG MSG

SERVICE SERVICE

HANDLER HANDLER

TIME TIME

SERVER SERVER

C++WRAPPERS

SPIPE SPIPE

SAP SAP

CORBA CORBA

HANDLER HANDLER

SYSV SYSVWRAPPERS WRAPPERS

SHARED SHARED

MALLOC MALLOC

THE ACE ORB THE ACE ORB

((TAO TAO))

JAWS ADAPTIVE JAWS ADAPTIVE

WEB SERVER WEB SERVER

MIDDLEWARE

APPLICATIONS

REACTOR REACTOR//PROACTOR PROACTOR

PROCESS PROCESS//THREAD THREAD

MANAGERS MANAGERS

ADAPTIVE SERVICE EXECUTIVE ADAPTIVE SERVICE EXECUTIVE (ASX) (ASX)

SERVICE SERVICE

CONFIG CONFIG--URATOR URATOR

SYNCH SYNCH

WRAPPERS WRAPPERS

MEM MEM

MAP MAP

OS ADAPTATION LAYER

www.cs.wustl.edu/�schmidt/ACE.html

�ACEOverview

{ConcurrentOOnetworkingframework{PortedtoC++

andJava{RunsonRTOSs,

POSIX,andWin32

�Relatedwork

{x-Kernel{SysVSTREAMS

WashingtonUniversity,St.Louis8


ACEStatistics

�ACEcontain>125,000linesofC++

{Over10person-yearsofe�ort

�PortedtoUNIX,Win32,MVS,andembeddedplatforms

{e.g.,VxWorks,Chorus,LynxOS,pSoS

�Largeusercommunity

{www.cs.wustl.edu/�schmidt/ACE-users.html

�Currentlyusedbydozensofcompanies

{Bellcore,Boeing,Ericsson,Kodak,Lucent,Motorola,SAIC,Siemens,StorTek,etc.

�Supportedcommercially

{www.riverace.com



Applying ORBs to Real-time Avionics

OBJECTOBJECT REQUESTREQUEST BROKERBROKER

2:PUSH (EVENTS)

AirFrame

Sensorproxy

HUD

Nav

EVENT

CHANNEL

Sensorproxy

Sensorproxy

3:PUSH (DEMARSHALED DATA)

1: SENSORS

GENERATE

DATA

� Domain Challenges

{ Periodicdeterministicreal-time deadlines{ COTS infrastructure{ Open systems



Visualizing Periods for Avionics Operations



Real-time Features and Optimizations in TAO

NETWORKNETWORK

OS KERNELOS KERNEL

OS IOS I//O SUBSYSTEMO SUBSYSTEM


OS KERNELOS KERNEL



ORBORBINTERFACEINTERFACE

ORBORBCORECORE


IDLIDLSTUBSSTUBS

OBJECTOBJECT

ADAPTERADAPTER

IDLIDLSKELETONSKELETON

in argsin args


CLIENTCLIENT

GIOPGIOP

SERVANTSERVANT

CONNECTION

MANAGEMENT

OPTIMIZATIONS

DATA COPYING

OPTIMIZATIONS

REQUEST

DEMUXING AND

DISPATCHING

OPTIMIZATIONS

THREADING

OPTIMIZATIONS

PROTOCOL

OPTIMIZATIONS

I/O SUBSYSTEM

OPTIMIZATIONS

NETWORK

ADAPTER

OPTIMIZATIONS

PRESENTATION

LAYER

OPTIMIZATIONS



Providing QoS to CORBA Operations

PERIODIC SCHEDULING AND DISPATCHINGPERIODIC SCHEDULING AND DISPATCHING

P:P: PERIOD PERIOD

C:C: REQUEST COMPUTATION TIME REQUEST COMPUTATION TIME

PP

CC CC

TIMETIME

TT TT++PP TT++22PP

struct RT_Infostruct RT_Info{{ Time_t worstcase_exec_time_; Time_t worstcase_exec_time_; Time_t cached_exec_time_; Time_t cached_exec_time_; Period_t period_; Period_t period_; Importance importance_; Importance importance_; sequence<RT_Info> dependencies_; sequence<RT_Info> dependencies_;};};

RTRTOperationOperation

� Design Challenges

{ Specifying/enforcing QoS requirements{ Focus on Operations upon Objects

� Rather than on communicationchannels or threads/synchronization

� Initial focus

{ Determinisitic deadlines{ Static scheduling

� Solution approach

{ Servants publish resource (e.g., CPU)requirements and (periodic) deadlines{ Most clients are also servants



TAO's Real-time Scheduling Service

RTRT__INFOINFO

REPOSITORYREPOSITORY

OFFOFF--LINELINE

SCHEDULERSCHEDULER

DEPENDS UPON DEPENDS UPON ==EXECUTES AFTEREXECUTES AFTER

4: ASSESS

SCHEDULABILITY

5: ASSIGN OS THREAD

PRIORITIES AND

DISPATCH QUEUE

ORDERING

SUBPRIORITIES6: SUPPLY

PRIORITIES

TO ORB

3: POPULATE

RT_INFO

REPOSITORY

RUNRUN--TIMETIME

SCHEDULERSCHEDULER

Priority/Priority/SubprioritySubpriorityTable PerTable Per

ModeMode

MODE MODE 00

MODE MODE 11

MODE MODE 22

MODE MODE 33

CURRENTCURRENT

MODEMODE

SELECTORSELECTOR

struct RT_Infostruct RT_Info{{ wc_exec_time_; wc_exec_time_; cached_exec_time_; cached_exec_time_; period_; period_; importance_; importance_; dependencies_; dependencies_;};};

1:1: CONSTRUCT CALL CONSTRUCT CALL

CHAINS OF RT CHAINS OF RT__OPERATIONSOPERATIONS

2:2: IDENTIFY THREADS IDENTIFY THREADS

RTRT

OperationOperation

RTRT

OperationOperation

RT

Operation

I/O SUBSYSTEM

ORB CORE

OBJECT ADAPTER

www.cs.wustl.edu/�schmidt/TAO.ps.gz

� Components

{ O�ine� Assess schedule

feasibility� Assign thread and

queue priorities{ Online

� Supply priorities toORB endsystemdispatcher via O(1)table lookup



TAO's Real-time ORB Endsystem Architecture

RR

UU

NN

TT

II

MM

EE

S S

CC

HH

EE

DD

UU

LL

EE

RR

SOCKETSOCKET QUEUEQUEUE DEMUXERDEMUXER

ATM PORT INTERFACECONTROLLER (APIC)

ZZ

EE

RR

OO

CC

OO

PP

YY

BB

UU

FF

FF

EE

RR

SS

II//OOSUBSYSTEMSUBSYSTEM

OBJECTOBJECTADAPTERADAPTER

SERVANTSERVANT DEMUXERDEMUXER

CLIENTSCLIENTSSTUBSSTUBS

SERVANTSSERVANTSSKELETONSSKELETONS

U

ORBORB CORECORE

REACTORREACTOR

(20 (20 HZHZ))

REACTORREACTOR

(10 (10 HZHZ))

REACTORREACTOR

(5 (5 HZHZ))

REACTORREACTOR

(1 (1 HZHZ))

QQooSSAPIAPI

� Solution Approach

{ Integrate RT dispatcher intoORB endsystem{ Support multiple request

scheduling strategies� e.g., RMS, RMS with

Deferred Preemption, andEDF

{ Requests ordered acrossthread priorities by OSdispatcher{ Requests ordered within

priorities based on data

dependencies and importance



Priority Inversion Experiments

��

C 1C 0

Requests

C n

��

Client

...

...

2ATM Switch

Ultra 2 Ultra 2

I/O SUBSYSTEM

Server

Object Adapter

ORB Core

Servants RU

NT

IME

SCH

ED

UL

ER

www.cs.wustl.edu/�schmidt/RT-perf.ps.gz

� One high priority client

� 1..n low priority clients

� Server factory implementsthread-per-rate

{ Highest real-timepriority for high priorityclient{ Lowest real-time

priority for low priorityclients



Priority Inversion Experiment Results

0

2

4

6

8

10

12

14

16

1 5 10 15 20 25 30 35 40 45 50

Number of Low Priority Clients

Late

ncy

per

Twow

ay R

eque

st in

Mill

isec

onds

MT-Orbix High-PriorityMT-Orbix Low-PrioritySun COOL High-PrioritySun COOL Low-Priority

TAO High-PriorityTAO Low-Priority

MT-Orbix, Chorus, and TAO Priority Inversion

� Synopsis of results

{ Chorus' latency is lower forsmall # of clients� �1.2msec vs. �1.4sec vs.

�2.0sec{ TAO's latency is much

lower for large # of clients� �2.3msec vs. �7.6msec

vs. �14.1msec{ TAO avoids priority

inversion� i.e., high priority client

always has lowest latency



Jitter Experiment Results

1 5 10 15 20 25 30 35 40 45 50

TAO High Priority JitterTAO Low Priority Jitter

Sun COOL High Priority JitterSun COOL Low Priority Jitter

Orbix High Priority JitterOrbix Low Priority Jitter

0

10

20

30

40

50

60

70

80

90

100

Jitt

er (

mill

isec

)

Number of Low Priority Clients

MT-Orbix, Chorus, and TAO Jitter

� De�nition

{ Jitter is thevariance from theaverage latency

� Synopsis of results

{ TAO's jitter islowest and mostconsistent{ MT-Orbix's jitter is

highest and morevariable



Problem: Improper ORB Concurrency Model

OBJECTOBJECTADAPTERADAPTER

SERVANTSERVANT DEMUXERDEMUXER

SERVANTSERVANTSKELETONSSKELETONS

U

ORBORB CORECORE

FILTERFILTER

FILTERFILTER

FILTERFILTER

THREADTHREAD

FILTERFILTER

SERVANTSERVANTSKELETONSSKELETONS

U1: impl_is_ready()1: impl_is_ready()

2: recv()2: recv()

3: enqueue(data)3: enqueue(data)

4: filter4: filterrequest &request &enqueueenqueue

5: dispatch5: dispatchmethod()method()

II//OO SUBSYSTEMSUBSYSTEM

� Common Problems

{ High overhead� Context switching� Synchronization{ Priority inversions

� FIFO request queueing� Improper thread priorities{ Lack of application control

over concurrency model



Problem: ORB Shared Connection Model

SERVERSERVERORBORB CORECORE



COMMUNICATIONCOMMUNICATION LINKLINK


SERVANTSSERVANTS

ONEONE TCPTCP

CONNECTIONCONNECTION

ORBORB CORECORE

SEMAPHORESSEMAPHORES

2: select()2: select()4: release()

3: read()

BO

RR

OW

ED

TH

RE

AD

BO

RR

OW

ED

TH

RE

AD

S

APPLICATION

5: dispatch_return()

1: invoke_twoway()

� Common Problems

{ Priority inversions� Sharing multiple

priorities on asingle connection

{ Complexconnectionmultiplexing{ Synchronization

overhead



TAO's Inter-ORB Connection Topology

CLIENTCLIENT ORBORB CORECORE

20 10 5 120 10 5 1

HZHZ HZHZ HZHZ HZHZ

CONNECTORCONNECTOR

20 10 5 120 10 5 1

HZHZ HZHZ HZHZ HZHZ

CONNECTORCONNECTOR

20 10 5 120 10 5 1

HZHZ HZHZ HZHZ HZHZ

CONNECTORCONNECTOR

SERVERSERVER ORBORB CORECORE

REACTORREACTOR

(20 (20 HZHZ))

REACTORREACTOR

(10 (10 HZHZ))

REACTORREACTOR

(5 (5 HZHZ))

REACTORREACTOR

(1 (1 HZHZ))

CC

OO

NN

NN

EE

CC

TT

22

AA

CC

CC

EE

PP

TT

OO

RR

CC

OO

NN

NN

EE

CC

TT

11

CC

OO

NN

NN

EE

CC

TT

33

II//OO SUBSYSTEMSUBSYSTEMI/O SUBSYSTEM

C

O

N

N

E

C

T

2

A

C

C

E

P

T

O

R

C

O

N

N

E

C

T

1

C

O

N

N

E

C

T

3

C

O

N

N

E

C

T

2

A

C

C

E

P

T

O

R

C

O

N

N

E

C

T

1

C

O

N

N

E

C

T

3

C

O

N

N

E

C

T

2

A

C

C

E

P

T

O

R

C

O

N

N

E

C

T

1

C

O

N

N

E

C

T

3

COMMUNICATION LINK

CLIENT APPLICATION

STUB STUB STUB

www.cs.wustl.edu/�schmidt/RT-middleware.ps.gz



Problem: Reducing Demultiplexing Latency

2:2: DEMUX TO DEMUX TO

I/OI/O HANDLE HANDLE

OP

ER

AT

ION

OP

ER

AT

ION

KK

OP

ER

AT

ION

OP

ER

AT

ION

22

.........

OP

ER

AT

ION

OP

ER

AT

ION

11.........

.........IDL

SKEL 1IDLIDL

SKEL SKEL 22IDLIDL

SKEL SKEL MM

OS KERNELOS KERNEL



SERVANT SERVANT 11 SERVANT SERVANT 22 SERVANT SERVANT NN


SKELETON SKELETON


OPERATION OPERATION

1:1: DEMUX THRU DEMUX THRU

PROTOCOL STACK PROTOCOL STACK


SERVANT SERVANT

LAYERED

DEMUXING

ORB COREORB CORE

OBJECT ADAPTER


OBJECT ADAPTER OBJECT ADAPTER

� Design Challenges

{ Minimize demuxinglayers{ Provide O(1) operation

demuxing{ Avoid priority inversions{ Remain

CORBA-compliant



Demultiplexing Performance Experiments

.........

.........IDLIDL

SKEL SKEL 22

OBJECT ADAPTER

SERVANT SERVANT 500500

(A)(A) LAYERED DEMUXING LAYERED DEMUXING,,LINEAR SEARCHLINEAR SEARCH

SERVANT SERVANT 11 SERVANT SERVANT 22

IDLIDL

SKEL SKEL 11

OP

ER

AT

ION

OP

ER

AT

ION

100

100

OP

ER

AT

ION

OP

ER

AT

ION22

.........

OP

ER

AT

ION

OP

ER

AT

ION

11

IDLIDL

SKEL NSKEL N

... ..................

SE

RV

AN

TS

ER

VA

NT500::

500::

OP

ER

AT

ION

OP

ER

AT

ION

100

100

SE

RV

AN

TS

ER

VA

NT500::

500::

OP

ER

AT

ION

OP

ER

AT

ION

11

SE

RV

AN

TS

ER

VA

NT1::

1::

OP

ER

AT

ION

OP

ER

AT

ION

100

100

SE

RV

AN

TS

ER

VA

NT1::

1::

OP

ER

AT

ION

OP

ER

AT

ION

22

SE

RV

AN

TS

ER

VA

NT1::

1::

OP

ER

AT

ION

OP

ER

AT

ION

11

OBJECT ADAPTER

.........

.........IDLIDL

SKEL SKEL 22

OBJECT ADAPTER

(C) LAYERED DEMUXING,PERFECT HASHING


OP

ER

AT

ION

OP

ER

AT

ION

100

100

OP

ER

AT

ION

OP

ER

AT

ION22

.........

OP

ER

AT

ION

OP

ER

AT

ION

11

IDLIDL

SKEL NSKEL N

search(object key)

hash(operation)

IDLIDL

SKEL SKEL 11

(D) DE-LAYERED ACTIVE DEMUXING

hash(object key)

search(operation)

index(object key/operation)

(B) LAYERED DEMUXING,DYNAMIC HASHING

SERVANT SERVANT 500500

� Linear search based on Orbix demuxing strategy

� Perfect hashing based on GNU gperf

{ www.cs.wustl.edu/�schmidt/gperf.ps.gz

� Results at www.cs.wustl.edu/�schmidt/GLOBECOM-97.ps.gz



Demultiplexing Performance Results

1100200300400500

Act

ive

Dem

ux (

1 M

etho

d)

Act

ive

Dem

ux (

10 M

etho

ds)

Act

ive

Dem

ux (

100

Met

hods

)

GP

ER

F (

1 M

etho

d)

GP

ER

F (

10 M

etho

ds)

GP

ER

F (

100

Met

hods

)

Dyn

amic

Has

h (1

Met

hod)

Dyn

amic

Has

h (1

0 M

etho

ds)

Dyn

amic

Has

h (1

00 M

etho

ds)

Line

ar (

1 m

etho

d)

Line

ar (

10 m

etho

ds)

Line

ar (

100

met

hods

)

0

20

40

60

80

100

120

140

Lat

ency

in m

icro

seco

nd

s

Number of Objects

Demultiplexing scheme

� Synopsis

{ Linear search is far toocostly{ Dynamic hashing is too

erratic{ gperf solution is 100%

compatible, but static{ Active demuxing may

not be 100%compatible, but isdynamic



Integrating TAO with RT I/O Subsystem and ATM

REACTORREACTOR

(20 (20 HZHZ))

REACTORREACTOR

(10 (10 HZHZ))

REACTORREACTOR

(5 (5 HZHZ))

REACTORREACTOR

(1 (1 HZHZ))

ORBORB CORECORE

APICAPIC ATMATM DRIVERDRIVER

II//OOSUBSYSTEMSUBSYSTEM

PERPER--VCVC

SOCKETSOCKET

QUEUESQUEUES

APICAPIC PACINGPACING

QUEUESQUEUES

ZZ

EE

RR

OO

CC

OO

PP

YY

BB

UU

FF

FF

EE

RR

SS

� Key Features

{ Vertical integration of QoSthrough ORB, OS, and ATMnetwork{ Provides rate-based QoS

end-to-end{ Leverages APIC features for cell

pacing



Dimensions of ORB Extensibility

1 POSIX,POSIX, WWININ32,32, RTOSRTOSSS,, MVSMVS

3 DLLDLLSS

2

strategy2

strategy1

strategy3 profile2

profile1

profile3

profile4

� Extensible to retarget on new platforms

� Extensible via custom implementation strategies

� Extensible via dynamic con�guration of custom strategies



Applying Patterns to Develop Extensible ORBs

ACCEPTORCONNECTOR

ABSTRACT

FACTORY

SERVANTCLIENT

OS KERNELOS KERNEL

ACTIVE

OBJECT

THREAD-SPECIFIC

STORAGE

SERVICE

CONFIGURATOR

STRATEGY

REACTORREACTOR

WRAPPER FACADESWRAPPER FACADES

www.cs.wustl.edu/�schmidt/ORB-patterns.ps.gz

� De�nition

{ \A recurring solutionto a design problem ina particular context"

� Bene�ts of Patterns

{ Facilitate design reuse{ Preserve crucial design

information{ Guide design choices{ Document common

traps and pitfalls



Addressing ORB Portability and Typesafety Challenges

� Problem

{ Building an ORB using low-level system APIs is hard

� Forces

{ Low-level APIs are tedious to program{ Low-level APIs are error-prone{ Low-level APIs are non-portable

� Solution

{ Apply the Wrapper Facade pattern to encapsulate low-level OSprogramming details



Enhancing Portability and Typesafety with the Wrapper

Facade Pattern

:Wrapper:Wrapper

request()1: request ()

2: specific_request()

:Wrappee:Wrappee

specific_request()

clientclient

� Intent

{ Encapsulates low-level,

stand-alone system

mechanisms within

type-safe, modular, and

portable class interfaces

� Forces Resolved

{ Avoid tedious, error-prone,and non-portable systemAPIs{ Create cohesive

abstractions



Using the Wrapper Facade Pattern in TAO

'

&

$

%

POSIXPOSIXPthreadsPthreads

BSDBSDSocketsSockets

WinSockWinSock

SocketSocketMacrosMacros Other OSOther OS

System CallsSystem Calls

pthread_create()pthread_create()

pthread_mutex_*pthread_mutex_*

socket(), bind(),socket(), bind(),

recv(), send()recv(), send()

gettimeofday(),gettimeofday(),

select(), etc.select(), etc.

SunSoft IIOP's ORB CoreSunSoft IIOP's ORB Core

GENERALGENERAL

POSIXPOSIX &&WWININ3232

SERVICESSERVICES

'

&

$

%

TAO's ORB CoreTAO's ORB Core

spawn()spawn()

acquire()acquire()

open(),open(),

close(),close(),

recv(), send()recv(), send()

dlopen()dlopen()

dlsym()dlsym()

COMMUNICATIONCOMMUNICATION

SUBSYSTEMSUBSYSTEM

VIRTUALVIRTUAL

MEMORY MEMORY

SUBSYSTEMSUBSYSTEM

GENERALGENERAL

POSIXPOSIX && WWININ3232

SERVICESSERVICES

PROCESSPROCESS//THREADTHREAD

SUBSYSTEMSUBSYSTEM

THREADTHREAD

WRAPPERSWRAPPERS

DYNAMIC

LINKING

SELECT/IO COMP

SOCKETS/TLI

ACEWRAPPER

FACADES

handle_events()

SunSoft IIOP TAO

� TAO's wrapper facades are based on ACE

� The Wrapper Facade pattern substantially increased portability andreduced the amount of ad hoc code



Addressing ORB Demuxing and Dispatching Challenges

� Problem

{ ORBs must process many di�erent types of events simultaneously

� Forces

{ Multi-threading is not always available{ Multi-threading is not always e�cient{ Tightly coupling general event processing with ORB-speci�c logic is

in exible

� Solution

{ Use the Reactor pattern to decouple generic event processing fromORB-speci�c processing



Enhancing Demuxing with the Reactor Pattern

Initiation DispatcherInitiation Dispatcher

handle_events()register_handler(h)remove_handler(h)

select (handlers);foreach h in handlers loop h.handle_event(type)end loop

Event HandlerEvent Handler

handle_event(type)get_handle()

handlers

HandleHandle ownsuses

notifies

ConcreteConcreteEventEvent

HandlerHandler

Synchronous EventSynchronous EventDemultiplexerDemultiplexer

select()

1 N

� Intent

{ Decouples

synchronous event

demuxing/dispatching

from event handling

� Forces Resolved

{ Demuxing eventse�ciently within onethread{ Extending applications

without changingdemux infrastructure



Using the Reactor Pattern in TAO'

&

$

%

ORB COREORB CORE

1: RUN EVENT LOOP

OBJECTOBJECT

ADAPTERADAPTER


2: GET REQUEST

3: BLOCK FOR CONNECTION 6: INCOMING

MESSAGE

5: DISPATCH

SERVANTSERVANT

7: UPCALL

GIOPGIOP

EngineEngine4: select()

serverserver

endpointsendpoints

'

&

$

%

ORB COREORB CORE

1: RUN EVENT LOOP

OBJECTOBJECT

ADAPTERADAPTER


3: handle_input()

4: DISPATCH

SERVANTSERVANT

5: UPCALL

ACTIVE OBJECT MAPACTIVE OBJECT MAP

2: select()

ReactorReactor

ConnectionConnectionHandlerHandler



SunSoft IIOP TAO

� The ACE Reactor pattern is widely used by industry



Addressing ORB Endpoint Initialization Challenges� Problem

{ The communication protocol used between ORBs is often orthogonalto its connection establishment and service handler initialization

protocol

� Forces

{ Low-level connection APIs are error-prone and non-portable{ Separating initialization from subsequent processing increases software

reuse for many types of communication software

� Solution

{ Use the Acceptor-Connector pattern to decouple passive/activeconnection establishment and GIOP connection handler initializationfrom the subsequent ORB interoperability protocol (e.g., IIOP)



Enhancing Endpoint Initialization with the

Acceptor-Connector Pattern'

&

$

%

CREATE CREATE &&

ACTIVATEACTIVATE

:Connection:ConnectionHandlerHandler

peer_stream_

open()

:Event:EventDispatcherDispatcher

NOTIFIE

S

NOTIFIE

S

: Strategy: StrategyAcceptorAcceptor

peer_acceptor_

handle_input()

Connection HandlerConnection Handler

'

&

$

%

HANDLE ASYNCHANDLE ASYNC

CONNECTION COMPLETIONCONNECTION COMPLETION

CREATE CREATE &&

ACTIVATEACTIVATE

:Connection:ConnectionHandlerHandler

peer_stream_

open()

:Event:EventDispatcherDispatcher

: Strategy: StrategyConnectorConnector

connect(sh, addr)

complete()

Connection HandlerConnection Handler

Acceptor Structure Connector Structure

� Intent

{ Decouple connection establishment and service handler initialization

from subsequent service processing



Using the Acceptor-Connector Pattern in TAO

'

&

$

%

ORB COREORB CORE1: lookup()

2: connect() 4: accept()

5: read()/write()

5: read()/write()clientclient

endpointendpoint

clientclientendpointendpoint

clientclientendpointendpoint

serverserverendpointendpoint

listenerlistenerendpointendpoint

serverserverendpointendpoint

3: select()3: select()

SERVERCLIENT

'

&

$

%

GIOPGIOP

HandlerHandler

Strategy StrategyConnectorConnector

Cached Cached

ConnectConnect

StrategyStrategy


ReactorReactor

ORBORB CORECORE

SERVERSERVERCLIENTCLIENT

5:5: REQUEST REQUEST//RESPONSERESPONSE

2: connect()2: connect() 3: accept()3: accept()

0..N

6: DISPATCH()

4: CREATE & ACTIVATE

1: operation()

ConnectionHandler

ConnectionHandler

ConnectionHandler

Concurrency

Strategy

StrategyAcceptor

SunSoft IIOP TAO

� Forces Resolved

{ (1) Improve portability and reuse and (2) avoid common mistakes



Addressing ORB Concurrency Challenges

� Problem

{ Multi-threaded ORBs are needed since Reactive ORBs are oftenine�cient, non-scalable, and non-robust

� Forces

{ Multi-threading can be very hard to program{ No single multi-threading model is always optimal

� Solution

{ Use the Active Object pattern to allow multiple concurrent serveroperations using an OO programming style



Enhancing ORB Concurrency with the Active Object

Pattern

Method ObjectsMethod Objects

ClientClientInterfaceInterface

ResultHandle m1()ResultHandle m2()ResultHandle m3()

SchedulerScheduler

dispatch()m1'()m2'()m3'()

loop { m' = actQueue.remove() dispatch (m', resource_rep)}

HI D D E NHI D D E NFROMFROM

CLIENTSCLIENTS

VISIBLEVISIBLETOTO

CLIENTSCLIENTS

1: m1()

2: insert(m1')

3: dispatch()

ActivationActivationQueueQueue

insert()remove()

ResourceResourceRepresentationRepresentation

n

1

� Intent

{ Decouples the thread

of request execution

from the thread of

request reception

� Forces Resolved

{ Allow blockingoperations{ Permit exible

concurrency strategies



Using the Active Object Pattern in TAO'

&

$

%

select()select()

2: NOTIFY

ORB CORE

serverendpoint

REACTIVE

1: ARRIVAL

3: READ

serverendpoint

select()

2: NOTIFY

ORB CORE

serverendpoint

1: ARRIVAL

3: READ

serverendpoint

THREAD-PERCONNECTION

'

&

$

%

Concurrency ConcurrencyStrategyStrategy

ReactorReactor

ORB COREORB CORE

2:2: ACTIVE OR PASSIVE ACTIVE OR PASSIVE??


2a: Task::activate()2a: Task::activate()

1: handle_input()1: handle_input()

3:3: SERVICE REQUEST SERVICE REQUEST

SunSoft IIOP TAO

� TAO supports several variants of Active Objects (e.g., Thread-per-Connection, Thread-per-Request, Thread Pool, Thread-per-Rate, etc.)



Reducing Lock Contention and Priority Inversions with

the Thread-Speci�c Storage Pattern� Problem

{ It is important to minimize the amount of locking required to serializeaccess to resources shared by an ORB

� Forces

{ Locks increase performance overhead

{ Locks increase potential for priority inversion

{ Di�erent concurrency schemes yield di�erent locking costs

� Solution

{ Use the Thread-Speci�c Storage pattern to maximize threading-model exibility and minimize lock contention and priority inversion



Minimizing ORB Locking with the Thread-Speci�c

Storage Pattern

THREAD ATHREAD A THREAD BTHREAD B

1: ACE_OS::thr_getspecific(key)

2: get_state(key)

ORB THREAD-SPECIFIC STATE

POA

Reactor

Acceptor

Connector

POA

Reactor

Acceptor

Connector

THREAD-SPECIFICOBJECT TABLES

INDEXED BY KEY

� Forces Resolved

{ Minimizes overhead and priority inversion

� Intent

{ Allows multiple

threads to use

one logically

global access

point to retrieve

ORB

thread-speci�c

data without

incurring locking

overhead for each

access



Using Thread-Speci�c Storage in TAO

CLIENTCLIENT ORBORB CORECORE

20 10 5 120 10 5 1

HZHZ HZHZ HZHZ HZHZ

CONNECTORCONNECTOR

20 10 5 120 10 5 1

HZHZ HZHZ HZHZ HZHZ

CONNECTORCONNECTOR

20 10 5 120 10 5 1

HZHZ HZHZ HZHZ HZHZ

CONNECTORCONNECTOR

SERVERSERVER ORBORB CORECORE

REACTORREACTOR

(20 (20 HZHZ))

REACTORREACTOR

(10 (10 HZHZ))

REACTORREACTOR

(5 (5 HZHZ))

REACTORREACTOR

(1 (1 HZHZ))

CC

OO

NN

NN

EE

CC

TT

22

AA

CC

CC

EE

PP

TT

OO

RR

CC

OO

NN

NN

EE

CC

TT

11

CC

OO

NN

NN

EE

CC

TT

33

II//OO SUBSYSTEMSUBSYSTEMI/O SUBSYSTEM

C

O

N

N

E

C

T

2

A

C

C

E

P

T

O

R

C

O

N

N

E

C

T

1

C

O

N

N

E

C

T

3

C

O

N

N

E

C

T

2

A

C

C

E

P

T

O

R

C

O

N

N

E

C

T

1

C

O

N

N

E

C

T

3

C

O

N

N

E

C

T

2

A

C

C

E

P

T

O

R

C

O

N

N

E

C

T

1

C

O

N

N

E

C

T

3

COMMUNICATION LINK

CLIENT APPLICATION

STUB STUB STUB



Addressing ORB Flexibility Challenges

� Problem

{ Real-world ORBs must be exible to satisfy the requirements of manydi�erent types of end-users and applications

� Forces

{ Ad hoc schemes for ORB exibility are too static and non-extensible{ Flexibility often has many (related) dimensions

� Solution

{ Use the Strategy pattern to support multiple transparently \pluggable"ORB strategies



Enhancing ORB Flexibility with the Strategy Pattern

StrategyStrategy

algorithm_interface()

ConcreteStrategy A


STRATEGY

ConcreteStrategy B


ConcreteStrategy C


Context

context_interface()

� Intent

{ Factor out similarity

among algorithmic

alternatives

� Forces Resolved

{ Orthogonally replacebehavioral subsetstransparently{ Associating state with

an algorithm



Using the Strategy Pattern in TAO

'

&

$

%

ORB CORE

OBJECT ADAPTER

DEMUXING

CODE

CONCURRENCY

CODE if (do_thread) // take lock...

...

if (do_thread) // releaselock...

CONNECTION

MANAGEMENT

CODE

if (do_thread)

// thread...

else

// single-threaded

'

&

$

%

Thread-Thread-SpecificSpecificConnectConnectStrategyStrategy

Cached CachedConnectConnectStrategyStrategy

Reactive ReactiveConcurrencyConcurrency

StrategyStrategy

Threaded ThreadedConcurrencyConcurrency

StrategyStrategy

SERVANT SERVANT 11 SERVANT NSERVANT N

IDLIDL

SKEL SKEL 22IDLIDL

SKEL NSKEL N

ORB COREORB CORE

SERVERSERVERCLIENTCLIENT

...... ............

SE

RV

AN

TS

ER

VA

NTN

::N

::O

PE

RA

TIO

NO

PE

RA

TIO

NKK

SE

RV

AN

TS

ER

VA

NTN

::N

::O

PE

RA

TIO

NO

PE

RA

TIO

N11

SE

RV

AN

TS

ER

VA

NT1::

1::

OP

ER

AT

ION

OP

ER

AT

ION

KK

SE

RV

AN

TS

ER

VA

NT1::

1::

OP

ER

AT

ION

OP

ER

AT

ION

22

SE

RV

AN

TS

ER

VA

NT1::

1::

OP

ER

AT

ION

OP

ER

AT

ION

11

(B) ACTIVE DEMUXING STRATEGY

index(object key)......

......

(A) PERFECT HASHING

DEMUXING

STRATEGY

OP

ER

AT

ION

OP

ER

AT

ION

KK

OP

ER

AT

ION

OP

ER

AT

ION

22

......

OP

ER

AT

ION

OP

ER

AT

ION

11

hash(operation)

hash(object key) OBJECTOBJECT

ADAPTERADAPTER

IDLIDL

SKEL SKEL 11

SERVANT SERVANT 22

ORB COREORB CORE

ORB COREORB CORE

StrategyStrategyAcceptorAcceptor

StrategyStrategyConnectorConnector

SunSoft IIOP TAO



AddressingORBCon�gurabilityChallenges

�Problem

{AgressiveuseoftheStrategypatterncancreateacon�gurationnightmare

�Forces

{It'shardtomanagelargenumbersofindividuallycon�guredstrategies{It'shardtoensurethatgroupsofsemanticallycompatiblestrategies

arecon�gured

�Solution

{UsetheAbstractFactorypatterntoconsolidatemultipleORBstrategiesintosemanticallycompatiblecon�gurations



CentralizingORBCon�gurabilitywiththeAbstract

FactoryPattern

Abstract Abstract

Factory Factory

make_product_A()

make_product_B()

Abstract Abstract

Product_A Product_A

Concrete Concrete

Factory_1 Factory_1

make_product_A()

make_product_B()

Concrete Concrete

Factory_2 Factory_2

make_product_A()

make_product_B()

Abstract Abstract

Product_B Product_B

Product_B1 Product_B1

Product_A2 Product_A2

Product_B2 Product_B2

Product_A1 Product_A1

�Intent

{Integrateallstrategies

usedtocon�gurean

ORB

�ForcesResolved

{Consolidatescustomizationofmanystrategies{Ensuressemantic

compatibilityofstrategies



Using the Abstract Factory Pattern in TAO

ActiveActive

DemuxingDemuxing

DispatchingDispatching

StrategyStrategy

DemuxingDemuxing

StrategyStrategy

ORBORB

ServerServer

AbstractAbstract

FactoryFactory

Concurrency Concurrency

StrategyStrategy

Perfect Perfect

HashingHashing

Avionics AvionicsConcreteConcreteFactoryFactory

Rate-based Rate-based


Thread- Thread-

per-per-

RateRate

Thread- Thread-

per-per-

ConnectionConnection

Medical MedicalImagingImagingConcreteConcreteFactoryFactory

FIFOFIFO




Addressing ORB Dynamic Con�gurability Challenges

� Problem

{ Prematurely committing ourselves to a particular ORB con�gurationis in exible and ine�cient

� Forces

{ Certain ORB con�guration decisions can't be made e�ciently untilrun-time{ Forcing users to pay for components they don't use is undesirable

� Solution

{ Use the Service Con�gurator pattern to assemble the desired ORBcomponents dynamically



Enhancing Dynamic ORB Extensibility with the Service

Con�gurator Pattern

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

ServiceService

DispatchingDispatchingServiceService

ServiceServiceRepositoryRepository

services

ConcurrencyConcurrencyServiceService

DemuxingDemuxingServiceService

CORBA::ORB_init (int &argc, char *argv[])

{

// Configure the ORB.

Service_Config tao (argc, argv);

// Perform initialization...

}

� Intent

{ Decouples ORB

strategies from time

when they are

con�gured

� Forces Resolved

{ Reduce resourceutilization{ Support dynamic

(re)con�guration



Using the Service Con�gurator Pattern in TAO

Rate-basedRate-basedDispatchingDispatching

TAOTAOPROCESSPROCESS

DLLDLLSS

Thread-per Thread-perRateRate

ConcurrencyConcurrency

AvionicsAvionicsConcreteConcreteFactoryFactory

PerfectPerfectHashingHashing

Service ServiceRepositoryRepository

ActiveActiveDemuxingDemuxing

MedicalMedicalImagingImagingConcreteConcreteFactoryFactory

FIFOFIFODispatchingDispatching

Thread-perThread-perConnectionConnection

ConcurrencyConcurrency

Run-time Con�guration



Quantifying the Bene�ts of Patterns

1 − 5 6 − 10 > 10MVG Range

0.0

10.0

20.0

30.0

40.0

50.0

60.0

70.0

% M

etho

ds in

Ran

geSunSoft IIOPTAO

Macabe Complexity Metric Scores for TAOand SunSoft IIOP

� Statistics

{ Patterns greatlyreduce codecomplexity� e.g., Most TAO

components havev(G) < 10

{ TAO components aresubstantially smallerthan SunSoft IIOP� e.g., connection

managementreduced by a factorof 5



Current Status of TAO

'

&

$

%

DIIDII ORBORBINTERFACEINTERFACE


IDLIDLSTUBSSTUBS

REALREAL--TIMETIME

OBJECTOBJECT

ADAPTERADAPTER

IDLIDLSKELETONSKELETON DSIDSI

in argsin args


CLIENTCLIENT

ORB COREORB CORE

SERVERSERVER

Strategy StrategyConnectorConnector

Cached Cached

ConnectConnect

StrategyStrategy

CLIENTCLIENT

5:5: REQUEST REQUEST//RESPONSERESPONSE

2: connect()2: connect() 3: accept()3: accept()

GIOP GIOP

HandlerHandler0..N

6:6: DISPATCH DISPATCH()()

4:4: CREATE CREATE && ACTIVATE ACTIVATE

1: operation()1: operation()

SERVANTSERVANT

Reactor Reactor Reactor Reactor

Strategy StrategyAcceptorAcceptor

Strategy StrategyAcceptorAcceptor





'

&

$

%

......... ..................

SE

RV

AN

TS

ER

VA

NTN

::N

::O

PE

RA

TIO

NO

PE

RA

TIO

NMM

SE

RV

AN

TS

ER

VA

NTN

::N

::O

PE

RA

TIO

NO

PE

RA

TIO

N11

SE

RV

AN

TS

ER

VA

NT1::

1::

OP

ER

AT

ION

OP

ER

AT

ION

MM

SE

RV

AN

TS

ER

VA

NT1::

1::

OP

ER

AT

ION

OP

ER

AT

ION

22

SE

RV

AN

TS

ER

VA

NT1::

1::

OP

ER

AT

ION

OP

ER

AT

ION

11

OBJECT ADAPTER

.........

.........IDLIDL

SKEL SKEL 22

(A) LAYERED DEMUXING,PERFECT HASHING


OP

ER

AT

ION

OP

ER

AT

ION

MM

OP

ER

AT

ION

OP

ER

AT

ION

22

.........

OP

ER

AT

ION

OP

ER

AT

ION

11

IDLIDL

SKEL SKEL KK

hash(operation)

IDLIDL

SKEL SKEL 11

(C) DE-LAYERED ACTIVE

DEMUXING

hash(object key) index(object key/operation)

(B) LAYERED DEMUXING,DYNAMIC HASHING

SERVANT SERVANT NN

ORB CORE

OBJECT ADAPTER

ORB CORE

ORBORBCORECORE

GIOPGIOP//IIOPIIOP

DIIDII ORBORBINTERFACEINTERFACE


IDLIDLSTUBSSTUBS OBJECTOBJECT

ADAPTERADAPTER

IDLIDLSKELETONSKELETON DSIDSI

in argsin args


CLIENTCLIENT SERVANTSERVANT



TAOProjectSummary

�CurrentFocus:High-performance,Real-timeORBs

{Reducinglatencyviade-layeredactivedemuxing

{ApplyingoptimizationprinciplestoTypeCodeinterpreter{EnforcingperiodicdeadlinesviaReal-timeORBendystem

�i.e.,supportstaticschedulingforCORBArequests{Applyingoptimizationprinciplestopresentationlayer

�FutureWork

{Pinpointnon-determinismandpriorityinversionsinORBs{Dynamicschedulingofrequests{DistributedQoSandintegrationwithRTI/OSubsystem{IDLcompilerandoptimizedstubgeneration{TypeCodecompileroptimizations



ConcludingRemarks

�Developersofdistributedapplicationsconfrontrecurringchallengesthatarelargelyapplication-independent

{e.g.,serviceinitializationanddistribution,errorhandling, owcontrol,eventdemultiplexing,concurrencycontrol,persistence,faulttolerance

�Successfuldevelopersresolvethesechallengesbyapplyingappropriatedesignpatternstocreatecommunicationframeworksandcomponents

�ORBsareane�ectivewaytoachievereuseofdistributedsoftwarecomponents

�Thenext-generationofORBswillprovidemuchbetterQoSsupport


using and developing r fo atterns p - vanderbilt universityschmidt/pdf/tao2.pdf · using and...

Documents