Highly Configurable Real-time Object Request Brokers

ZENTowards Highly Configurable Real-time Object Request Brokers Raymond Klefstad, Douglas C. Schmidt, and Carlos O'Ryan University of California at Irvine Presented by: S. M. Sadjadi Software Engineering and Networking Systems Laboratory Department of Computer Science and Engineering Michigan State University www.cse.msu.edu/sens

Acknowledgement: • Douglas C. Schmidt • Raymond Klefstad • Carlos O'Ryan • Other DOC members

Backgroud: • The purpose: • To support advanced R&D on distributed object computing middleware using an open source software development model. • The DOC Group is a distributed research consortium consisting of: • Vanderbilt University in Nashville, Tennessee. (southern office) • Washington University in St. Louis, Missouri. (midwest office) • University of California in Irvine, California. (west coast office) • Members at: • Siemens ZT in Munich, Germany. • Bell Labs in Murray Hill, New Jersey. • OCI in St. Louis, MO. • …

Agenda: • Motivation • ZEN Solution • Background • CORBA and Real-Time CORBA • Java and Real-Time Java • ORB Generations • Micro-ORB vs. Monolithic-ORB • Virtual Component Pattern • ZEN Architecture • Concluding Remarks

Motivations: • ZEN Project Goal: • Supporting development of distributed, real-time, and embedded (DRE) systems. • DRE systems: • “The right answer delivered too late becomes the wrong answer.” [ZEN] • Examples: • Telecommunication Networks (e.g., wireless phone services). • Tele-medicine (e.g., remote surgery). • Manufacturing Process Automation (e.g., hot rolling mills). • Defense Applications (e.g., avionics mission computing systems). • DRE Challenging Requirements: • As Distributed Systems: • managing connections and message transfer. • As Real-Time Systems: • predictability and end-to-end resource control. • As Embedded Systems: • resource limitations.

ZEN’s Solution: • Integration of the Best Aspects of: • CORBA: • Standards-based distributed applications • Real-time CORBA: • CORBA with Real-time QoS capabilities • Java: • Simple, less error-prone, large user-base • Real-time Java: • Real-time support • Pattern-Oriented Programming: • Virtual Component Pattern: • Factory Method Pattern • Proxy Pattern • Component Configurator Pattern

OMG Reference Model Architecture [CORBA-Overview] : • Domain Services • (a.k.a, Domain Interfaces and Vertical Facilities) • are more oriented towards specific app domains. • Product Data Management (PDM) Enablers for the manufacturing domain. • Application Services • (a.k.a, Application Interfaces and Application Objects) • are services developed specifically for a given application. • Object Services • (a.k.a, CORBA Services) • Domain-independent services. • Naming Service and Trading Service. • Common Services • (a.k.a, Common Facilities and Horizontal Facilities) • are less oriented towards end-user applications. • Distributed Document Component Facility (DDCF).

CORBA ORB Architecture [CORBA-Overview]: • Object • A CORBA programming entity. • Servant • An implementation programming language entity. • Server • is a running program (or process) entity. • Client • is a program entity that invokes an operation. • Object Request Broker (ORB) • provides transparent comm. Mechanisms. • ORB Interface • decouples an application from an ORB impl. • CORBA IDL stubs and skeletons • the ``glue'' between the client and server applications, respectively, and the ORB. • Dynamic Invocation Interface (DII) • allows generating dynamic requests. • Dynamic Skeleton Interface (DSI) • server side's analogue to DII. • Object Adapter • assists the ORB with delivering requests. • associates object with the ORB. • can be specialized to provide support for certain object implementation styles. .

Real-Time CORBA [ZEN]: • Features: • Adds QoS control capabilities to regular CORBA. • Improve application predictability by bounding priority inversion • Manage system resources end-to-end. • Processor resources • Communication resources • Memory resources • Shortcommings: • Focuses primarily on “fixed-priority” real-time applications, where priorities are assigned statically. • Steep learning curve: • Cause by the complex C++ mapping. • Run-time and memory footprint overhead

