Towards Highly Configurable Realtime Object Request Brokers

1
Towards Highly Configurable Real-time Object
Request Brokers

• Raymond Klefstad, Douglas C. Schmidt, Carlos
  ORyan
• klefstad,schmidt,coryan_at_uci.edu
• Electrical Computer Engineering Dept
• University of California, Irvine

2
Motivation for QoS-enabled Middleware

• Trends

• Building distributed systems is hard
• Building them on-time under budget is even
  harder

• Many mission-critical distributed applications
  require real-time QoS guarantees
• e.g., combat systems, online trading, telecom
• Building QoS-enabled applications manually is
  tedious, error-prone, expensive
• Conventional middleware does not support
  real-time QoS requirements effectively

3
CORBA Overview

• Common Object Request Broker Architecture (CORBA)
• A family of specifications
• OMG is the standards body
• Over 800 companies
• CORBA defines interfaces, not implementations
• It simplifies development of distributed
  applications by automating/encapsulating
• Object location
• Connection memory mgmt.
• Parameter (de)marshaling
• Event request demultiplexing
• Error handling fault tolerance
• Object/server activation
• Concurrency
• Security

• CORBA shields applications from heterogeneous
  platform dependencies
• e.g., languages, operating systems, networking
  protocols, hardware

4
Overview of Real-Time CORBA

• Real-time CORBA adds QoS control to regular CORBA
  to improve application predictability, e.g.,
• Bounding priority inversions
• Managing resources end-to-end
• Policies mechanisms for resource configuration
  control in Real-time CORBA include
• Processor Resources
• Thread pools
• Priority models
• Portable priorities
• Communication Resources
• Protocol policies
• Explicit binding
• Memory Resources
• Request buffering

These capabilities address some (but by no means
all) important distributed real-time embedded
application development challenges
5
Motivations for Using Java Real-time Java

• Easier, faster development
• Memory management is simpler
• Language support for concurrency and
  synchronization
• Large and powerful library, including portable
  GUI
• Dynamic language features (e.g., class loading,
  reflection)
• Large programmer base
• 1,000,000 developers (and growing)
• Taught at many universities
• Easily picked up by C, Ada Programmers
• Recent Real-time Java Specification
• Provides features designed for real-time
  programming

6
Real-time Spec for JAVA (RTSJ) Overview

• Memory Management
• Scoped Memory
• Disposed as a whole after the scope is exited.
• Similar to stack memory in C
• ScopedMemory sm new sm.enter()
• sm.newInstance(Class.forName(Vector))
• Limitations on access to/from Heap
• Lifetime is from creation to exit of last thread
  sharing it
• Immortal Memory
• Lifetime is from creation to program exit
• Physical (and ImmortalPhysical) Memory
• PhysicalMemory NVRam new PhysicalMemory(
  0xFF00, 1024)
• Allows access to raw physical memory addresses
• int i NVRam.getInt( 0x0A ) NVRam.setInt( 0x0A,
  i1 )
• Primitives only!
• Heap Memory regular garbage-collected heap

7
RTSJ Overview (cont.)

• Stronger guarantees on threads
• Highest priority runnable thread is always run
• Faster context switching
• 1-2 Microseconds down from 100s
• Asynchronous Event Handlers (AEH)
• Similar to Unix Signals and handlers
• Own no resources
• Run in context of current thread
• Cant pass data to them
• Asynchronous transfer of control
• Java Can interrupt only when thread is in
  wait(), sleep() or join()
• RT-Java can interrupt methods at any time
  (Asynchronous)
• Will wait until critical sections are exited
• Extensive Scheduling support
• Schedulable Objects (threads, AEHs), Admission
  control, feasibility analysis
• Extend base fixed-priority preemptive scheduler
  to fit needs

8
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

9
Goals of the ZEN Real-time ORB Project

• Flexible Configuration
• Small footprint
• Load classes only as needed
• On-demand or at initialization time
• Easily Extensible
• Code and compile new alternatives
• Dynamically plug them in/out of the ORB
• e.g., new protocols, Object Adapters, IOR
  formats, etc.
• 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

10
Five Generations of ORB Designs

• Standards-based middleware (ORB) must provide a
  wide range of features, many have a variety of
  behavior options
• 1st Generation Static monolithic ORB
• All support code is in one executable,
• OS virtual memory manages footprint
• Footprint too large for some applications
• e.g., original implementation of TAO,
• many other conventional ORBs
• 2nd Generation Monolithic ORB with
• compile-time configuration flags
• Conditional compilation or smart linkers
• remove unwanted parts of middleware
• scores of options can overwhelm the application
  developer
