© 2006 the mitre corporation. all rights reserved a status report 11 october 2006 4th international...

© 2006 The MITRE Corporation. All rights reserved

A Status Report

11 October 2006

4th International Workshop on Java Technologies for Real-time and Embedded Systems (JTRES 2006)

JSR-50: The Distributed Real-Time

Specification for Java

Jonathan S. [email protected]

Lead EngineerThe MITRE Corporation

JSR-50 Implementation Lead

Dr. E. Douglas [email protected]

Consulting ScientistThe MITRE Corporation

JSR-50 Expert Group Lead

Slides available at http://andersoj.org/jtres06

2

© 2006 The MITRE Corporation. All rights reservedRevised 11 October 2006

Agenda

Key Principles from the DRTSJ Expert Group (JSR-50) Elements of the evolving DRTSJ

• Distributable Threads Programming Model

• Distributable Thread Integrity

• RTSJ Relationships DRTSJ Reference Implementation Schedule and Future Work

3


Key Principles of the DRTSJ EG

Bring distributed real-time to Java, not bring Java to traditional distributed real-time

Provide support for end-to-end application properties Distributed objects and operations are distinguished

from local objects and operations, for the obvious reasons of latency, partial failures, and concurrency control

Address current real-time system practice, as well as allow future implementations to include advanced features

RTSJ applications should run unmodified on DRTSJ-compliant JVMs, with some caveats on their distributed behavior

Do not dictate the use of an RTSJVM or real-time transport

• Spec should not limit interoperability across RT and non-RT platforms

4


Key Principles:Bring distributed real-time to Java

It is the intention of the JSR-50 Expert Group to bring facilities required for constructing the DRTSJ style of distributed real-time systems into the Java programming environment in a way that is least disruptive to experienced Java programmers

Build upon (not replace) Java's distributed object model as expressed in the Java RMI specification (as proposed in JSR-50)

• New wire protocol(s) are likely required Therefore, DRTSJ is specifically for Java, and is not

intended to be language agnostic (as, for example, CORBA is more or less intended)

5


Key Principles:(Don’t) Bring Java to distributed real-time

The opposite approach of bringing Java to distributed real-time could conceivably be performed with a binding of the RTSJ to Real-Time CORBA

• but that would require Java programmers to learn about how to use CORBA

Each approach is reasonable for some contexts• our choice for the DRTSJ is not intended to compete with

that alternative (should it eventually materialize)

• but instead to complement it and provide the users two options

Nothing constrains a vendor from implementing the DRTSJ with IIOP or even full RT-CORBA underneath

• In principle, DRTSJ threads can map to RT-CORBA 1.2 threads

6


Key Principles:Support end-to-end application properties

Properties such as timeliness and fault management Raison d'être of distributed real-time systems By definition, some multi-node behaviors in distributed

real-time systems have end-to-end time constraints which must be respected

Other end-to-end properties may also be required, such as fault management, security credentials, serialization, etc.

Traditionally ensuring these end-to-end properties has been forced on the application designers

• who must create ad-hoc (and error-prone) mechanisms to attain them

• typically without proper experience or education

• and at high recurring and non-recurring costs Maintaining end-to-end properties requires providing

and using appropriate end-to-end context

7


Key Principles:Support end-to-end application properties

Existing Java distribution models (e.g., JMS, JXTA) do not provide appropriate end-to-end context…

… and thus force any end-to-end timeliness and integrity to be a higher level – usually application programmers’ – responsibility, at greater recurring costs

DRTSJ must provide basic mechanisms for passing and acting upon the required end-to-end context among the nodes participating in any given distributed behavior, respecting the desired end-to-end properties

8


Key Principles: Address current real-time system practice while allowing advanced features

DRTSJ will provide a specification which targets those technologies, techniques, and interfaces that have been well-tested, subjected to review, and successfully employed in the construction of non-trivial distributed real-time systems

Additional promising technologies under development by the research community which fail to meet those specification criteria may be provided in versions of the DRTSJ Reference Implementation (RI)

Such versions of the RI serve as an active testing ground for innovative technologies which may appear in future versions of the specification

9


Key Principles:Not dictate use of RTSJVM or real-time transport

Some practitioners who misinterpret “real-time” as being only the special case of “hard real-time” consequently misinterpret “distributed real-time” systems as requiring deterministic (synchronous) networks

