Fifth IEEE International Symposium on Object-Oriented Real-Time Distributed Computing.

ZENZENTowards Highly Configurable Towards Highly Configurable

Real-time Object Request Real-time Object Request BrokersBrokers

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

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

OMG Reference Model Architecture [CORBA-

Overview] :

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

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.

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

Real-Time Java: 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

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

ORB Generations and ZEN Design Process:

1. 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

2. Monolothic ORB with Compile-Time Configurable Flags:

– Allows a variety of different configurations– Advantages:

Reduced footprint– Disadvantages:

Hard to code the application

3. 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

4. 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

5. 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

ZEN Design Process1. Dynamic Micro-ORB2. Dynamic Reflective Micro-ORB3. Static Reflective Micro-ORB

Monolithic-ORB Architecture [ZEN] Micro-ORB Architecture [ZEN]

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

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]

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

Solution:– Virtual Component:

Fine-grain– 48 separate classes

Client/Server pairing– Groups complementary

methods into a single class

Pluggable GIOP Message Handling:

Problem:– 8*2*3 makes 48 methods– Space overhead– Hard to modify

Pluggable GIOP Message Handling [ZEN]

Context:– GIOP defines 8 types of

messages– Each requires two marshal

and demarshal– Three versions: 1.0, 1.1, and

1.2

Pluggable Object Adapter:

Pluggable Object Adapter [ZEN]

Solution:– Virtual Component:

If the application plays the role of a server, at most one of POA types will be loaded.

Problem:– A POA is just necessary for

server applications.– Space overhead– Hard to add new standards

Context:– Maps client requests to the

servants– Different types of POAs:

The Standard POA Minimun POA Real-Time POA

Pluggable Transport Protocols:

Pluggable Transport Protocols [ZEN]

Solution:– Virtual Component:

Allows one (or more) desired protocol(s) to be loaded.

Only the required subclasses will be loaded dynamically.

Problem:– About 20 to 30 methods

required to handle the most common protocols.

– Space overhead– Hard to modify

Context:– GIOP can run over many

transport protocols.

– Each protocol roughly need 5 methods to implement.

– Each containing: Client-oriented classes Server-oriented classes

Pluggable CDR Stream Reader/Writer:

Pluggable CDR Reader [ZEN]

Solution:– Virtual Component:

Each CDRInputStream class in divided into two classes (for big and little endian).

Improve in space and performance (“if” executes once).

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

Context:– CORBA is platform independent

and must handle diverse end system instruction set.

– CORBA defines Character Data Representation for marshalling and demarshalling.

Pluggable Any Handler:

Pluggable Any Handler [ZEN]

Solution:– Virtual Component:

Removing Any methods. Keep minimal proxy object

(AnyReader and AnyWriter). The rest will be loaded on

demand.

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

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.

Pluggable IOR Parsers (cont.):

Pluggable IOR Parser [ZEN]

Solution:– Virtual Component:

Define an interface that parses and handles IORs.

Derive separate class strategies that handles each.

Load the class on demand.

Problem:– Parsing every possible format– Space overhead– Hard to modify

Context:– Interoperable ORB

References are CORBA object pointer.

– Variety of formats: “IOR:,” “FILE:,” “HTTP:,”

“CORBALOC:,” and “FTP:.”

Example IOR [ZEN]

Pluggable Object Resolver:

Pluggable Object Resolver [ZEN]

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.

Problem:– Cascade if statements to

check each object string name.

– Space overhead– Hard to modify

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.

Pluggable Message Buffer Allocators:

Pluggable Allocator [ZEN]

Solution:– Strategy Pattern:

To support each algorithm

– Thread Specific Pattern To make them pluggable.

– Virtual Component: Dynamic on demand loading.

Problem:– Must include all possible

algorithms for flexibility. – Fast fit, buddy system, …– Space overhead– Hard to modify

Context:– To ensure efficient

interprocess communication and avoid unnecessary garbage collection.

– But which specific dynamic storage allocation algorithm?

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