1. Fifth IEEE International Symposium on Object-Oriented Real-Time Distributed Computing. 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

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

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

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

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

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

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

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

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

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

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

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

13. 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 Process 1.Dynamic Micro-ORB 2.Dynamic Reflective Micro-ORB 3.Static Reflective Micro-ORB

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

15. 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]

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

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

18.  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

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

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

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

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

23. 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]

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

25. 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?

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

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

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