• accidental complexity due to conditional
  compilation
• e.g., second generation of TAO

11
Five Generations of ORB Designs (cont.)

• 3rd Generation Dynamic micro-ORB
• Small kernel of required functionality
• Various components are linked/loaded on-demand
• e.g., newest version of TAO ZEN, GOPI
• 4th Generation Dynamic reflective micro-ORB
• ORB builds a configuration description for each
  application based on the applications execution
  history
• This description is used to prime the ORB,
  loading required components at initialization-
  run-time
• e.g., dynamicTAO
• 5th Generation Static reflective micro-ORB
• Application configuration needs are learned by
  dynamic reflective micro-ORB above
• Model-based generator builds a custom-ORB for
  each application, which can then be compiled
  placed into ROM

12
ZEN Development Process

• Start with a flexible, extensible design based on
  TAO pattern language

• Version 1 Focus on 3rd Generation
• Dynamic micro-ORB to identify pluggable
  components
• Focus on real-time requirements implementing
  Real-time CORBA features in Real-time Java
• Version 2 Focus on 4th Generation
• Learn from reflection which components are likely
  to be used preload them at initialization-time
• Version 3 Focus on 5th Generation
• Static custom ORB generation
• Use reflection aspects
• Statically configure trim unused components
  automatically

www.posa.uci.edu
13
Micro-ORB vs. Monolithic ORB Designs

• Lessons learned from building TAO
• Implementing full-service, flexible ORB can yield
  a monolithic implementation with large footprint
• Patterns resolve design forces yield highly
  modular, extensible designs
• Achieving a small footprint must be an initial
  design goal
• ZENs design based on Micro-kernel pattern
  (POSA1)
• 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

14
Virtual Component Pattern

• Intent
• Application transparent mechanism to factor out
  components that arent currently needed
• Solution
• Use abstract interfaces for all components
• Upon component-fault load concrete
  implementations using
• Factory method Repository
• Strategy pattern
• Proxy component

Abstract Interfaces
15
Pluggable GIOP Messaging Handling

• Context
• Eight different message types
• Two methods for each read/write
• Three different versions of GIOP
• (and counting)
• Client/server applications only
• require a few of 48 methods
• Problem
• Monolithic ORBs must have code to handle all
  cases
• Solution
• Apply Virtual Component pattern to factor out
  each method
• Only two methods are required for typical server,
  two others for typical client

16
ZENs Pluggable Object Adapters

• Context
• Object Adapter maps client requests to server
  servants
• Three types of POAs
• Standard POA For non-real-time applications
• Minimum POA Reduce memory footprint features
• Real-time POA Ensures predictability required
  for real-time systems

• Problem
• Only servers or peers need an Object Adapter,
  clients do not need one
• Even servers only need a few of the features of a
  POA
• Solution
• Apply Virtual Component pattern to allow
  pluggable POA
• Also divide POA into smaller components units
  that can be loaded as needed

17
ZENs Pluggable POA (cont.)

• Strategized POA Policies
• POA policies can be dynamically loaded
  configured
• Servant Retention
• ID Uniqueness
• Lifespan
• Request Processing
• Policy Factory sets handles POA creation and
  configuration
• Consider policy factory in the Interceptor spec.

18
ZENs Pluggable Transport Protocols

• Context
• GIOP can run on many protocol
• transports
• e.g, TCP/IP, shared memory, SSL
• 20 to 30 classes may be required to
• support all common transport
• protocols
• Problem
• Monolithic implementation may use if/switch
  statements
• Or may choose only one transport, e.g., TCP/IP
• Solution
• Apply Virtual Component pattern, only load
  classes required
• Both client and server need Transport Address
  class
• Server also needs Acceptor Reactor classes
• Client also needs Connector class
• Only required classes are loaded specific to the
  transport being used

19
ZENs Pluggable Any Handlers

• Context
• Corba any data type is useful for
• generic services because it may
• hold any data type

• Problem
• Monolithic implementations must include
• methods to read and write each primitive data
  type, user-defined types arrays, sequences
• Solution
• Apply Virtual Component pattern to factor out all
  this code
• It is loaded upon first use, only methods dealing
  with the specific type used are loaded

20
ZENs Pluggable IOR Parsers

• Context
• IORs are CORBAs powerful object pointers
• May point to servant across the net in another
  process
• CORBA supports various formats for IORs
• Problem
• Monolithic implementation must include code to
  recognize format and parse, then handle each IOR
  format

• Solution
• Apply the Virtual Component pattern to factor out
  each IOR format handler
• Each handler is loaded only when the particular
  format is encountered

21
ZENs Pluggable Object Resolvers