The DRTSJ allows the inevitable mixtures of regular and RTSJ-compliant JVMs, and specifies the timeliness behaviors that result

Deliberately silent on the topic of the transport, which is regarded as a quality of implementation issue

As with Real-Time CORBA, pluggable, real-time, and application-specific transports may be addressed in a subsequent specification

10


Key Principles led to minimum required components for final DRTSJ specification

A distributable threads programming model A distributable thread integrity framework A scheduling framework

11


Distributable threads programming model

Many distributed system applications (or portions of applications) are most naturally structured as

• a multiplicity of sequential (i.e., linear) flows of execution and data

• within and among known objects (i.e., that do not need discovery)

• asynchronously and concurrently A distributable thread is a single logically distinct (i.e.,

having a globally unique identifier) locus of control flow movement that extends and retracts through local and (potentially) remote objects

The presence of a distributed object model (RMI) in the Java platform makes the distributable thread concept a straightforward step for Java programmers into the world of distributed real-time programming

12


A distributable thread extends and retracts among objects and (potentially) nodes

Object A Object B Object C Object D

dthread 1 dthread 2 dthread 3

Returns have not yet occurred

13


Example Application:battle management sensor-to-shooter chain

PlotCorrelatorSensors

TrackHdlr

TrackDB

IDData

ThreatAssessor

TrackID

StoresMgr

WeaponCtlrs

ThreatData

14


Distributable thread model: causal sequential control/data flow among known objects

Model imposes no constraints on the presence, size, or structure of the data that may be propagated as part of the thread's flow

Commonly, input parameters may be propagated with thread invocations, and results may be propagated back with returns

When the principal purpose for a thread is movement of associated data, the model can be viewed as a data flow one as much as, or more than, a control flow one

Each invoked object's ID is known by the invoking object (i.e., the invoked object does not have to be discovered)

There are end-to-end properties that must be maintained, including timeliness, fault management, and control (e.g., concurrency, pause/resume, signaling of state changes)

15


Distributable thread propagates context for end-to-end scheduling on the nodes transited

A distributable thread carries its execution context as it transits (object and) node boundaries, including its scheduling parameters (e.g., time constraints, execution time), identity, and security credentials

The propagated thread context is intended to be used by node schedulers for resolving all node-local resource contention among threads such as that for node's

• physical (e.g., CPU, I/O, memory, disk)

• and logical (e.g., locks)

resources, according to a discipline that provides acceptably

optimal and predictable system-wide timeliness

16


A distributed thread’s multi-node behavior may have end-to-end time constraints

Object A Object B Object C

end-to-end time constraint

time constraint

scope

BEGIN

END

current head of the thread

root of the thread

17


Time constraints are lexically scoped attributes of a schedulable entity (e.g., thread) activity

code

BeginTimeConstraint (t)

EndTimeConstraint

thread

tc scope

thread is “non-real-time”

thread is “non-real-time”

thread is “real-time” system callscheduling event

18


Remote invocation propagates a time constraint to (and enforces it on) remote nodes

code

BeginTimeConstraint (t)

EndTimeConstraint

thread

tc scope thread is “real-time”invokereturn

19


Distributed systems are subject to partial failures

Non-trivial dynamic distributed systems should be presumed to always be partially failed

Provisions must be made to ensure the end-to-end integrity of distributable threads at a level appropriate for the application

Perhaps more importantly for the construction of large, complex distributed real-time systems, the integrity abstraction must be one that programmers and designers can reason about

The DRTSJ reference implementation provides • example implementations of prior art integrity (e.g.,

orphan detection and elimination) policies

• APIs allowing applications to provide their own integrity policies

• example implementations of new research focused on thread integrity in mobile, ad-hoc networks

20


DRTSJ’s threads model is deliberately intended to be similar to that of Real-Time CORBA 1.2

The Real-Time CORBA 1.0 (“fixed priority scheduling”) specification used the activity abstraction as an analysis/design concept for end-to-end predictability of timeliness, but it left the details of the abstraction undefined

The Real-Time CORBA 1.2 (“dynamic scheduling”) specification defines a distributable threads model as the schedulable entity to provide for end-to-end timeliness

Many of the prospective users of either the DRTSJ or Real-Time CORBA 1.2 compliant products express the desire

• to use the other also

• for them to be tightly interoperable at the application programmer level

21


