Download corbazen - University of California, Irvine

CORBA Overview
Arvind S. Krishna
Info & Comp Science Dept
University of California,
Irvine
{krishnaa}@uci.edu
Distributed Systems &Middleware ICS243f
30 April 2017
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
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
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)
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
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 ();
// …
};
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
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
Standardized
Format
ORB-specific
Format
Real-Time CORBA Overview
• RT CORBA adds QoS control to
regular CORBA improve the
application predictability, e.g.,
End-to-End Priority
Propagation
Client
OBJ
REF
in args
operation()
Object
(Servant)
• Bounding priority inversions &
• Managing resources end-to-end
out args + return
Scheduling
Service
IDL
SKEL
IDL
STUBS
Explicit
Binding
ORB CORE
Standard
Synchronizers
Portable Priorities
Thread
Pools
Object Adapter
GIOP
• Policies & mechanisms for
resource configuration/control in
RT-CORBA include:
1.Processor Resources
• Thread pools
• Priority models
• Portable priorities
2.Communication Resources
Protocol Properties
• Protocol policies
• Explicit binding
3.Memory Resources
• Request buffering
Real-time CORBA leverages the CORBA
Messaging QoS Policy framework
• These capabilities address some
important real-time application
development challenges
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
Overview - ZEN R&D Plan
Phase I  Apply Optimization patterns
and principles
• ORB-Core Optimizations
• Micro ORB Architecture  Virtual
Component Pattern
• Connection Management  AcceptorConnector 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  HalfSync/Half-Async
Phase III  Build a Real-Time
CORBA ORB that runs atop a mature
RTSJ Layer
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
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/