1. CORBA Overview Arvind S. Krishna Info & Comp Science Dept
University of California, Irvine
Distributed Systems &Middleware ICS243f
10 September 2018

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.
Keep this explanation at a very high level
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
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 ORB-specific Format Standardized
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 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 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 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):
jsr_001_real_time.html
Dynamic scheduling RFP:
Dynamic_Scheduling_RFP.html
Distributed Real-time Java (JSR-50):
jsr_050_drt.html
AspectJ web page:
JRate