Design & Evaluation of a Highly Modular CORBA Portable Object Adapter Arvind S. Krishna Info & Comp. Sci. Dept University of California, Irvine Distributed Objects & Applications (DOA) Conference 23 November 2015 Raymond Klefstad Douglas C. Schmidt Elec & Comp. Eng. Dept

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 R&D efforts

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

Micro-ORB vs. Monolithic ORB Designs Problem memory constraints Implementing a full service, flexible ORB can lead to monolithic ORB implementation Embedded Systems often have severe. memory constraints Context Standards-based middleware (e.g CORBA) must provide a wide range of features, each may have a variety of behavior options Achieving a small footprint must be a fore thought

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

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

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 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 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 POA Policies We decompose the POA across policies

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

Thread Policy Strategy Implements the POA’s Thread policy Values are Single Thread Strategy ORB Control Strategy Each strategy contains the mechanism of enforcing the policy value Construction Process Based on Thread policy value specified either the Single thread strategy / ORB control strategy is plugged into the POA Responsibilities Request execution follows appropriate threading model in the POA. E.g Serialization of calls using the enter() and exit() methods

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 Implements Lifespan Policy Values are Transient Strategy Persistent Strategy

Activation Policy Strategy 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 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 Implements the Activation Policy Values –Implicit Activation Strategy (flyweight) –Explicit Activation Strategy (flyweight)

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

Id Assignment Policy Strategy Overview Implements the Id Assignment Policy Values are System Id Strategy User Id Strategy Responsibilities Encapsulates Id generation strategy of the POA. POA uses create() method to get the next id. Depending on the concrete implementation plugged in, Next id is generated Wrong Policy Exception raised

Id Uniqueness Policy Strategy Overview Dictates the relationship between servants and their objects in the POA. Either one to one or many to one Values are Unique Id Multiple Id Responsibilities POA operations like activate_object call the validate() method on the strategy to check if registration of servants is permitted.

Servant Retention Policy Strategy Overview Implements the semantics of Servant Retention Policy Values Strategized into Retain and Non Retain Strategy Responsibilities Aid in object id based and servant based lookup operations in the POA. Non Retain Strategy raises WRONG_POLICY exception for lookup operations Retain Strategy contains Active Object Map to maintain associations between objects and servants AOM further strategized into Single and Dual Maps based on Id Uniqueness Policy value.

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 Secondary components depend on the values of primary components Other secondary components: Id Assignment, Servant Retention, Id Uniqueness Strategies

Fine Grain POA Architecture: Summary Consider example POAs A and B with the following policy values

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 Results –ZEN ~ 61 k.B –JacORB ~ 180 k.B ZEN: Latest Version JacORB: Version 1.4 beta 4 Dual-CPU 1.7GHz Xenon (512Mb RAM) –Debian Linux 2.4.1, – javac compiler, JDK 1.4 JVM

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 Results –ZEN ~ 35 k.B –JacORB ~ 250 k.B

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 ZEN’s 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 Results –Average child POA creation time ZEN ~ 0.17 msecs JacORB ~ 0.88 msecs –JacORB 7 times slower

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 ZEN Solution Use Active Demultiplexing and Perfect Hashing to ensure O(1) worst case time bound for all the demultiplexing stages Demuxing Strategies Linear Search, Binary Search,Dynamic Hashing, Perfect Hashing and Active Demultiplexing

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 Active Demultiplexing ensures O(1) worst case lookup time for POA Demultiplexing Dual-CPU 1.7GHz Xenon (512Mb RAM) –Debian Linux 2.4.1, – javac compiler, JDK 1.4 JVM

ZEN Servant Demultiplexing Active Demultiplexing ensures O(1) worst case Servant lookup time Active Demultiplexing ensures O(1) worst case Servant lookup time 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

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

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

References ZEN open-source download & web page: JacORB web page: Real-time Java (JSR-1): jsr_001_real_time.html Dynamic scheduling RFP: Dynamic_Scheduling_RFP.html Distributed Real-time Java (JSR-50): jsr_050_drt.html AspectJ web page: JRate