Design

1
Design Evaluation of a Highly Modular CORBA
Portable Object Adapter
Raymond Klefstad Douglas C. Schmidt Elec Comp.
Eng. Dept klefstad_at_uci.edu schmidt_at_uci.edu
Arvind S. Krishna Info Comp. Sci. Dept
Krishnaa_at_uci.edu
University of California, Irvine Distributed
Objects Applications (DOA) Conference 29
January 2014
2
Motivation for ZEN Real-time ORB

• Integrate best aspects of several key
  technologies
• Java Simple, less error-prone, large user-base
• Real-time Java Real-time support
• CORBA Standards-based distributed applications
• Real-time CORBA CORBA with Real-time QoS
  capabilities
• ZEN project goals
• Make development of distributed, real-time,
  embedded (DRE) systems easier, faster, more
  portable
• Provide open-source Real-time CORBA ORB written
  in Real-time Java to enhance international
  middleware RD efforts

3
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

4
Micro-ORB vs. Monolithic ORB Designs

• Context
• Standards-based middleware (e.g CORBA) must
  provide a wide range of features, each may have a
  variety of behavior options

• Problem
• memory constraints Implementing a full service,
  flexible ORB can lead to monolithic ORB
  implementation
• Embedded Systems often have severe.memory
  constraints

Achieving a small footprint must be a fore thought
5
Micro-ORB vs. Monolithic ORB Designs

• Solution
• Identify core ORB services whose behavior may
  vary
• Move each core ORB service out of the ORB by
  applying the Virtual Component pattern
• Implement pluggable alternatives
• Remaining kernel is micro-ORB kernel

• Candidate services for applying the Virtual
  Component Pattern include
• Object Adapters, IOR Parsers, GIOP Message
  handlers, CDR Stream readers/writes, Any handlers
  and protocol transports

6
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
7
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
8
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
• Apply Virtual Component pattern to allow the POA
  to be plugged in/out as one piece

This level of granularity has been implemented in
TAO
But we can we do better and reduce the footprint
of servers peers?
9
Fine-Grained POA Pluggability
POA Policies

• POAs 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

• Request Processing Policy
• Use Active Object Map Only
• Use Default Servant
• Use Servant Manager
• Implicit Activation Policy
• Implicit Activation
• No Implicit Activation
• Lifespan Policy
• Persistent
• Transient

• Thread Policy
• - Single Thread Model
• - ORB Control Model
• - Main Thread Model
• Id Assignment Policy
• - System Id
• - User Id
• Id Uniqueness Policy
• - Unique Id
• - Multiple Id
• Servant Retention
• Policy
• - Retain
• - Non Retain

• We decompose the POA across policies

10
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

11
Thread Policy Strategy

• Implements the POAs Thread policy
• Values are
• Single Thread Strategy
• ORB Control Strategy
• Each strategy contains the mechanism of enforcing
  the policy value

12
Lifespan Policy Strategy

• Responsibilities
• Object key validation
• Maintain POA time stamps
• POA uses the validate() method to check
  freshness of the object key.
• Transient strategy compares time stamp values

13
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

14
Secondary POA Components

• Secondary components depend on the values of
  primary components
• These dependencies may lead to conflicts
• When two policies cannot coexist they are said to
  be in conflict.
• Example Implicit Activation policy value and User
  Id policy value cannot coexist.
• Conflicts are identified at strategy creation
  time

• Secondary Components include
• Id Assignment Strategy
• Servant Retention Strategy
• Id Uniqueness Strategy
• Request Processing Strategy

15
Id Assignment Policy Strategy

• Overview
• Implements the Id Assignment Policy
• Values are
• System Id Strategy
• User Id Strategy

16
Id Uniqueness Policy Strategy

• Responsibilities
• POA operations like activate_object call the
  validate() method on the strategy to check if
  registration of servants is permitted.

17
Servant Retention Policy Strategy

• Overview
• Implements the semantics of Servant Retention
  Policy

• Responsibilities
• Aid in object id based and servant based lookup
  operations in the POA.
• Non Retain Strategy raises WRONG_POLICY exception
  for lookup operations

18
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

19
Fine Grain POA Architecture Summary
Consider example POAs A and B with the following
policy values
20
Root POA Footprint Analysis

• 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
• 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

• Results
• ZEN 61 k.B
• JacORB 180 k.B

21
Child POA Footprint Analysis

• 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)

• Results
• ZEN 35 k.B
• JacORB 250 k.B

22
Child POA Creation Time Metrics

• Overview
• Many applications create a child POA as a side
  effect of an up call
• Slow creation time in this scenario could
  decrease jitter and increase throughput
• ZENs POA design decreases creation time as most
  of the components are implemented as Flyweights
• Experiment
• Variation in child POA creation time measured
  with the number of POAs created
• POAs created have default policies (involve least
  number of flyweights)

• Results
• Average child POA creation time
• ZEN 0.17 msecs
• JacORB 0.88 msecs
• JacORB 7 times slower

23
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

24
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

25
ZEN POA Demultiplexing

• Overview
• The first step involved in request demultiplexing
  is finding the Object Adapter
• The POA Hierarchy can be arbitrarily nested
• Test Description
• Variation in POA demultiplexing time with the
  depth of the POA hierarchy measured
• Result Synopsis
• Active Demultiplexing provides constant latency
  irrespective of POA hierarchy
• Dynamic Hashing degrades with depth

• Dual-CPU 1.7GHz Xenon (512Mb RAM)
• Debian Linux 2.4.1,
• javac compiler, JDK 1.4 JVM

Active Demultiplexing ensures O(1) worst case
lookup time for POA Demultiplexing
26
ZEN Servant Demultiplexing

• Overview
• The POA finds the servant associated with the
  object
• 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

Active Demultiplexing ensures O(1) worst case
Servant lookup time
27
ZEN Operation Demultiplexing

• Overview
• The last step at the Object Adapter layer is to
  demultiplex request to the appropriate skeleton
• Operation dispatch time varies with the number of
  methods in the interface
• Test Description
• Variation in Operation Demultiplexing latency
  measured with number of methods
• Result Synopsis
• Dynamic hashing has higher overhead and degrades
  4 u.s
• Perfect hashing guarantees constant time bound
  1 u.s

Perfect Hashing ensures O(1) worst case operation
demultiplexing time
28
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

29
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