Real-time CORBA
Part 1: Motivation and Overview
Object Interconnections
Douglas C. Schmidt
Steve Vinoski
September 2001
Introduction
Our past three columns [1,2,3] have compared and contrasted CORBA with other emerging enterprise
middleware technologies, such as XML and SOAP. Enterprise middleware is an important and growing
segment of the Information Technology (IT) market. It’s often used in large-scale business systems where
scalability, evolvability, and interoperability are essential for success. We now turn our attention to the
opposite end of the spectrum and describe how middleware is evolving to support distributed real-time and
embedded (DRE) systems, such as distributed control of large-scale telecom switching systems or
autonomous vehicles over wireless links. DRE middleware is another important and growing segment of
the IT market. It’s increasingly being used in mission-critical embedded systems where predictability,
efficiency, and fine-grained control over system resources are essential for success.
Our focus in this column is Real-time CORBA, which is DRE middleware that’s integrated with the
CORBA 2.5 specification [4]. Real-time CORBA provides standard interfaces and policies that allow DRE
applications to configure and control the following system resources:
 Processor resources via thread pools, priority mechanisms, intra-process mutexes, and a global
scheduling service for real-time applications with fixed priorities
 Communication resources via protocol properties and explicit bindings to server objects using priority
bands and private connections and
 Memory resources via buffering requests in queues and bounding the size of thread pools.
Real-time CORBA is designed for applications with hard real-time requirements, such as avionics mission
computing, as well as those stringent soft real-time requirements, such as telecommunication call
processing. In this column, we explain the need for the capabilities offered by Real-time CORBA.
Subsequent columns will show C++ examples that illustrate how to program many of the Real-time
CORBA features.
Why We Need Standard Middleware for Distributed Real-time and Embedded Systems
There are many types of DRE systems, but they have one thing in common: the right answer delivered too
late becomes the wrong answer. This is clearly the case for DRE applications used in military systems,
such as anti-ship cruise missile defense. Civilian examples include DRE systems for process control and
manufacturing, such as controlling the temperature of coolant in a nuclear reactor or ensuring the thickness
and quality of steel in a hot rolling mill.
Several trends are changing the way in which new and planned DRE systems are conceived and
constructed [5]. The first is that information technology of all forms is becoming highly commoditized, i.e.,
hardware and software artifacts are getting faster, cheaper, and better, all at a relatively predictable rate.
The second is the growing acceptance of a network-centric paradigm, where DRE applications with a range
of quality of service (QoS) needs are constructed by integrating separate components connected by various
communication and computing services. The nature of the interconnection for DRE systems can range
from
1. The very small and tightly coupled, such as avionics mission computing systems and “pick and place”
technology for mounting chips to motherboards, to
2. The very large and loosely coupled, such as global telecommunication systems or large-scale
networked sensor systems used to control building temperature and energy consumption.
The interplay of these two trends has motivated new architectural concepts and services centered on
standardized middleware for DRE systems.
Due to constraints on weight, power consumption, memory footprint, and performance, the development
techniques and methodologies used for DRE software has historically lagged behind those used for
mainstream desktop and enterprise software. As a result, DRE software systems are costly to develop,
maintain, and evolve. Moreover, they are often so specialized that they cannot adapt readily to meet new
functional or QoS requirements, hardware/software technology innovations, or market opportunities.
Programming DRE systems is hard in part because certain QoS properties must be supported along with the
application software and distributed computing middleware functionality. Key QoS properties include:
 Pooling of concurrency resources and synchronization of concurrent operations
 Sensor input and actuator output timing constraints
 Allocation, scheduling, and priority assignment of computing and communication resources end-to-end
and
 Memory management.
Historically, applications for DRE systems have been custom programmed by hand to implement these
QoS properties. Unfortunately, this tedious and error-prone manual development process has largely failed
to address the following challenges:
1. Multiple platforms and varying operational contexts. Modern DRE systems must invest an everincreasing proportion of functionality in software. Rapidly emerging technologies and flexibility
required for diverse operational contexts force deployment of multiple versions of software on various
platforms, while simultaneously preserving key properties, such as real-time response and end-to-end
priority preservation.
2. Total ownership costs. Custom software development and evolution is labor-intensive and error-prone
for complex DRE systems, such as fly-by-wire aircraft or autonomous vehicle systems, and can
represent over 50% of the total ownership costs of these systems.
3. Obsolescence trends. Incommensurate lifetimes between long-lived DRE systems (20 years or more)
and commercial off-the-shelf (COTS) platforms and tools (2-5 years) lead to pervasive software
obsolescence and multiply the total ownership costs by requiring periodic software re-development
and COTS refresh.
Some aspects of these challenges are similar to those confronted by mainstream distributed systems. Other
aspects are unique to DRE systems. For the past five years, the OMG, the DRE research community, and
many ORB vendors have been exploring techniques for codifying the “best practices” of distributed realtime and embedded systems in standard middleware based on CORBA. The result has been the Real-time
CORBA 1.0 specification [6], which was adopted as a standard by the OMG in 1998 and integrated with
CORBA in the 2.4 specification released in 2000. Real-time CORBA was designed to address the
following limitations with prior CORBA specifications:
 Lack of QoS specification—Earlier CORBA specifications did not define standard policies that
