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 IT (Information Technology) 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 DRE (distributed real-time and embedded) 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
- 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 DRE 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 QoS (quality of service) 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
- The very small and tightly coupled, such as avionics mission computing systems and "pick and place" technology for mounting chips to motherboards, to
- 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
- 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:
- Multiple platforms and varying operational contexts. Modern DRE systems must invest an ever-increasing 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.
- 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 percent of the total ownership costs of these systems.
- Obsolescence trends. Incommensurate lifetimes between long-lived DRE systems (20 years or more) and COTS (commercial off-the-shelf) 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 DRE 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 self-organizing 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 multithreading, 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 (non-multiplexed) 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, 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 make 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 multipart 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 object_connect@cs.wustl.edu.
References
[1] D.C. Schmidt and S. Vinoski. "Object Interconnections: CORBA and XML, Part 1: Versioning," C/C++ Users Journal C++ Experts Forum, May 2001, <www.cuj.com/experts/1905/vinoski.htm>.
[2] D.C. Schmidt and S. Vinoski. "Object Interconnections: CORBA and XML, Part 2: XML as CORBA Data," C/C++ Users Journal C++ Experts Forum, July 2001, <www.cuj.com/experts/1907/vinoski.htm>.
[3] D.C. Schmidt and S. Vinoski. "Object Interconnections: CORBA and XML, Part 3: SOAP and Web Services," C/C++ Users Journal C++ Experts Forum, September 2001, <www.cuj.com/experts/1910/vinoski.htm>.
[4] Object Management Group. "The Common Object Request Broker: Architecture and Specification Revision 2.5," OMG Technical Document, September 2001, <www.omg.org/cgi-bin/doc?formal/01-02-33>.
[5] 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), <www.cs.wustl.edu/~schmidt/PDF/middleware-chapter.pdf>.
[6] Douglas C. Schmidt and Fred Kuhns. "An Overview of the Real-time CORBA Specification," IEEE Computer Magazine, June 2000, <www.cs.wustl.edu/~schmidt/PDF/orc.pdf>.
[7] Rebecca Callison, Marilynn Goo, and Daniel Butler. "Real-time CORBA Trade Study," D204-31159, The Boeing Company, 1999, Phantom Works, Seattle.
[8] 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.
Steve Vinoski is chief architect and vice president of Platform Technologies for IONA Technologies and is also an IONA Fellow. A frequent speaker at technical conferences, he has been giving CORBA tutorials around the globe since 1993. Steve helped put together several important OMG specifications, including CORBA 1.2, 2.0, 2.2, and 2.3; the OMG IDL C++ Language Mapping; the ORB Portability Specification; and the Objects By Value Specification. In 1996, he was a charter member of the OMG Architecture Board. He is currently the chair of the OMG IDL C++ Mapping Revision Task Force. He and Michi Henning are the authors of Advanced CORBA Programming with C++, published in January 1999 by Addison Wesley Longman.
Doug Schmidt is an associate professor member at the University of California, Irvine. His research focuses on patterns, optimization principles, and empirical analyses of object-oriented techniques that facilitate the development of high-performance, real-time distributed object computing middleware on parallel processing platforms running over high-speed networks and embedded system interconnects. He is the lead author of the book Pattern-Oriented Software Architecture: Patterns for Concurrent and Networked Objects, published in 2000 by Wiley and Sons. He can be contacted at schmidt@uci.edu.