ZEN

Towards 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

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

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 d istributed, 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.

2.

3.

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

4.

5.

 – – –

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

ZEN Design Process

Dynamic Micro-ORB 2.

3.

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]

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

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

SESSION=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