allowed applications to specify end-to-end QoS requirements. Before CORBA 2.4, for instance, clients
had no standard way to indicate the relative priorities of their operations to an ORB, nor could they
ensure that certain operations run over different network connections.
 Lack of real-time features—Earlier CORBA specifications did not provide key features needed to
support real-time programming. For instance, although the GIOP inter-operability protocol supported
asynchronous messaging since CORBA 2.0, there was no standard programming language mapping for
invoking operations asynchronously until CORBA 2.4.
 Lack of optimizations—Early ORB implementations incurred overhead that stemmed from excessive
data copying, non-optimized presentation layer conversions, internal message buffering strategies that
produce non-uniform behavior for different message sizes, inefficient demultiplexing algorithms, long
chains of intra-ORB virtual method calls, and lack of integration with underlying real-time OS and
network QoS mechanisms. Although the OMG does not mandate optimizations for these sources of
overhead, ORBs that conform to the Real-time CORBA specification are designed carefully to
minimize latency and jitter while also ensuring efficient throughput and scalability [7].
It’s important to recognize that “real-time” need not be synonymous with “real-fast.” In particular,
requirements for high efficiency may conflict with requirements for real-time predictability. For instance,
real-time schedulers often rely on the predictability of infrastructure mechanisms, such as thread
scheduling, I/O demultiplexing, and message buffering. However, certain optimizations, such as using selforganizing search structures to demultiplex client requests, can increase the average-case performance of
operations, while decreasing the predictability of any given operation. Ideally, Real-time CORBA
implementations use algorithms and data structures that optimize for both efficiency and predictability. For
instance, active demultiplexing of POAs and servants and perfect hashing of operations [8] can increase
ORB performance and predictability by eliminating excessive searching and avoiding priority inversions.
Overview of Real-time CORBA Features
Real-time CORBA is a superset of CORBA. Below, we describe how Real-time CORBA features can be
used to control processor resources and inter-ORB communication. We also outline Real-time CORBA
features for managing memory resources, but because the specification is less explicit on this topic, we
merge our managing memory discussion with the topic of managing processor resources.
Managing Processor Resources
Strict control over the scheduling and execution of processor resources is essential for many DRE
applications. The Real-time CORBA specification therefore defines the following features that enable:
 Client and/or server applications to determine the priority of CORBA invocations. Earlier CORBA
specifications provided no standard way for clients to indicate the relative priorities of their requests to
ORB endsystems. This feature is necessary, however, to minimize end-to-end priority inversion, as
well as to bound latency and jitter for applications with deterministic real-time QoS requirements.
 Servers to pre-spawn pools of threads. This feature allows server applications to pre-allocate pools of
threads and to set certain thread attributes, such as default priority levels. Thread pools are useful for
real-time ORB endsystems and applications that want to leverage the benefits of multi-threading, while
bounding their consumption of memory resources, such as stack space. Moreover, thread pools can be
configured to buffer or not buffer requests, which allows further control over their memory usage. It's
also possible to bound the priority of ORB threads, which may be useful when combining a CORBA
server with other real-time threads that may need to run in a particular range of priorities.
 Client and/or server applications to ensure consistent semantics for intra-process thread
synchronizers. Earlier CORBA specifications provided no standard, portable API that applications
could use to ensure semantic consistency between their synchronization mechanisms and the internal
synchronization mechanisms used by an ORB. Real-time applications, however, require this
consistency to enforce priority inheritance and priority ceiling protocols. To ensure semantic
consistency, therefore, the Real-time CORBA specification defines a standard set of locality
constrained mutex operations.
 A global Scheduling Service to allocate system resources that meet the QoS needs of the applications