DRTSJ will extend Real-Time CORBA 1.2 constructs with thread integrity and scheduling

Real-Time CORBA 1.2 specification silent on thread integrity

• hadn’t become well enough understood yet

• it was left as an ORB vendor added value or an application-specific solution

The DRTSJ will include APIs allowing applications (or vendors) to provide their own integrity policies

Real-Time CORBA 1.2 specification • IDL for schedulers and scheduling segments

• Does not specify delivery of scheduling events to policies DRTSJ will include a scheduling framework

• Schedule arbitrary javax.realtime.Scheduleables

• Will be submitted to RTSJ EG for consideration

• Extensions to support distributable thread scheduling

• Support advanced application-specific policies

22


Distributable Thread Integrity:Distributable Thread Primer

Thread is instantiated at its root (“root node”)

Thread may transit any node in the network, so that its call-graph is dynamic and difficult to measure

Goal of enforcing the predicate that only a single, unique point of control (in the application’s view) is active at any instant

The “distributable thread” is realized by a collection of local threads, called “segments”

Root

Head

Segment

Dow

nstr

eam

23


Distributable Thread IntegrityThread Polling & TPR

Phase I: Each thread’s root node broadcasts a “poll” message to all nodes

Phase II: Every node hosting a segment of the thread responds (“Ack”) with information about their segment and knowledge about the location of the head. The root assembles a tentative measure of the call graph.

Phase III: If a persistent “break” or missing head is discovered, the thread is paused, cleanup commences on nodes downstream of the break, and control is returned to a new head.

Root

Head

Segment

Dow

nstr

eam

X

24






Root

Head

Segment

Dow

nstr

eam

X

25






Root

Head

Segment

Dow

nstr

eam

Phase I: Poll

X

26






Root

Head

Segment

Dow

nstr

eam

Phase 2: Ack

OrphanX

27






Root

Head

Segment

Dow

nstr

eam

Phase 3: Refresh

New Head

Orphan

OrphanX

28


Distributable Thread IntegrityThread Polling & TPR Root

New HeadException Delivered

OrphanExceptions Delivered

X




29


Distributed thread model works with various JVMs and transport infrastructures

A distributed thread is capable of traversing nodes with standard, RTSJ, and DRTSJ virtual machines, yielding the best available timeliness behavior on each

The distributed thread abstraction appears like the RMI programming model, but has been decoupled from RMI to the extent possible

Implementers are able to implement distributed threads with any transport infrastructures (RMI, SOAP, Real-Time CORBA, etc.) that provides an interface comparable to that of RMI's RPC-style programming model

30


Optional Metascheduler allows arbitrary user-defined scheduling disciplines

Providing control for distributable threads in the presence of partial failures requires cooperation with processor schedulers on every node

Processor scheduling disciplines often need to be application-specific

The DRTSJ implementation team has implemented a set of low-level scheduling primitives called the Metascheduler

• facilitates the construction of arbitrary thread scheduling disciplines

• supports distributable thread integrity policies A variety of scheduling disciplines have been

implemented, ranging from traditional (e.g., fixed priority, EDF), to Time-Utility Function/Utility Accrual ones

The Metascheduler is most effective with JVM support for it, but functions in a degraded mode on any RTSJ-compliant JVM

31


Distributed RTSJ memory areas out of scope for JSR-50

The DRTSJ currently does not intend to address how distributable threads interact with remote memory areas, instead leaving that up to the implementers

Providing control over remote memory – e.g., a distributed way to name a scoped area from off the node – is difficult to make sense of semantically

The DRTSJ is currently silent about how distributable threads interact with memory management – the RTSJ community continues to explore best practices for RTSJ scoped memory,

When sufficient consensus emerges, we anticipate addressing memory areas from a distributed system standpoint

32


Asynchronous events in the DRTSJ

We are investigating the correct approach to DistributedAsyncEvents, but have made no commitment yet about their appearance in the DRTSJ or reference implementation

We are using AsyncEvents locally in the Metascheduler implementation of a scheduling framework for user space scheduling disciplines

We intend to allow the Metascheduler to facilitate user-defined scheduling policies capable of dealing with AsyncEventHandlers

33


DRTSJ development resumed after a pause

Work on the DRTSJ took place for about a year, and then gradually slowed and essentially paused for almost three years; it has recently resumed

Work paused due to…

