CORBA Overview

1. CORBA Overview Arvind S. Krishna Info & Comp Science Dept University of California, Irvine {krishnaa}@uci.edu Distributed Systems &Middleware ICS243f 23 September 2014

2. Brief History - OMG OMG Formation • OMG created in 1989 with aim of promoting object technology in Distributed Systems • OMG realizes its goals through creating standards which allow interoperability and portability of distributed object oriented applications • Do not produce software define standards • OMA – Object Management Architecture • Consists of four components divided into two parts: • System oriented components Object Request Brokers and Object Services and • Application oriented components Application Objects and Common Facilities • Object Request Broker is the one which constitutes the foundation of OMA and manages all communication between its components

3. CORBA CORBA – Common Object Request Broker Architecture Motivation • To allow objects to interact in • Heterogeneous distributed environment • independent of the platforms on which these objects reside • techniques used to implement them (languages) • CORBA – Architecture • Object Request Broker (ORB) • ORB encompasses • all communication infrastructure necessary to identify and locate objects, • handle connection management • Marshalling & de-marshalling data and • deliver data. • The ORB is not required to be a single component; it is simply defined by its interfaces. • The ORB Core is the most crucial part of the Object Request Broker; • Minimum run-time layer required in every peer

4. Overview of CORBA Components Standard CORBA Components Object This is a CORBA programming entity that consists of an identity, an interface, and an implementation, which is known as a Servant. Servant This is an implementation programming language entity that defines the operations that support a CORBA IDL interface. Servants can be written in a variety of languages, including C, C++, Java, Smalltalk, and Ada. ClientThis is the program entity that invokes an operation on an object implementation. Accessing the services of a remote object should be transparent to the caller. Ideally, it should be as simple as calling a method on an object, i.e., obj->op(args)

5. Component Overview – (contd) • ORB InterfaceAn ORB is a logical entity that may be implemented in various ways • (such as one or more processes or a set of libraries). • To decouple applications from implementation details, the CORBA specification defines • an abstract interface for an ORB. • This interface provides various helper functions such as converting object references to • strings and vice versa • CORBA IDL stubs and skeletonsCORBA IDL stubs and skeletons serve as • the ``glue'' between the client and server applications • The transformation between CORBA IDL definitions to languages automated • IDL compiler • The compiler allows for compiler optimization and automation of repetitive tasks • Object AdapterThis assists the ORB with delivering requests to the object and with • activating the object. • More importantly, an object adapter associates object implementations with the ORB. • Object adapters can be specialized to provide support for certain object • implementation styles • The QoS requirements for a POA specified using policies passed to it at creation time • OMG provides seven standard policies and policy values • Lifespan policy with policy values PERSISTENT and TRANSPERANT

6. Interface Definition Language • IDL - motivation • CORBA language independent • OMG does not provide implementations • Left to ORB implementer • OMG defines architecture of the system in terms of “interfaces” and the operations on these interfaces • IDL – in Motion • IDL is a language that has been developed for distribution of architecture • Each ORB implementer writes an IDL compiler to generate programming language code • IDL – Mapping • OMG also defines a mapping from the IDL to the programming language • IDL is a declarative language – cannot define data members • Example, interfaces are mapped to the Java classes or to abstract classes in C++ • Arguments must also specify the direction e.g. in means only input cannot hold output, inout holds both input and output interface Drone { void turn (in float degrees); void speed (in short mph); void reset_odometer (); short odometer (); // … };

7. CORBA Communication Model CORBA Communication • Heterogeneous languages, platforms and also operating systems • Big endian (Sparc)Little endian architectures (Intel) Problem • Traditionally programmers have had to handle these • Offloaded to middleware Protocol definition • General Internet Inter-ORB protocol • Standard marshalling and demarshalling parameters • Client marshals a request i.e. wraps a request in a given format includes padding etc • GIOP maps to various protocols TCP/IP mapping of the protocol is IIOP same as that used by java RMI • Standardized exchange enabling two different ORB implementations to inter operate • Supports standardized uni-cast communication reliable one-way, two-way communication • Three broad mechanisms of communication • synchronous • deferred synchronous • asynchronous

8. Object References Inter-operability • Many ORBs how can these ORBs talk to each other? • OMG standardizes the generation of Object references • An object reference is an ORB-specific entity that can contain a • Repository ID, which identifies its interface type • Transport address information, e.g., a server’s TCP/IP host/port address(es) • An object key that identifies which object in the server the request is destined for • An object reference similar to a C++ “pointer” that’s been enhanced to identify objects in remote address spaces • Object references can be passed among processes on separate hosts • The underlying CORBA ORB will correctly convert object references into a form that can be transmitted over the network • The ORB provides the receiver with a pointer to a proxy in its own address space • This proxy refers to the remote object implementation • Object references are a powerful feature of CORBA e.g., they support peer-to-peer interactions and distributed callbacks ORB-specific Format Standardized Format

9. Real-Time CORBA Overview • RT CORBA adds QoS control to regular CORBA improve the application predictability, e.g., • Bounding priority inversions & • Managing resources end-to-end • Policies & mechanisms for resource configuration/control in RT-CORBA include: • Processor Resources • Thread pools • Priority models • Portable priorities • Communication Resources • Protocol policies • Explicit binding • Memory Resources • Request buffering • These capabilities address some important real-time application development challenges Real-time CORBA leverages the CORBA Messaging QoS Policy framework

10. Motivation for ZEN Real-time ORB Integrate best aspects of several key technologies • Java: Simple, less error-prone, large user-base • Real-time Java: Real-time support • CORBA: Standards-based distributed applications • Real-time CORBA: CORBA with Real-time QoS capabilities ZEN project goals • Make development of distributed, real-time, & embedded (DRE) systems easier, faster, & more portable • Provide open-source Real-time CORBA ORB written in Real-time Java to enhance international middleware R&D efforts

11. Overview - ZEN R&D Plan • Phase II  Enhance Predictability by applying RTSJ features • Associate Scoped Memory with Key ORB Components • I/O Layer : Acceptor-Connector, Transports • ORB Layer: CDR Streams, Message Parsers • POA Layer: Thread-Pools and Upcall Objects • Using NoHeapRealtimeThreads • Ultimately use NHRT Threads for request/response processing • Reduce priority inversions from Garbage Collector Phase I  Apply Optimization patterns and principles • ORB-Core Optimizations • Micro ORB Architecture  Virtual Component Pattern • Connection Management  Acceptor-Connector pattern, Reactor (java’s nio package) • Collocation and Buffer Management Strategies • POA Optimizations • Request Demultiplexing  Active Demultiplexing & Perfect Hashing • Object Key Processing Strategies  Asynchronous completion token pattern • Servant lookup  Reverse lookup map • Concurrency Strategies  Half-Sync/Half-Async Phase III  Build a Real-Time CORBA ORB that runs atop a mature RTSJ Layer

12. References • ZEN open-source download & web page: • http://www.zen.uci.edu • Real-time Java (JSR-1): • http://java.sun.com/aboutJava/communityprocess/jsr/ jsr_001_real_time.html • Dynamic scheduling RFP: • http://www.omg.org/techprocess/meetings/schedule/ Dynamic_Scheduling_RFP.html • Distributed Real-time Java (JSR-50): • http://java.sun.com/aboutJava/communityprocess/jsr/jsr_050_drt.html • AspectJ web page: • http://www.aspectJ.org • JRate • http://tao.doc.wustl.edu/~corsaro/jRate/