The demand for real-time applications that encompass everything from video-on-demand and real-time telephone system management to traditional embedded systems is increasing significantly. We believe a new generation of real-time applications is now possible due to two parallel streams of research. First, the development of widespread standardized object-oriented middleware that supports the development of applications built from components using high-level abstractions of the underlying computational and network infrastructure. This is realized in the CORBA ideal, as it allows for an application to use components that are identified dynamically and without regard to location. Second, support for quality-of-service constrained computations by the underlying infrastructure has also risen. This is realizable with the introduction of real-time POSIX, ATM, RSVP, and IP version 6. Until very recently, these two developments have been progressing along non-intersecting trajectories, however convergence could result from real-time extensions to CORBA.
It is therefore timely that OMG has just this year released a Request For Proposals[1] for real-time extensions to CORBA. This provides an opportunity for crafting a consensus between the real-time and middleware communities for a new generation of object-oriented middleware that can be used to develop real-time applications. It is our position that consensus with respect to real-time middleware must address a number of issues to be successful. These issues include defining a scope for middleware responsibilities, mechanisms for middleware mediation between infrastructure and application, and interactions between real-time aware and non-aware middleware and middleware services. This position paper addresses these three issues and provides insight into the areas of open research and opportunities to achieve a viable componentware market for real-time applications.
None: The simplest is to be oblivious to real-time considerations. This choice will bar the middleware in question from hard real-time environments, where failure of an application to meet a deadline is considered to be a system failure. If the middleware is unaware of real-time considerations, it may make resource allocation decisions that prevent an application from satisfying its timing constraints.
Respect: The second choice is to respect the real-time requirements of applications. In this case, the middleware does not actively work to achieve real-time goals, but does support those activities carried out by an application, for example by respecting application level priorities when allocating resources. Such middleware would be suitable for some soft-real time applications, where the value of a computation depends on its timeliness.
Support: The third choice would be to support real-time activities. This could include providing real-time scheduling of middleware activities, for example offering resource reservation and rate monotonic scheduling of resources. This type of middleware could be used for hard real-time applications, but would require the application to schedule middleware activities.
Provide: The final level of real-time support is for the middleware to offer real-time performance of applications as one of its functionalities. This could include application level scheduling of resources, not just of the middleware but of the underlying infrastructure. This type of middleware could be used to impart a degree of real-time functionality to otherwise non-real-time applications.
Current middleware typically falls into the first (None) category. The current OMG Realtime RFP envisions real-time ORBs that fall into the third (Support) category, while suggesting that conventional ORBs should move into the second (Respect). The TAO ORB as described in [2] falls into the fourth (Provide) category, since it actually performs rate-monotonic scheduling of applications.
It is our position that middleware that supports real-time activities will be necessary. Middleware that actively provides real-time functionality is desirable, since it would more readily support new types of real-time applications being made possible by the emerging infrastructure technologies.
Providing real-time characteristics as a part of the abstraction offered by middleware can be accomplished by varied means. The middleware can provide real-time functionality, as in case four above. It could also allow applications using the middleware access to the real-time features of the underlying infrastructure. This can be done either by providing an API for defining real-time properties of middleware requests that are passed through to the infrastructure, or by allowing applications to bypass the middleware and directly affect the real-time behavior of the infrastructure. Both of these alternatives are currently under consideration or development. The current OMG Realtime RFP includes the potential for establishing communications using real-time protocols. Clearly a real-time API is more in the spirit of middleware by providing a common abstraction. Providing access to operations of the underlying infrastructure allows the ultimate in control over infrastructure features not typically recognized by the middleware.
Further research is needed to evaluate the tradeoffs of both approaches. Benefits must be weighed not only with respect to current technologies and real-time applications but with regard to expected evolutionary paths of emerging technologies.
How to perform such interaction is also an open research question. A significant amount of research indicates the difficulty of combining real-time and non-real-time applications in the same environment. For example, a system composed of real-time and non-real-time tasks may not be able to schedule any of the non-real-time tasks and still satisfy all of its real-time requirements in the presence of potential overload, even if no overload occurs [3]. This is clearly not acceptable or possible for the sorts of highly distributed and dynamic environments to be supported by the next generation of middleware. Some way of resolving this conflict is necessary to achieve the desired componentware markets envisioned as a result of these efforts.
References
[1] OMG, Realtime CORBA 1.0 Request for Proposal. OMG Document:orbos/97-09-31, Framingham, MA
[2] D. Schmidt, D. Levine, and T. Harrison. The Design and Performance of a Real-time CORBA Object Event Service. Proceedings of OOPSLA '97, Atlanta, GA, October 1997.
[3] R. Howell. Optimal Scheduling and Handling Potential Overload. KSU TR-CIS-93-14, 1994.