Design & Evaluation of a Highly Modular
CORBA Portable Object Adapter
Raymond Klefstad
Douglas C. Schmidt
Elec & Comp. Eng. Dept
klefstad@uci.edu
schmidt@uci.edu
Arvind S. Krishna
Info & Comp. Sci. Dept
Krishnaa@uci.edu
University of California, Irvine
Distributed Objects & Applications (DOA) Conference
21 March 2016
Technical Goals for the ZEN Real-time ORB
• Real-time CORBA using Real-time Java
• Easily Extensible
• Code and compile new alternatives
• Dynamically “plug” them in/out of the ORB
• e.g., new protocols, Object Adapters, IOR
formats, etc.
• Flexible Configuration
• Small footprint
• Load components only as needed
• On-demand or at initialization time
• Real-time performance
• Bounded jitter for ORB/POA operations
• Eliminate sources of priority inversion
• Access to Real-time Java features in ORB
by applications
• Low startup latency
Virtual Component Design Pattern
Intent
• Application transparent way of loading and
unloading components implementing
middleware functionality
Problem
• Features and options for standards based
middleware are large and growing
• Few embedded applications use all the
functionality provided
• Cannot eliminate capabilities based on any
particular embedded system
Solution
• Identify components whose interfaces
represent building blocks
• Define concrete components that implement
capabilities
• Define factories that create the concrete
components using a set of loading/
unloading strategies
ZEN applies the Virtual Component pattern
to the CORBA Portable Object Adapter
What is a Portable Object Adapter (POA)?
• A POA maps remote client requests to local
servants
• Capabilities
• Generate Object References
• Activate/objects
• Incarnate/Etherealize servants
• Demultiplex client requests to the
appropriate servants
• Customization based on policies
• Key Components
• Adapter Activator
• Servant Managers
• POA Manager
• The POA is a large chunk of code: adds considerably to server footprint
• To reduce foot print apply the Virtual Component Pattern to make POA pluggable
Two levels of pluggability: (1) Coarse grained & (2) Fine grained
Coarse Grained Pluggability
•Context
•A POA maps client requests to server servants
•Several types of POAs:
•Standard POA: For non-real-time applications
•Min POA: Reduce memory footprint & features
•Real-time POA: Ensures predictability required for real-time systems
•Problem
•Each application needs
only one type of POA
•Moreover, Servers and
peers need a POA, but
clients do not
•Solution
This level of granularity has been
Apply Virtual Component pattern to
allow the POA to be plugged in/out
implemented in TAO
as one piece
But we can we do better and reduce the footprint of servers & peers?
Fine-Grained POA Pluggability
•POA’s behavior is governed
by the policies associated
with it
•Servers need only a few of
the features provided by a
POA
–Many applications use
only a Root POA
–Root POA has only one
policy value from each
policy (indicated in red)
associated with it
•We decompose the POA
across policies
POA Policies
Thread Policy
- Single Thread Model
- ORB Control Model
- Main Thread Model
Request Processing Policy
- Use Active Object Map Only
- Use Default Servant
- Use Servant Manager
Id Assignment Policy
- System Id
- User Id
Implicit Activation Policy
-Implicit Activation
-No Implicit Activation
Id Uniqueness Policy
- Unique Id
- Multiple Id
Servant Retention
Policy
- Retain
- Non Retain
Lifespan Policy
-Persistent
-Transient
Fine-Grain POA Architecture
• Implement each policy value as
a Virtual Component
• E.g Servant Retention Policy
• Retain
• Non Retain
• Each policy value is a different
mechanism of enforcing the
policy
• Load only the components
required based on policy values
• POA Policy factory creates a
concrete strategy for each of
the abstract strategy
Activation Policy Strategy
• Implements the Activation Policy
• Values
–Implicit Activation Strategy (flyweight)
–Explicit Activation Strategy (flyweight)
• Responsibilities
–Validates operations that implicitly
activate servants:
_this(),
servant_to_reference()
validate() method on the concrete
Activation strategy associated
allows/disallows implicit Activation
• Thread, Lifespan, and Activation Strategies are “Primary POA Components”
• They are composed first during POA creation
• The primary components associated with the POA influence rest of the strategies
Request Processing Policy Strategy
• Overview
• Implements the Request Processing
policy
• Strategized along
• Active Object Map Only Strategy:
• Default Servant Strategy
• Servant Manager Strategy
• Servant Locator Strategy
• Servant Activator Strategy
• Responsibilities
• Handle client requests
• handleRequest() method
uses the Strategy plugged in
to service client requests
• Secondary components depend on the values of primary
components
•Other secondary components:
•Id Assignment, Servant Retention, Id Uniqueness Strategies
Root POA Footprint Analysis
Dual-CPU 1.7GHz Xenon (512Mb RAM)
–Debian Linux 2.4.1,
– javac compiler, JDK 1.4 JVM
ZEN: Latest Version
JacORB: Version 1.4 beta 4
Root POA size
200
180
160
140
120
Size kB
Overview
• Root POA is the base POA for all POAs
created in an ORB
• A Root POA suffices for many
applications unless different QoS
guarantees needed, e.g object
persistence
ZEN
100
JacORB
80
Experiment
• Measures the footprint increase prior
and after the call to
resolve_initial_references(“RootPOA”)
• In particular, the increase in “process
space” was measured after the
association of the Root POA with the
Server
60
40
20
0
1
Root POA
Results
–ZEN ~ 61 k.B
–JacORB ~ 180 k.B
Child POA Footprint Analysis
Child POA Size
1000
100
Size in kB
Overview
• Child POA created if different QoS
guarantees required than provided
by Root POA
• Using the Micro POA design
• considerably reduces the foot
print
• scale as most of the
components implemented as
flyweights
Experiment
• Variation in footprint with the number
of POAs created measured
• The increase in footprint prior to and
after a create_POA method call
measured in each of the
• POAs created have the following
policy values: User Id, Non Retain
and Servant Manager. (Maximizes
number of flyweights)
ZEN
JacORB
10
1
10
25
50
75
100
125
150
200
Number of POAs
Results
–ZEN ~ 35 k.B
–JacORB ~ 250 k.B
POA Demultiplexing Steps
Context
• A key functionality of a CORBA
ORB is to demultiplex client
requests to the appropriate
servants
Problem
• Conventional Layered
demultiplexing approach
inefficient, causes increased
priority inversions
Factors:
• The POA hierarchy is arbitrarily
deep
• and/or the POA is managing a
large number of Servants
• and/or a Servant implements an
interface with a large number of
operations
POA Demultiplexing Strategies
Demuxing Strategies
• Linear Search, Binary
Search,Dynamic Hashing,
Perfect Hashing and Active
Demultiplexing
ZEN Solution
• Use Active Demultiplexing and
Perfect Hashing to ensure O(1)
worst case time bound for all
the demultiplexing stages
ZEN POA Demultiplexing
Dual-CPU 1.7GHz Xenon (512Mb RAM)
Overview
–Debian Linux 2.4.1,
• The first step involved in request
– javac compiler, JDK 1.4 JVM
demultiplexing is finding the
Object Adapter
POA Demultiplexing
• The POA Hierarchy can be
60
arbitrarily nested
50
Test Description
• Variation in POA demultiplexing
40
time with the depth of the POA
Latency(us) 30
Dynamic Hashing
hierarchy measured
Active Demultiplexing
20
Result Synopsis
10
• Active Demultiplexing provides
constant latency irrespective of
0
1
25 50 75 100 125 150 175 200
POA hierarchy
Depth of POA Hierarchy
• Dynamic Hashing degrades with
Active Demultiplexing ensures O(1)
depth
worst case lookup time for POA
Demultiplexing
ZEN Servant Demultiplexing
Overview
Servant Demultiplexing
• The POA finds the servant
associated with the object
60
• A POA can manage arbitrary
number of objects in the
AOM
Test Description
• Latency variations with the
increase in number of
servants measured
Result Synopsis
• Dynamic Hashing higher
overhead, degrades with
number of servants
• Active Demultiplexing
provides constant time
latency
50
40
Latency (us) 30
Dynamic Hashing
Active Demultiplexing
20
10
0
1
250 500 750 1000 1250 1500 1750 2000
Num ber of Objects
Active Demultiplexing ensures O(1)
worst case Servant lookup time
ZEN Operation Demultiplexing
Overview
• The last step at the Object
Adapter layer is to demultiplex
request to the appropriate
skeleton
Operation Demultiplexing
5
• Operation dispatch time varies
with the number of methods in the
interface
Test Description
• Dynamic hashing has higher
overhead and degrades ~ 4 u.s
• Perfect hashing guarantees
constant time bound ~ 1 u.s
4
3.5
3
Latency (us) 2.5
• Variation in Operation
Demultiplexing latency measured
with number of methods
Result Synopsis
4.5
Perfect Hashing
2
Dynamic Hashing
1.5
1
0.5
0
1
5
10
20
30
40
50
Number of methods
Perfect Hashing ensures O(1) worst
case operation demultiplexing time
Future Research on ZEN
• Complete implementation of RT
CORBA specification
• Utilizing RT Java features within the
ORB and POA for RT CORBA
• Ahead of time compile ZEN using jRate
• TimeSys RTSJ implementation
• Using Aspects to custom generate
ORBs
• Extend the pluggable protocol
framework to handle other protocols
run()
{
------------------}
Scoped Memory
SM Deallocated as
whole
References
• ZEN open-source download & web page:
• http://www.zen.uci.edu
• JacORB web page:
• http://www.jacorb.org
• Real-time Java (JSR-1):
• http://java.sun.com/aboutJava/communityprocess/jsr/
jsr_001_real_time.html
• Dynamic scheduling RFP:
• http://www.omg.org/techprocess/meetings/schedule/
Dynamic_Scheduling_RFP.html
• Distributed Real-time Java (JSR-50):
• http://java.sun.com/aboutJava/communityprocess/jsr/ jsr_050_drt.html
• AspectJ web page:
• http://www.aspectJ.org
• JRate
• http://tao.doc.wustl.edu/~corsaro/jRate/