 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 50: Distributed Real-Time Specification
JCP version in use: 2.1 Java Specification Participation Agreement version in use: 1.0 Description: The Distributed Real-Time Specification for Java extends RMI in the Real-Time Specification for Java, to provide support for predictability of end-to-end timeliness of trans-node activities. Please direct comments on this JSR to the Spec Lead(s) Team
This JSR has been Dormant The following has been changed from the original proposal: 2011.02.15: Specification Lead: Dr. James Hunt, Aicas GmbH E-mail address: jjh Telephone: +49 721 663 968 22 Fax: +49 721 663 968 99 Original Java Specification Request (JSR) Identification | Request | Contributions Section 1: Identification
Submitting Participant: Mitre Corporation
Name of Contact Person: E. Douglas Jensen
E-Mail Address: jensen@real-time.org
Telephone Number: +1 508 653 5653
Fax Number: +1 508 653 3342
Submitting Participant: IBM Corporation
Name of Contact Person: Greg Bollella
E-Mail Address: bollella@us.ibm.com
Telephone Number: +1 919 254 4602
Fax Number: +1 919 254 5263
Note that this information has been updated from this original proposal. List of other Participants who endorse this JSR:
Section 2: Request
2.1 Please describe the proposed Specification:The proposed JSR is for a distributed extension to the Real-Time Specification for Java ("distributed real-time Java"). One approach could be to make RMI capable of supporting application-specific predictability of end-to-end timeliness in trans-node programs by propagating timeliness attributes. 2.2 What is the target Java platform? (i.e., J2EE, J2SE, J2ME)The target Java platform will be described by the Real-Time Specification for Java ("RTSJ") currently underway in JSR-000001 2.3 What need of the Java community will be addressed by the proposed specification?The need is that many real-time applications (for example, in the industrial automation, defense, and telecommunication domains) which involve a multiplicity of computing nodes, must satisfy trans-node end-to-end timeliness requirements. 2.4 Why isn't this need met by existing specifications?The RTSJ is deliberately focused on centralized (single computing node) systems. This proposed specification will be consistent with that specification, and will add further extensions to it for distributed (multi-node) real-time systems. 2.5 Please give a short description of the underlying technology or technologies:For the purpose of this JSR, the term "distributed system" informally refers to a system whose programming model is based on there being objects which are located on a multiplicity of physical computing nodes, and which may interact. Distributed systems can be categorized in various ways; here we categorize them in one possible way according to their programming model for interaction:
(Of course, the latter two categories of distributed systems are implemented on some form of message passing mechanism below the programming model.) These categories of distributed systems have long histories of successful use in real-time as well as non-real-time application domains. In addition, distributed systems, particularly those employing Java, could have mobile objects; such systems are gaining interest but currently have little history of use in real-time domains (e.g., industrial automation, defense, telecommunications). This JSR is focused on the second category -- control flow style real-time distributed object systems. More specifically, control flow in this context means the movement of a distributed (i.e., trans-node) program's execution point among the program's constituent objects which may reside on a multiplicity of physical computing nodes. In Java, control flow is based on threads performing RMI's, and there may be multiple concurrent control flows in a distributed program. A control flow in a distributed Java program can be thought of as extending and retracting its locus of execution point movement among remote object instances by a sequence of RMI's and RETURN's. Each control flow may have one or more execution scheduling attributes -- e.g., priority, importance, time constraints such as deadlines or utility functions -- that specify the acceptable timeliness for it completing the sequential execution of methods in object instances that may reside on multiple physical nodes. The semantics of acceptability with respect to these end-to-end timeliness attributes is defined by the application and the chosen scheduling policy. The purpose of this proposed Distributed Real-Time Specification for Java is to provide for acceptably predictable (as defined by the application) end-to-end timeliness of control flow executions. The most fundamental requirement is that there be end-to-end transitivity of a control flow's locus of execution point movement among local and remote objects. This could be accomplished either by the distributed real-time Java programming model including a new first class abstraction for a control flow (such as the distributed thread in the Alpha kernel and elsewhere, and the activity suggested in the Real-Time CORBA 1.0 standard), or by the distributed real-time Java JVM's synthesizing a functional equivalent using local threads (as done in the MK7.3A OS's microkernel and elsewhere). With either technique, each control flow has attributes -- primarily (for the purpose of this JSR) one or more current execution scheduling attributes (e.g., priority, deadline, utility function) which apply at every node it visits, to ensure end-to-end predictability of timeliness. Thus, appropriate scheduling parameters must be propagated among corresponding JVM's with the execution point movement. (Other propagated parameters could include those for security, fault tolerance, transactional context, etc.). Real-time control flows necessitate a number of concomitant real-time facilities (not necessarily within the scope of this JSR) which would be facilitated by appropriate support from distributed real-time for Java, including (but not limited to) the following.
There are several reasons why control flow is proposed here as the initial distributed extension of the RTSJ (one or more other -- e.g., data flow style -- distributed extensions of the RTSJ could be the subject of subsequent JSR's). The networked programming model is incongruous with Java's programming model, and is so rudimentary that adding the necessary distributed real-time capabilities is more difficult than creating the control flow model. Real-time control flow based on RMI is a natural, well understood, incremental extension to the RTSJ. Data flow abstractions can be built cost-effectively using control flow abstractions (as is currently done with CORBA and COM), while the converse (e.g., method invocations based on TCP/IP streams) is semantically difficult, especially in real-time contexts. A control flow style distributed real-time specification for Java complements, rather than competes with, the OMG Real-Time CORBA 1.0 standard. Real-Time CORBA 1.0 ORB's are control flow style (currently no other CORBA services have been specified for real-time). CORBA is intended primarily for heterogeneous languages and platforms; it provides rich functionality and wide interoperability, but even real-time CORBA ORB's usually suffer from being heavier weight than is acceptable for most homogeneous all-Java distributed real-time systems. In addition, control flows correspond closely to the activities suggested in the Real-Time CORBA 1.0 standard. The control flow style distributed programming model is applicable to real-time systems which are either "hard" (in the sense of having absolutely predictable timeliness) or "soft" (in the sense of having statistically characterized timeliness). That predictability spectrum is orthogonal to application time-frame magnitudes, which can range from microseconds to megaseconds, as explained in Section 1 Concepts of the NIST Real-Time Java Requirements document. This specification is intended to address application timeliness requirements everywhere in that two-dimensional predictability/time-frame space of distributed real-time Java systems. 2.6 Is there a proposed package name for the API Specification?javax.realtime.distributed is suggested. 2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?The timeliness properties of this proposed distributed real-time Java are obviously affected by the timeliness properties of the underlying OS (as are those of the RTSJ) and of the internode communication network. The end-to-end predictability of the distributed real-time Java is a function of how the magnitudes and predictability of the application time constraints, and of the application thread execution durations, relate to the magnitudes and predictability of the OS and network latencies. Traditional distributed real-time applications for device level monitoring and regulatory control often have relatively short time constraints and execution durations that require the low and highly predictable latencies of real-time OS's and real-time networks. Many other -- less traditional but extremely important -- distributed real-time applications, such as for automated control at higher levels in process, manufacturing, telecommunication, and defense enterprises, usually include time constraints and execution durations that are large with respect to the OS and network latencies, allowing the use of mainstream products. This distributed real-time specification for Java, like the RTSJ and like Real-Time CORBA, is intended to proactively provide timeliness properties that are acceptable (as specified by the application), given the behavior of its substrate. Of course, as always in distributed real-time systems, if that performance is infeasible, the application designers/users must change their acceptability criteria or the characteristics of the substrate. 2.8 Are there any security issues that cannot be addressed by the current security model?Different distributed real-time systems have a variety of different, application-specific, potential security issues. Many are addressed by the current security model. Control flow introduces the opportunity, and often the necessity, to propagate security attributes along with the control flow execution point as it moves across node boundaries. 2.9 Are there any internationalization or localization issues?There are no internationalization or localization issues. 2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?This distributed real-time Java specification may benefit from, or even require, minor revisions to the RTSJ being developed in JSR-000001. The Distributed Real-Time Specification for Java is expected to involve RMI, events, thread transfer of control, and thread scheduling. Section 3: Contributions
3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.One possible focus of the proposed Distributed Real-Time Specification for Java could be real-time RMI. In this JSR (at least) "real-time RMI" does not mean "real fast RMI" or even "real predictable RMI" (although those are important second order performance goals). Rather, it means that RMI's and return's preserve the timeliness semantics of the control flow in which they are performed. Execution of the control flow is governed by its current execution scheduling parameters (in the context of the system's scheduling optimization criterion), regardless of the control flow's execution point transiting nodes (and taking into account scheduling parameters associated with the occurrence of relevant events, control flow control actions, and failure handling). Real-time RPC and method invocation are relatively well understood (albeit not yet widely applied) technology. The principles and techniques for the concomitant distributed real-time event handling, control flow control action, concurrency control, and failure detection/handling facilities are less well and widely understood, especially in the context of dynamic real-time systems -- but well enough that the minimum necessary hooks to support them can be included in this specification. Real-time method invocation (and concomitant facilities) were developed for the distributed thread, and associated programming model, abstractions in Jensen's Alpha distributed real-time OS kernel at CMU [Northcutt 87], KSR, and Concurrent Computer [Clark et al. 92]. Additional insight into the programming model can be gained from an example application created jointly by CMU and General Dynamics [Maynard et al. 88], and from the collaboration of SRI International, CMU, OSF/RI, and Digital Equipment on a multilevel secure version of Alpha [Greenberg 93]. The Alpha distributed thread technology was subsequently adapted by Ford and Lepreau at the Univ. of Utah to create migrating threads for the Mach 3 kernel [Ford and Lepreau 93] [Ford and Lepreau 94]. Microsoft Research also adapted the Alpha distributed thread model for their Rialto real-time OS [Jones et al. 95]. Sun (apparently independently) devised an RPC implementation technique for their Spring research OS similar to that used under Alpha's distributed threads [Hamilton and Kougiouris 95]. The Alpha distributed thread and associated abstractions and facilities were developed further by The Open Group Research Institute in their MK7 OS [Goldstein and Wells 93] [Open Group 98], which is the anticipated basis for a forthcoming OS from a major computer vendor. These abstractions and facilities in the MK7 OS were utilized effectively in a large scale, multi-year, U.S. Navy/DARPA technology demonstration leading to a next generation Aegis combat system [NSWC 99]. At the same time, Digital Equipment and IBM jointly performed additional development of these abstractions and facilities for OS/2 for PowerPC (no public references available). Subsequently, Compaq (ne'e Digital Equipment) has continued this work in the context of a real-time DCOM and a Win32-compatible real-time distributed OS (no public references are yet available). DARPA ITO's Quorum program includes as one of its architectural tenets "path based resource allocation" inspired (in part at least) by distributed threads [Koob 98]. The writers of OMG's Real-Time CORBA 1.0 specification [OMG 99a] came to their own recognition of the value of a distributed thread-like abstraction for real-time distributed object systems. To avoid further delaying an already very late specification, they only included mention of "activities" as an implementation hint. The activity concept was explicitly incorporated into the subsequent initial joint proposal for Dynamic Synchronized Real-Time CORBA [OMG 99b]. The RTSJ specification by the JSR-000001 Expert Group [Bollella 99] [RTEG99] already includes asynchronous transfer of control -- perhaps the most challenging facility needed by real-time RMI. References Bollella 99 Real-Time Java: Status and Architecture, www.rtj.org/rtas99/rtas.htm, June 1999.
Clark et al. 92 Clark, R.K, E.D. Jensen, and F.D. Reynolds, An Architectural Overview of the Alpha Real-Time Distributed Kernel, Proc. USENIX Workshop on Microkernel and Other Kernel Architectures, Seattle, April 1992, USENIX. Clark et al. 93 Clark, R.K., D.M. Wells, I.B. Greenberg, and E.D. Jensen, Effects of Multilevel Security on Real-Time Applications, Proc. Computer Security Applications Conf., Baltimore, December 1993, IEEE. Ford and Lepreau 93 Ford, B. and J. Lepreau, Microkernels Should Support Passive Objects, Proc. I-WOOOS, December 1993, IEEE. Ford and Lepreau 94 Ford, B. and J. Lepreau, Evolving Mach 3.0 to a Migrating Threads Model, Proc. Winter USENIX Conf., January 1994, USENIX. Goldstein and Wells 93 Goldstein, I. and D.M. Wells, Alpha/Mach Integration Study, April 1993, The Open Group (ne'e OSF) Research Institute). Greenberg et al. 93 Greenberg, I.B., P. Boucher, R.K. Clark, E.D. Jensen, T. Lunt, P. Neuman, and D.M. Wells, The Secure Alpha Study -- Final Summary Report, March 1993, Computer Science Laboratory, SRI International. Hamilton and Kougiouris 93 Hamilton, G. and P. Kougiouris, The Spring Nucleus: A Microkernel for Objects, Proc. 1993 Summer USENIX Conference, June 1993, USENIX. Jones et al. 95 Jones, M.B., P.J. Leach, R.P. Draves, J.S. Barrera, III, Support for User-Centric Modular Real-Time Resource Management in the Rialto Operating System, Proc. of the Fifth Workshop on Hot Topics in Operating Systems, May 1995, IEEE. Koob 98 Koob, G., Quorum, 1998, http://www.darpa.mil/ito/research/quorum/index.html Maynard et al. 88 Maynard, D.P., S.E. Shipman, R.K. Clark, J.D. Northcutt, R.B. Kegley, B.A. Zimmerman, and P.J. Keleher, An Example Real-Time Command, Control, and Battle Management Application for Alpha, TR-88121, Archons Project, CMU Computer Science Dept., December 1988. Northcutt 87 Northcutt, J.D., Mechanisms for Reliable Distributed Real-Time Operating Systems -- The Alpha Kernel, 1987, Academic Press, ISBN 0-12-521690-4. NSWC 99 High Performance Distributed Computing (HiPer-D), http://www.nswc.navy.mil/hiperd/index.shtml, 1999, NSWC. Open Group 98 MK7.3a Release Notes, 1998, The Open Group. OMG 99a Real-Time CORBA 1.0 Specification, ORBOS/99-02-12, and errata, ORBOS/99-03-29, 1999, Object Management Group. OMG 99b Joint Initial Proposal for Dynamic Real-Time CORBA, ORBOS/99-10-06, October 1999, Object Management Group. RTEG99 The Real-Time for Java Expert Group, The Real-Time Specification for Java, 1999, http://www.rtj.org. 3.2 Explanation of how these items might be used as a starting point for the work.The prior art and experience with real-time remote method invocation, distributed events, and distributed trans-node thread control., provide many lessons learned about the design and implementation of control flow style real-time distributed object systems. RTSJ's asynchronous events and asynchronous transfer of control are directly relevant to this proposed specification. |
||||||||||||||||||||||||||||||||||||||
