1 Rationale for the Direction of the Distributed Real-Time Specification for Java Panel Position Paper E. Douglas Jensen The MITRE Corporation jensen@real-time.org, http://www.real-time.org The Distributed Real-Time Specification for Java (DRTSJ) is being developed by the JSR-50 Expert Group in Suns Java Community Process. The Expert Group is led by The MITRE Corporation, and includes approximately 20 other member enterprises from academia, the U.S. government, and industrial corporations in the defense, telecommunications, industrial automation fields. The terms distributed, real-time, and distributed real- time are employed for so many disparate kinds of computer systems, that the Expert Group deemed it unlikely that any single DRTSJ could do justice to them all. Therefore, the intended target space of distributed real-time systems had to be at least roughly delineated for both the Expert Group and the prospective DRTSJ users. This position paper synopsizes some of the rationale for the Expert Groups focus. For the purpose of the DRTSJ, the term distributed system informally refers to a computing system whose programming model is based on there being application- level entities that exhibit multi-node behaviors. In real-time distributed computing systems, multi-node application behaviors may have end-to-end time constraints. The defining characteristic of any real-time distributed computing system, whatever its programming model, is that the timeliness (optimality and predictability of optimality) of each multi-node application behavior on each individual node it involves, and collectively end- to-end on all nodes it currently involves is acceptable to that application under the current circumstances. The current circumstances include the latency characteristics of the underlying infrastructure (node OSs, network), the attributes of the system load, etc. All those circumstances are known and controlled Æ priori in static distributed real-time computing systems, notably including hard real-time ones. But in general, not all of those circumstances are (or can be) known and controlled Æ priori the system is dynamic to the degree that is the case. The Real-Time Specification fir Java is oriented toward dynamic (non-static) systems, although it has been proven to successfully support static hard real-time computing. Similarly, the DRTSJ is oriented toward the general case of dynamic distributed real-time computing systems, although we expect it to also be capable of supporting the special case of static hard real-time ones. In most cases, the extent to which end-to-end multi-node timeliness can be achieved depends on the extent to which each multi-node application behaviors timeliness properties e.g., end-to-end time constraints, expected execution time, execution time received thus far, etc. are explicitly employed for appropriately coherent resource management (particularly scheduling) on each node currently involved in that application multi-node behavior. Ideally, that includes scheduling of other sequentially shared hardware resources, notably the network connecting those nodes, and software ones as well, notably synchronizers (e.g., locks). Thus (in dynamic distributed real-time computing systems) these properties need to be propagated among corresponding computing node resource managers in operating systems, JVMs, middleware, and even (directly or indirectly) device e.g., network, storage controllers. Acquiring, propagating, depositing, and employing this information should be done transparently to the application programmers; indeed, often some of this information is not even accessible by the application programmers. There are many different kinds of distributed systems. However, the vast majority of deployed distributed real- time computing systems employ at least one of the following programming models: • control flow: movement of an execution point, with or without parameters, among application entities e.g., remote procedure call (RPC) and remote method invocation (RMI) • data flow: movement of data, without an execution point, among application entities e.g., publish/ subscribe and bulk data transfers • networked: asynchronous or synchronous movement of messages, without an execution point, among application entities e.g., message passing IPC Proceedings of the Fifth IEEE International Symposium on Object-Oriented Real-Time Distributed Computing (ISORC02) 0-7695-1558-4/02 $17.00 ' 2002 IEEE