• no COTS RTSJ products – consequently little pull from prospective DRTSJ users, and hence the work was low priority for the contributors

• problems getting Sun to grant a source license to the RTSJ RI

Work resumed for the following reasons…• several COTS RTSJ products became available

• Sun (and TimeSys) finally granted the source licenses

• but meanwhile Apogee agreed to incorporate the DRTSJ-specific changes into their RTSJ-compliant Aphelion Java runtime environment product

Reference Implementation incrementally developed and used driven by our own research needs

34


The DRTSJ software suite will have four parts

DRTSJ software suite, beginning with Early Draft Release 1, will consist of

• a set of DRTSJ class libraries (implementing a distributable-thread-aware RMI stack)

• an optional COTS binary DRTSJ-compatible JVM product from Apogee, who is implementing it collaboratively with us (the first such product, anticipating a corresponding update to the RTSJ)

• a set of external dependencies, including the Apache build environment and a Debian Linux system with Linux Kernel 2.6, patched with the most recent real-time extensions

• an optional demonstration application

35


DRTSJ applications do not require a DRTSJ-compliant RTSJVM

DRTSJ applications may comprise mixtures of standard JVMs, RTSJ-compliant JVMs, and DRTSJ-compliant JVMs

Distributable threads abstraction will run atop a regular JVM using java.lang.Thread sections, and the programmer may specify if transitions should be made to DistributableThread sections upon arrival in DRTSJ-compliant JVMs

Distributable threads have (dynamic) policy controlling allowable invocations

• Allow invocations on non-DRTSJ remote objects?

• Allow invocations from DRTSJ to RTSJ JVM?

• Allow invocations from DRTSJ to standard JVM? Some facilities unavailable on less compliant VMs, e.g.

• Distributable RealtimeThreads

• Advanced thread scheduling policies

36


The DRTSJ reference implementation and TCKwill be delivered in two forms

First, traditional tarball/jarfiles appropriate for cross-platform evaluation and use by JCP members

Second, because of the complexity and inherent dependencies, a parallel set of packages is being maintained to streamline the “getting started”' process on Debian Linux

A Debian package repository containing the DRTSJ core libraries, with references to all required dependencies will be provided, and constructing a test system will be as easy as “apt-get install drtsj-package”

37


DRTSJ Demonstration Application

Virginia Tech has written a demonstration application to help prospective users better understand the DRTSJ

The demonstration application also is providing essential feedback to the team designing and implementing the DRTSJ and RI

That work was performed in an ONR-funded Advanced Wireless Integrated Navy Network (AWINN) project at VA Tech

Both the AWINN project and the MITRE DRTSJ focus are on dynamic (e.g., mobile, ad hoc wireless) networks with end-to-end time constraints

38


Coastal Air Defense DemonstrationMotivating Scenario

1 Detect

2 Identify

3 Track and Engage4 Shoot

Coastline/boundary to protect

Challenge: How to detect and respond to partial (communications) failure in the midst of a sequential activity execution?

Approach: Implement mission in terms of distributable threads with thread integrity protocols

39


Scenario Communication Network

Coastal Air Defense DemonstrationScenario Deployment Diagram

ScenarioGenerator

andGUI

SensorTrackingService

C2Node

CannonInterceptor

DRTSJ Middleware / Apogee RTJVM

Detections, Commands

RadarPulse, Detection,Lock/Unlock Sensor

Lock/Unlock Interceptor

Distributed Application

Detection Events

Detections, Tracks,

Predictions

Weapon-toTargetPairing

RMI RMI RMI RMI

LaunchInterceptor

40


DRTSJ Present and Future

Early Draft Review #1 Delivery November 2006• Specification: Distributable Threads API

• Reference Implementation: DT API, DT Integrity policies and scheduling framework

Successful Demonstration Application Staffing challenges: Primary contributors are students

and engineers with other priorities Contributor focus on specifying and implementing

aspects of interest to our US DoD and academic sponsors

“Future draft releases and final submission depend on the quality and quantity of … implementation participation from the broader community”

Responses to the expert group regarding this presentation and accompanying paper are solicited!


A Status Report

11 October 2006

4th International Workshop on Java Technologies for Real-time and Embedded Systems (JTRES 2006)

JSR-50: The Distributed Real-Time

Specification for Java

Jonathan S. [email protected]

Lead EngineerThe MITRE Corporation

