Real-Time Middleware

Douglas Stuart
Nancy Eickelmann
Microelectronics and Computer Technology Corporation
3500 West Balcones Center Drive
Austin, TX 78759-5398
{stuart,ike}@mcc.com
(512)-338-{3478,3661}

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.

Scope of Real-time Middleware Support

The first issue that must be decided is the scope of middleware responsibilities in the area of real-time. Middleware can play one of four roles (None, Respect, Support, Provide) in a real-time context.

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.

Middleware Mediation

Related to the degree of support for real-time computing is the mediation the middleware provides between applications and infrastructure. Middleware provides an abstraction of the underlying system and network infrastructure to applications that use it. This abstraction allows developers to write distributed applications without reference to the underlying system, network architectures, and interfaces. Although this is generally a virtue for non-real-time applications, it may be catastrophic for real-time applications. To meet real-time constraints, real-time applications must be aware of, and have control over, the behavior of the underlying infrastructure that is abstracted away by the middleware. Therefore, middleware must include sufficient features in the abstraction it provides for applications to achieve real-time goals.

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.

Interaction of Real-time and Nonreal-time

The final issue is the interaction of real-time and non-real-time middleware. Traditional real-time systems have limited interactions with non-real-time systems. The new generation of real-time applications will frequently not have this luxury. Middleware can provide an interface between real-time and non-real-time domains. To do so, the interactions between real-time and non-real-time middleware must be defined. This is an important issue as shown by its prominence in the OMG Realtime RFP [1].

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.

Conclusions

The current generation of distributed object-oriented middleware does not support real-time applications and will not suffice for many emerging real-time applications. Parallel streams of research in CORBA and quality-of-service constrained computation technologies are addressing these deficiencies. The convergence of these efforts is being expedited by awareness of the need for real-time extensions to CORBA. Real-time aware middleware opens the possibility for more component-based approaches to developing traditional real-time systems, as well as adding real-time capabilities to otherwise non-real-time applications. The coming distributed infrastructure must support real-time computing by providing the necessary bridge between current practice and future need.

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.