ON REAL-TIME EXTENSIONS TO THE COMMON OBJECT REQUEST BROKER ARCHITECTURE: A POSITION PAPER Peter Krupp* Alice Schafer* Bhavani Thuraisingham* Victor Wolfe** * The MITRE Corporation, Bedford, MA ** The University of Rhode Island, Kingston, RI ABSTRACT This position paper describes some of the issues that need to be investigated in order to develop real-time data processing extensions to CORBA. In particular, issues on extensions to the object model, ORB, and IDL are discussed. 1. INTRODUCTION With the advent of increasingly complex applications that depend on timely execution (such as automated manufacturing, vehicle control, medical patient monitoring, and multi-media), many distributed computer systems must support components capable of real-time data processing. In a real-time system, the data as well as the transactions need to meet temporal constraints. For example, the data may have temporal consistency constraints stating how "old" it can be and still be considered valid. Transaction execution may have to meet start timing and deadline constraints. Recently, the object-oriented approach to developing real-time systems has gained a lot of attention. In this approach, the data along with a set of operations on the data (aka, methods) are regarded as objects. The temporal constraints are associated with the attributes and the methods of the objects. While the real-time systems community has been conducting research and development activities on the object-oriented approach to designing and developing real-time systems and software [THUR94,PRIC94,WOLF94], the Object Management Group (OMG) has been active in specifying standards for the interoperability of heterogeneous computing systems. Notable among the efforts of OMG is the Common Object Broker Architecture (CORBA). As stated in [CORB92], CORBA is structured to allow integration of a wide variety of object systems. The components of CORBA provide mechanisms by which clients transparently make requests of objects and receive responses so that interoperability between applications on different machines in heterogeneous distributed environments is enabled. Integration of CORBA technology and real-time systems technology is essentially an unexplored area. The interoperability of real-time systems via CORBA requires real-time extensions to CORBA. This position paper describes some of the issues that need to be investigated in order to develop real-time data processing extensions to CORBA. An overview of CORBA is provided in Section 2. Characteristics of real-time systems are discussed in Section 3. Real-time data processing extensions for CORBA are discussed in Section 4. The paper is summarized in Section 5. 2. OVERVIEW OF CORBA Three major components of CORBA are the object model, the Object Request Broker (ORB) and object adapters, and the Interface Definition Language (CORBA-IDL). We discuss the essential points of each component. The object model describes object semantics and object implementation. Object semantics describe the semantics of an object, type, requests, object creation and destruction, interfaces, operations, and attributes. Object implementation describes the execution model and the construction model. The ORB essentially enables communication between a client and a server object. As stated in [CORB92], a client is an entity that invokes an operation on the object, and the object implementation is the code and data that actually implements the object. The ORB, together with object adapters, provides all the mechanisms to find the object implementation for the request, to prepare the object implementation to receive the request, to communicate the data making up the request, to activate and deactivate objects and their implementations, and to generate and interpret object references. IDL is the language used to describe the interfaces that are called by client objects and provided by object implementations. IDL is a declarative language. Note that clients and object implementations are not written in IDL. The IDL grammar is a subset of ANSI C++ with additional constructs to support the operation invocation mechanism. An IDL binding to the C language has been specified; other language bindings are being processed. 3. CHARACTERISTICS OF REAL-TIME SYSTEMS As stated in Section 1, in a real-time system the data and the transactions have timing constraints associated with them. The data may have temporal consistency constraints associated with them; e.g. a piece of sensor data in a real-time control application may be valid for a certain number of seconds. The data may also be assigned criticality values to specify their importance. The transactions have to meet timing constraints. For example, a transaction in a real-time control application may have to execute within a specific deadline in order for the result to be considered correct, or, in some other case, to prevent a robot from walking into the wall. The origin of timing constraints in most real-time systems lies in the environment. When a real-time system such as the robot described above interacts with the environment physical processes governed by the laws of physics. To survive in the environment the robot must do the right thing at the right time. Crossing a busy street would be a good example of such a task. Another point that should be considered is that timing constraints are not necessarily satisfied by "faster" processing as in the above example. A third point to consider is that if timing constraints can be met reliably in a system this provides a means of synchronization of system activities that may require less communication activity (exchange of messages). This may enhance the performance of highly concurrent distribute and parallel systems by reducing the communication workload. [*****BHAVANI, WE NEED A REFERENCE FOR THIS(PETER)] A final point in the context of this example is that "speed" is not what is important but "predictability" is. For more information see Stankovic's Tutorial [STAN88A] and paper on the Misconceptions of Real-Time Systems [STAN88B]. In addition to timing considerations, criticalities are assigned to transactions. Criticalities are used to ensure that, when there is a scheduling conflict, the landing gear on the airplane will be put down before the air conditioning is adjusted. This is a general problem in real-time systems. We cannot economically design for the worst case by providing sufficient resources to meet all timing constraints all the times. Thus we need to provide a means for "graceful" degradation when demands for resources exceed the resources available. Especially important when interacting with the environment is the requirement that critical activities such as lowering the landing gear are given preference over non-critical activities such as the air condition as described above. Much of the research in real-time systems has been focusing on developing schedules where the transactions meet timing and criticality constraints. The schedules depend on whether the timing constraints are hard or soft. In the case of hard real-time constraints, it is critical that the transactions meet the timing constraints. In this case, the resources utilized by the transactions have to be known ahead of time. In the case of soft real-time constraints, there may still be some value in executing transactions even if they have missed the deadlines. We also recognize that dividing timing constraints into "soft" and "hard" categories may be overly simplistic. There are other models of timing constraints in which the utility of a result depends on the time at which it is delivered and "hard" and "soft" represent extreme limiting cases. This is seen in operating systems such as ALPHA [CLAR92]. There is also the notion of imprecise computation in which the constraint may be "hard" but the precision of the result depends on the time available to compute and improves montonically as a task executes. [***BHAVANI, THIS IS JANE LIU'S WORK.] Real-time operating systems, communication systems, and some aspects of real-time database systems are now commercially available. Research on the object-oriented approach to designing real-time systems is also in progress [THUR94,PRIC94]. 4. REAL-TIME EXTENSIONS TO CORBA In this section, we discuss the real-time extensions to the object model, the ORB and object adapters, and to IDL. 4.1 REAL-TIME OBJECT MODEL We propose that attributes and/or objects have timestamps and related timing information associated with them. In addition to the timestamping of time-sensitive data, information on the time-decay of short-lived data is needed. This timing information is used for determining temporal consistency of a set of attributes and for managing the data. Both for efficiency and for interoperability among ORB vendors, this requires a new CORBA data type capable of expressing time, preferably "global" time. Another important reason for a global time service is simply that system time will have little meaning without the notion of global time. We also propose that object operations provide information about their expected execution time and required resources so that a schedule of request activations can be set up, either statically or dynamically, to accomplish the required tasks. This schedule will be produced by a real-time scheduler but will need to interact with the ORB and object adapters. We also propose the assignment of criticality values to the objects in CORBA, as in [THUR94]. Criticality values specify the importance of the object. During time-constrained query and transaction processing, the objects with higher criticality values could be accessed first. If there is still time remaining, objects with lower criticality values would then be accessed. 4.2 REAL-TIME ORB and object adapter The major issues on developing a real-time ORB and object adapter involve the time constraints and criticalities attached to requests. That is, when clients request services from object implementations, time constraints are attached to the requests, such as start times, start events, deadlines, and periods, to be imposed on the execution of the operations. These ideas have been proposed in the RTSORAC model of [PRIC94]. Techniques to handle these timing constraints have to be developed. This is a heavily-analyzed problem in real-time scheduling [****PETER, REFERENCES?] which needs to be evaluated for applicability to the ORB environment. For instance, if an object server is to have some responsibility in controlling the order of execution of its requests, the entire request queue needs to be available for reading and writing, not just the top of the queue. An example of how CORBA can be used to advantage in a real-time problem: an operation may have multiple implementations which are differentiated by the accuracy of their computed result and their time to execution (worst-case, average, etc). When one implementation is too time-consuming to meet the required deadline, the best implementation which is feasible can be selected by the ORB/object adapter. Although no work has been reported on real-time extensions to ORB, work in [WOLF94] on real-time extensions to Texas Instruments' Open Object-Oriented Database System (Open OODB), which is currently stated to be consistent with CORBA specifications, is relevant. These extensions follow the RTSORAC model (see Section 4.1) and thus would be consistent with our proposed changes to the Object Model. The RT Open OODB system utilizes a real-time POSIX 1003.4 compliant operating system and has added a real-time persistent store. This store uses DBx Inc.'s ZIP-RTDBMS, which is a rudimentary commercial real-time database management system. Real-time extensions to SQL, features of the RTSORAC model, as well as a real-time object manager are being implemented. 4.3 REAL-TIME IDL Real-time extensions to IDL will depend on the extensions proposed for the object model and the ORB. In general, extensions to IDL will include specifying time constraints and temporal consistency constraints on IDL constructs such as operation, and attribute declarations. Recently several efforts on real-time extensions to programming languages such as C and C++ have been proposed (see for example, [WOLF93,ISHI92]). These extensions include syntax and semantics for expressing start times, deadlines, periods and exception handling for time constraint violations. The synthesis of these extensions with C++ should facilitate using them as a basis for real-time extensions to IDL. 5. FUTURE CONSIDERATIONS In this paper we have provided an overview of CORBA, the characteristics of real-time systems, and discussed possible extensions to CORBA to support real-time data processing. With the advent of computer control in complex real-time applications, the integration of real-time processing components in a CORBA system should be encouraged. The ideas discussed in this paper need to be examined further and a detailed set of requirements to be imposed on CORBA for real-time data processing need to be formulated. The next step is to meet with other interested parties to further explore and prototype real-time processing extensions to CORBA. The goal is to have a set of workable real-time extensions incorporated into the OMG standards and available for production real-time applications. This paper provides the initial step towards this goal. REFERENCES [CLAR92] Clark, R., Jensen,E.D., Reynolds, F., An Architectural Overview of the Alpha Real-Time Distributed Kernel, Proceedings of the USENIX Workshop on Microkernels and Other Kernel Architectures,1992 [CORB92] The Common Object Request Broker Architecture, Published by OMG and X/Open, 1992 [ISHI92] Ishikawa, Y, H. Tokuda, and C. Mercer, An Object-Oriented Real-Time Programming Language, IEEE Computer, 25(10),66-73, Oct. 1992. [LUI******REFERENCE date place??? Scheduling Real-time Periodic Jobs that Allow Imprecise Results [PRIC94] Prichard et al, RTSORAC: A Real-time Object-Oriented Database Model, Proceedings of the International Conference on Database and Expert System Applications, 1994 [STAN88A] Skankovic, J., Real-Time Computing Systems: The Next Generation, Hard Real-Time Systems Tutorial, Feb. 1988 [STAN88B] Skankovic, J., Misconceptions About Real-Time Computing, IEEE Computer, 21(10), Oct. 1988 [THUR94] Thuraisingham, B., and A. Schafer, RT-OMT: A Real-time Object Modeling Technique for Designing Real-time Database Applications, Proceedings of the IEEE Real-time Systems Applications Workshop, 1994 [WOLF93] Wolfe, V. F., S. Davidson, and I. Lee, RTC: Language Support For Real-Time Concurrency, Real-Time Systems Journal, 5 63-87; Spring 1993. [WOLF94] Wolfe, V. et al, The Design of Real-time Extensions to the Open Object-Oriented Database System, Proceedings of the IEEE Workshop on Object-Oriented Real-time Dependable Systems, 1994.