JSR-50 Implementation Lead

Dr. E. Douglas [email protected]

Consulting ScientistThe MITRE Corporation

JSR-50 Expert Group Lead

Slides available at http://andersoj.org/jtres06


BACKUPS

43


Excerpts from the JSR-50 proposal

The proposed JSR is for a distributed extension to the Real-Time Specification for Java.

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” … means that RMIs and returns 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).

“

”

44


The DRTSJ adds real-time to Java RMI

Java RMI supports moving thread contexts across nodes “RT-RMI” has stricter semantics

where the RMI specification is silent• end-to-end time constraints and integrity

• more types of RemoteExceptions RT-RMI is wire-protocol compatible with Sun’s JDK1.4

RMI implementation,

while providing an extended wire protocol for invocations between DRTSJ-compliant JVMs

Additionally, a UDP-based RT-RMI implementation with application-level reliability mechanisms is provided to demonstrate and test DRTSJ applications in dynamic (e.g., mobile ad-hoc) networks, where TCP is unsuitable

RT-RMI is called the distributable threads model

45


The DRTSJ seeks to bring distributed real-time to Java

Not bring Java to distributed real-time

• a binding of the RTSJ to Real-Time CORBA might be one way to bring Java to distributed real-time, but requires CORBA knowledge in addition to Java programming

Distributed (i.e., multi-node) real-time activities require• satisfying end-to-end time constraints (such as deadlines)

• maintaining end-to-end integrity of the activity (and consistency of the system) despite node and network failures

• and thus providing and using appropriate end-to-end context Other Java distribution models (e.g., JMS, JXTA) do not

provide appropriate end-to-end context,

and thus force any end-to-end timeliness and integrity to be a higher level – usually application programmers’ – responsibility, at greater recurring costs

46


The DRTSJ adds real-time to Java RMI

Java RMI supports moving thread contexts across nodes “RT-RMI” has stricter semantics

where the RMI specification is silent• end-to-end time constraints and integrity

• more types of RemoteExceptions RT-RMI is wire-protocol compatible with Sun’s JDK1.4

RMI implementation,

while providing an extended wire protocol for invocations between DRTSJ-compliant JVMs

Additionally, a UDP-based RT-RMI implementation with application-level reliability mechanisms is provided to demonstrate and test DRTSJ applications in dynamic (e.g., mobile ad-hoc) networks, where TCP is unsuitable

RT-RMI is called the distributable threads model

47


A distributed thread is sequential rather than synchronous (“send/wait”)

The send/wait synchrony of a conventional method invocation (or RPC) is often cited as a concurrency limitation

But a distributed thread is a sequential entity like a local thread

A distributed thread is always executing somewhere, while it is the most eligible there – it is not doing send/wait’s as with conventional method invocations (or RPC’s)

Remote invocations and returns are scheduling events at both source and destination nodes

• each node’s processor is always executing the most eligible distributed thread there

• the other distributed threads there wait as they should Local method invocations/returns benefit from not requiring

context switches like threads normally do

48


Coastal Air Defense Demonstration

Single-node coastal defense example

Prosecuting missile threat is an inherently sequential mission:

1) Detect

2) Identify

3) Track/Engage

4) Shoot

… for which distributable threads are an ideal technical solution

Sensor Range

Weapons Range(beyond line of sight)

Incoming Threats

Coastline/boundary to protect

Fighter/InterceptorLaunched by our Ship

49


Coastal Air Defense Demonstration Scenario Activity Diagram (MANET)

NavyShip2 NavyShip3 NavyShip4 NavyShip5

newDetection()

getSensorLock()

launchInterceptor()

updateSensorLock() (periodically)newDetection()

getSensorLock()

launchInterceptor()

interceptorReturned()

Return from launchInterceptor()

Tim

e

(example target prosecution)

50


Coastline to Defend

Enemy Track(with status and velocity vector)

InterceptPoint

FriendlyShip

FriendlyInterceptor

SensorRange

Accrued Utility

Comm LinkStatus

Integrity Policy and

Comm Settings

ScenarioGen Tactical Display (Example)

© 2006 the mitre corporation. all rights reserved a status report 11 october 2006 4th international...

Documents

realtime corba

mitre corporation jsr

java programmers

drtsj threads

java technologies

java jonathan

drtsj expert group jsr

distributed behavior