sharing ORB endsystems. Applications can use this Scheduling Service to specify the processing
requirements of their operations in terms of various parameters, such as worst-case execution time and
period.
Managing Inter-ORB Communication
Historically, the CORBA specification and conventional ORBs have supported location transparency, i.e.,
applications cannot detect whether components are distributed or collocated in the same process. Moreover,
the features of the underlying OS, network, and/or bus are considered a black box. Although this
encapsulation is useful for applications with best-effort QoS requirements, it’s inadequate for applications
with more stringent QoS requirements.
To allow applications to control the underlying communication protocols and endsystem resources,
therefore, the Real-time CORBA specification defines standard interfaces that can be used to select and
configure certain protocol properties. In addition, client applications can explicitly bind to server objects
using priority bands and private connections, as described below.
 Selecting and configuring protocol properties. Real-time CORBA defines an interface that permits
applications to specify ORB- and transport-specific protocol properties that control various
communication protocol features, such as ATM virtual circuits or Internet RSVP flow specifications.
 Pre-establish connections binding. Real-time CORBA defines an explicit binding mechanism that
uses the _validate_connection() operation defined on the CORBA::Object interface since the
CORBA 2.4 specification. This mechanism enables clients to pre-establish connections to servers and
control how client requests are sent over these connections.
 Private connections. Many ORBs support multiplexed connections, which yield better utilization of
connections and other limited OS resources. Real-time applications often require private (nonmultiplexed) connections, however, which are well suited for applications that possess deterministic
QoS requirements. A private connection cannot be reused for another two-way request until the reply
for the previous request is received.
 Priority-banded connections. Real-time CORBA allows clients to send operations to servers over a
pre-established connection that's assigned to a fixed priority range. The server ORB then processes the
servant upcall at the specified priority and sends the reply across the same non-multiplexed private
connection. This combination of features ensures that end-to-end priorities are maintained and that
key sources of priority inversion are eliminated.
Concluding Remarks
To achieve lower development cost and faster time to market, distributed real-time and embedded (DRE)
system development strategies are migrating towards those used for mainstream enterprise systems. In the
past, most DRE software development projects have lagged in terms of design and development
methodologies (and languages) by decades. These projects have been extremely costly to evolve and
maintain. They’ve also been so specialized that they can’t be adapted readily to meet new requirements or
new market opportunities. The technologies they’ve employed have often been obsolete by the time the
developers complete the first version of the system.
We believe the future of Real-time CORBA is quite promising for DRE systems. The flexibility and
adaptability offered by CORBA make it attractive for use in many types of DRE systems, such as
aerospace and defense, distributed process control, and highly distributed sensor networks. Stringent time
and space constraints are now possible with COTS ORBs, which makes the use of Real-time CORBA
compelling. Moreover, Real-time CORBA ORBs can be adapted to “niche” markets real-time and
embedded that aren't well covered by mainstream enterprise middleware vendors. In this sense, Real-time
CORBA has an advantage over other DOC technologies, such as COM+ and Java RMI, since it can be
integrated into a wider range of platforms, i.e., it's open!
This column concludes the introduction to our multi-part series on Real-time CORBA. Our subsequent
columns will show how to program many of the Real-time CORBA features using C++. If you have
comments, questions, or suggestions regarding these columns, please let us know at
mailto:object_connect@cs.wustl.edu.
References
1.
2.
3.
4.
5.
6.
7.
8.
D.C. Schmidt and S. Vinoski. “CORBA and XML, Part 1: Versioning,” C/C++ Users Journal, May
2001, http://www.cuj.com/experts/1905/vinoski.htm.
D.C. Schmidt and S. Vinoski. “CORBA and XML, Part 2: XML as CORBA Data,” C/C++ Users
Journal, July 2001, http://www.cuj.com/experts/1907/vinoski.htm.
D.C. Schmidt and S. Vinoski. “CORBA and XML, Part 3: SOAP and Web Services,” C/C++ Users
Journal, September 2001, http://www.cuj.com/experts/1910/vinoski.htm.
Object Management Group, “The Common Object Request Broker: Architecture and Specification
Revision 2.5, OMG Technical Document formal/01-09-01”, September 2001.
Richard E. Schantz and Douglas C. Schmidt, “Middleware for Distributed Systems: Evolving the
Common Structure for Network-centric Applications,” Encyclopedia of Software Engineering, Wiley
and Sons, 2002.
Douglas C. Schmidt and Fred Kuhns, “An Overview of the Real-time CORBA Specification,” IEEE
Computer Magazine, June, 2000.
Rebecca Callison, Marilynn Goo, and Daniel Butler, “Real-time CORBA Trade Study,” D204-31159,
The Boeing Company, 1999, Phantom Works, Seattle.
Irfan Pyarali, Carlos O'Ryan, Douglas C. Schmidt, Nanbor Wang, Vishal Kachroo, Aniruddha
Gokhale, “Using Principle Patterns to Optimize Real-time ORBs,” IEEE Concurrency Magazine,
January, 2000.