1 / 28

ZEN Towards Highly Configurable Real-time Object Request Brokers

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

michiko
Download Presentation

ZEN Towards Highly Configurable Real-time Object Request Brokers

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  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] : • 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).

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

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

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

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

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

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

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

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

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

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

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

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

More Related