Java: Real-Time Java: • Features: • Simple • Growing programmer • Powerful and standard library • JVM • Strong typing • Portable concurrency • Lazy class loading • Shortcomings: • No fine grain memory management • No precise thread priority • Garbage collector • Non-determinism • Non-predictable • Features: • New memory management model • Instead of garbage collector • Access to physical memory • A higher resolution time granularity • Stronger guarantees on thread semantics. • The highest priority thread will always run • Shortcomings: • No facilities for distributed applications

ORB Generations and ZEN Design Process: • Dynamic Reflective Micro-ORB: • Builds a configuration description for each application based on the history. • Advantages: • Neer minimal footprint adaptively • Eliminate jitter • Disadvantages: • Not suitable for some embedded systems • Static Reflective Micro-ORB: • Source code is generated using the configuration description for a new custom ORB • Advantages: • Fast • Small footprint • Easy to code • Disadvantages: • Automatic customization is still an open research issue • Static Monolithic ORB: • All code is loaded in one executable. • Advantages: • Efficient • Easy to code • Supports all CORBA services • Disadvantages: • Excessive memory footprint • Growth of footprint with each extension • Monolothic ORB with Compile-Time Configurable Flags: • Allows a variety of different configurations • Advantages: • Reduced footprint • Disadvantages: • Hard to code the application • Dynamic Micro-ORB: • Only a small ORB kernel is loaded • Component Configurator and Virtual Component • Advantages: • Reduced footprint • Dynamic reconfiguration • Easier to code the application • Disadvantages: • Potential jitter • May not be suitable for some systems • ZEN Design Process • Dynamic Micro-ORB • Dynamic Reflective Micro-ORB • Static Reflective Micro-ORB

Micro-ORB vs. Monolithic-ORB: • Context: • Implementing full-service can yield a monolithic-ORB with large footprint • Problem: • Embedded Systems often have severe memory limitations • Solution • Micro-Kernel pattern • Virtual Component Pattern • Identify core ORB services whose behavior may vary • Move each core ORB service out of the ORB Monolithic-ORB Architecture [ZEN] Micro-ORB Architecture [ZEN]

Virtual Component Configurator: • Intent • to factor out components that may not be needed • Solution • Use abstract interfaces for all components • Upon ‘component-fault’ load concrete implementations using: • Factory Method • Proxy • Component Configurator Virtual Component Static Structure [VirtualComponent]

Component Loading Strategies: Eager Static Loading Strategy [VirtualComponent] Eager Dynamic Loading Strategy [VirtualComponent] Lazy Dynamic Loading Strategy [VirtualComponent]

Pluggable GIOP Message Handling: • Context: • GIOP defines 8 types of messages • Each requires two marshal and demarshal • Three versions: 1.0, 1.1, and 1.2 • Problem: • 8*2*3 makes 48 methods • Space overhead • Hard to modify • Solution: • Virtual Component: • Fine-grain • 48 separate classes • Client/Server pairing • Groups complementary methods into a single class Pluggable GIOP Message Handling [ZEN]

Pluggable Object Adapter: • Context: • Maps client requests to the servants • Different types of POAs: • The Standard POA • Minimun POA • Real-Time POA • Problem: • A POA is just necessary for server applications. • Space overhead • Hard to add new standards • Solution: • Virtual Component: • If the application plays the role of a server, at most one of POA types will be loaded. Pluggable Object Adapter [ZEN]

Pluggable Transport Protocols: • Context: • GIOP can run over many transport protocols. • Each protocol roughly need 5 methods to implement. • Each containing: • Client-oriented classes • Server-oriented classes • Problem: • About 20 to 30 methods required to handle the most common protocols. • Space overhead • Hard to modify • Solution: • Virtual Component: • Allows one (or more) desired protocol(s) to be loaded. • Only the required subclasses will be loaded dynamically. Pluggable Transport Protocols [ZEN]

