RTAS '97 RT CORBA Panel Discussion

Contribution to RT CORBA Panel Discussion:

1) What do you see as the major applications of RT CORBA?

RT systems with processing demands so great that distribution is necessary. And, RT systems that can benefit from using CORBA services such as the Event, Time, and Persistence Services. Just looking at the Event Service as an example, it simplifies application software by allowing decoupled suppliers and consumers, asynchronous event delivery, and distributed group communication. However, the standard CORBA Event Service specification lacks other important features required by real-time applications such as real-time event dispatching and scheduling, periodic event processing, and efficient event filtering and correlation mechanisms. We view enhancements to the Event Service that address these deficiencies as part of RT CORBA.

RT systems with critical deadlines require predictable timing characteristics, and above all, correctness. Other RT systems demand low development cost and fast time to market. It's been very interesting to us to see that these kinds of systems don't seem to impose different requirements on distribution or on the common services. CORBA factors out common functionality that is sufficiently complex to be worth developing ``good'', reusable solutions.

RT systems have specific needs such as QoS guarantees and high performance that can, and should, also be factored out. RT CORBA is the natural common factor.

RT systems are typically used in more safety critical and demanding applications than conventional distributed systems. The major technical challenges include the ability to achieve and demonstrate correctness, and providing sufficiently optimized ORBs. The barrier to viable RT CORBA is that most of the key RT issues are associated with aspects of an end-to-end system design that transcend the layering boundaries traditionally associated with CORBA. That's why, for example, we cover the OS, I/O subsystem, and network adapters in our TAO work since they are crucial to providing a vertically integrated solution.

Academics are overcoming the technical barriers. But so are vendors and end-users. From an academic perspective, RT CORBA is a bit unusual in that these groups are much closer than many other fields. We're working on challenges that will have nearly immediate benefits to everyone involved.

Government's role should probably be to ensure that CORBA is widely adopted in DoD and other agency projects as a common architecture for distributed computing. The economies of scale of a large-scale migration to the standard are obvious, but it requires a long-term commitment and investment.

Very promising: RT system development strategies will migrate towards those used for ``mainstream'' systems in order to achieve lower development cost and faster time to market. We have seen RT software development projects that have lagged in terms of design and development methodologies (and languages) by _decades_. These projects are unbelievably difficult and costly to maintain. They are so specialized that they cannot be adapted to meet new market opportunities.

The flexibility and adaptability offered by CORBA make it very attractive for use in RT systems. If the RT challenges can be overcome, and progress so far shows that they can, then use of RT CORBA is compelling. And the solutions to these challenges will sufficiently complex yet general that it will be well worth re-applying them.

Finally, RT CORBA can be adapted to ``niche'' markets, e.g., the RTOS market, that aren't well covered by more traditional major players, e.g., Sun, Microsoft, IBM. In that sense, RT CORBA has an advantage over other DOC technologies (such as DCOM and Java RMI) since it can be integrated into a wider range of platforms, i.e., it's open!