Post on 16-Jan-2016
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