Pluggable CDR Stream Reader/Writer: • Context: • CORBA is platform independent and must handle diverse end system instruction set. • CORBA defines Character Data Representation for marshalling and demarshalling. • Problem: • each possible read or write for each data type, such as readDouble() and readLong(), needs an if statement to check big/little endian. • Space overhead • Hard to modify • Solution: • Virtual Component: • Each CDRInputStream class in divided into two classes (for big and little endian). • Improve in space and performance (“if” executes once). Pluggable CDR Reader [ZEN]

Pluggable Any Handler: • Context: • Any used for generic services • Each any is preceded by a type code of the value it contains. • Many DRE apps do not use Any at all. • Problem: • A lot of code is required to support Any. • To read, write, marshal, demarshal, and to insert and extract any from each type. • Space overhead • Solution: • Virtual Component: • Removing Any methods. • Keep minimal proxy object (AnyReader and AnyWriter). • The rest will be loaded on demand. Pluggable Any Handler [ZEN]

Pluggable IOR Parsers (cont.): • Context: • Interoperable ORB References are CORBA object pointer. • Variety of formats: • “IOR:,” “FILE:,” “HTTP:,” “CORBALOC:,” and “FTP:.” • Problem: • Parsing every possible format • Space overhead • Hard to modify • Solution: • Virtual Component: • Define an interface that parses and handles IORs. • Derive separate class strategies that handles each. • Load the class on demand. Example IOR [ZEN] Pluggable IOR Parser [ZEN]

Pluggable Object Resolver: • Context: • ORB::resolve_initial_reference() is used to obtain references to ORB objects such as RootPOA and Naming. • The number of objects are large and growing. • Problem: • Cascade if statements to check each object string name. • Space overhead • Hard to modify • Solution: • Virtual Component: • An abstract base class with a factory method at the base. • Factory method takes a string and returns a ref to an object. • A naming convention is used. Pluggable Object Resolver [ZEN]

Pluggable Message Buffer Allocators: • Context: • To ensure efficient interprocess communication and avoid unnecessary garbage collection. • But which specific dynamic storage allocation algorithm? • Problem: • Must include all possible algorithms for flexibility. • Fast fit, buddy system, … • Space overhead • Hard to modify • Solution: • Strategy Pattern: • To support each algorithm • Thread Specific Pattern • To make them pluggable. • Virtual Component: • Dynamic on demand loading. Pluggable Allocator [ZEN]

ZEN Current Status: • 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 for embedded systems • Completing Real-time CORBA support utilizing Real-time Java features • Ahead-of-time Real-time Java native compilation • Using refection to determine ideal minimal configuration • Using aspects for static custom configuration

Concluding Remarks: • ZEN Objectives: • Supporting development of DRE systems • Faster, easier, more extensible, and more portable • Reducing the footprint • Providing an infrastructure for DOC middleware R&D by releasing ZEN in open-source • Technologies integrated in ZEN: • CORBA and Real-Time CORBA • Java and Real-Time Java

References: • [ZEN] http://www.computer.org/proceedings/isorc/1558/15580437abs.htm?SMSESSION=NO • [CORBA-Overview] http://www.cs.wustl.edu/~schmidt/corba-overview.html • [ZEN-Web] http://www.zen.uci.edu • [RT-Java] Real-time Java (JSR-1) http://java.sun.com/aboutJava/communityprocess/jsr/jsr_001_real_time.html • [Dist-RT-Java] Distributed Real-time Java (JSR-50) http://java.sun.com/aboutJava/communityprocess/jsr/jsr_050_drt.html • [VirtualComponent] http://www.cs.wustl.edu/~schmidt/PDF/virtual-component.pdf

Highly Configurable Real-time Object Request Brokers