• Context
• ORBresolve_initial_references
• (stringname) allows applications to
• get IOR for ORB objects
• Examples include RootPOA,
• NameService, EventChannel
• Problem
• Monolithic ORB may use if statements to match
  name string or table lookup, all code for
  handling is resident
• Solution
• Apply the Virtual Component pattern to factor out
  handling of each string into a class
• Class name is based on the object string, e.g.,
  rootPOAResolver
• Only load classes for names used

22
Other Pluggable ORB Services

• Message Buffer Allocators
• Allows different algorithms to be plugged-in
• CDR stream reader/writers
• Vary with the endian of the local machine
• Little endian has one set of readers/writers
• Big endian has a different set

• Pluggable IOR Parsers
• Each handler is loaded only when the particular
  format is encountered
• Pluggable Object Resolvers
• Only load classes for names used

23
Performance Measurements

• ORB Benchmarking Testbed
• Hardware OS
• Dual-CPU 1.7GHz Xenon (512Mb RAM)
• Debian Linux 2.4.1, javac compiler, JDK 1.4 JVM
• ORBs
• JacORB Version 1.3
• ZEN Latest Version (CVS)
• TAO Version 5.2.2

• Benchmark Application Results
• Application overview
• Two-Way call passing long, returning long
• 100,000 calls, using loopback (on same machine)
• Roundtrip throughput
• JacORB 1,200 calls/second
• ZEN 1,300 calls/second
• TAO 8,000 calls/second

• Next steps
• Use ahead of time compiler for Real-time Java
  (jRate)
• Integrate with TimeSys RTSJ Reference
  Implementation

24
Performance Measurements

• Testbed (comparing ZEN to JacORB)
• On dual-CPU 1.7GHz Xenon (512Mb RAM)
• Debian Linux 2.4.1, javac compiler, JDK 1.4 JVM
• Two-Way call passing long, returning long
• 100,000 calls, using loopback (on same machine)
• ZEN Latest Version
• JacORB Version 1.4
• (Latest version)
• Roundtrip Throughput
• ZEN 1,295 calls/second
• JacORB 1,436 calls/second
• (TAO 8000 calls/second)

25
Memory Footprint Measurements

• Memory Sizes (in KB)
• ZEN JacORB TAO
  
• server 2,539 3,186 2,075
• client 2,527 2,985 1,567
• But Default JVM size 2194KB!
• Compare to
• libTAO size 1259KB
• libTAOPortable_Server size 510KB
• (TAO Test compiled using gcc-2.91 and static
  libraries.)
• As smaller JVM implementations become available
  ZEN TAO code size will be more comparable

26
Performance Measurements

• Testbed (comparing ZEN to JacORB)
• On dual-CPU 1.7GHz Xenon (512 MB RAM)
• Debian Linux 2.4.1, javacc compiler, JDK 1.4 JVM
• Two-Way call passing long, returning long
• 100,000 calls, using loopback (on same machine)
• ZEN
• Round-trip time 1,295 calls per second
• Memory footprint server 2,539KB, client
  2,527KB
• JacORB
• Round-trip time 1,436 calls per second
• Memory footprint server 3,186KB, client 2,985KB

27
Current Status of ZEN

• Functional Java-based ORB with POA, GIOP, IDL
  compiler, etc.
• Interoperable with the TAO C ORB
• Missing COS Services, DII/DSI
• Current focus is on
• Factoring out more functionality from the ORB
  core to reduce footprint
• Completing Real-time CORBA support utilizing
  Real-time Java features
• Ahead-of-time Real-time Java integration
• Using aspects for static custom configuration
• Available as open-source at www.zen.uci.edu

28
Future Work

• Research Issues
• Utilizing RT Java features within the ORB for RT
  CORBA
• Evaluation of performance of various pluggable
  ORB core services
• Using aspects with reflection to custom
  generation ORBs
• Real-Time Dynamic Scheduling
• Reflection Dynamic reconfiguration, power
  management, etc.

29
Concluding Remarks

• ZEN is a starting point for an open research
  platform for distributed, real-time, embedded
  (DRE) systems middleware developed using
  Real-time Java
• Pluggable architecture is comparable in speed to
  monolithic Java ORB implementations, yet with
  smaller footprint

• Open issues
• Real-time CORBA dynamic scheduling is not yet
  fully integrated into CORBA specification
• Conformant implementations of Real-time Java only
  recently available
• Real-time Java features largely
  unnecessary/unusable for Real-time CORBA
• Interoperability with Distributed Real-time Java
  (JSR-50)
• Integration with representative DRE demonstration
  platforms

30
URLs for Further Reference

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