Find JSRs
Submit this Search

Ad Banner

Summary  |  Proposal  |  Detail (Summary & Proposal)  |  Nominations
JSRs: Java Specification Requests
JSR 319: Availability Management for Java

Stage Access Start Finish
Withdrawn   19 Oct, 2021  
JSR Withdrawal Ballot View results 12 Oct, 2021 18 Oct, 2021
Final Release Download page 15 Jun, 2010  
Final Approval Ballot View results 16 Mar, 2010 29 Mar, 2010
Proposed Final Draft Download page 28 May, 2009  
Public Review Ballot View results 13 Jan, 2009 20 Jan, 2009
Public Review Download page 15 Dec, 2008 20 Jan, 2009
Early Draft Review Download page 25 Jun, 2008 25 Jul, 2008
Expert Group Formation   30 Oct, 2007  
JSR Review Ballot View results 16 Oct, 2007 29 Oct, 2007
Status: Withdrawn
Reason: null
JCP version in use: 2.11
Java Specification Participation Agreement version in use: 2.0

This JSR will provide an API by which an availability management framework can supervise and control Java runtime units in order to achieve high availability.


Specification Leads
  Jens Jensen Ericsson AB
Expert Group
  Vivek Chopra de Castro Filho, Paulo Roberto
: Paulo Roberto de Castro Filho
Ericsson AB
: Jens Jensen
  Ericsson AB
: Peter Kristiansson
: Marc Brandt
: Marc Lamberton
: Sanjeeva Manvi
: Benny Mandler
Kleemann, Jens
: Jens Kleemann
  Nokia Siemens Networks GmbH & Co. KG
: Tapio Tallgren
Red Hat
: Ivelin Ivanov
Red Hat
: Vladimir Ralev
  Reedy, Dennis
: Dennis Reedy
Sun Microsystems, Inc.
: Larry White

This JSR has been Withdrawn
Reason: null

This JSR was completed on 15 June 2010 under JCP version 2.7.

Original Java Specification Request (JSR)

Identification | Request | Contributions | Additional Information

Section 1. Identification

Submitting Member: Ericsson AB

Name of Contact Person: Jens Jensen

E-Mail Address:

Telephone Number: +46 8 727 3489

Fax Number: +46 8 647 8276

Specification Lead: Jens Jensen

E-Mail Address:

Telephone Number: +46 8 727 3489

Fax Number: +46 8 647 8276

Initial Expert Group Membership:

Sreeram Duvur - Sun Microsystems, Inc
Jarek Wilkiewicz - BEA
Ivelin Ivanov - JBoss (Red Hat Middleware)
Tapio Tallgren - Nokia Siemens Networks
Peter Kristiansson - Ericsson

Supporting this JSR:

Sun Microsystems, Inc
JBoss (Red Hat Middleware)
Nokia Siemens Networks

Section 2: Request

2.1 Please describe the proposed Specification:

An availability management framework shall coordinate redundant resources within a cluster to deliver a system with no single point of failure by:

  • - deciding the distribution of software resources across the cluster
  • - controlling the instantiation/activation and the deactivation/termination of software resources
  • - monitoring the health of the resources
  • - handling error detection, recovery and escalation
  • - supporting administrative operations on framework entities

The purpose of the Availability Management for Java is to enable availability frameworks to supervise and to control Java runtime units in a standardized way. The API has the following goals:
  • - It shall not specify the availability management framework itself but it shall only specify the means by which the framework can supervise and control the Java units within a JVM. The means by which the framework instantiates JVMs and communicates with the JVMs are outside the scope of the specification. The specification will define the local interactions within one JVM only.
  • - It shall allow different service providers to provide support for specific availability frameworks, standardized or proprietary. It is required that a service provider for the standardized AMF (Availability Management Framework) of SA Forum shall be feasible.
  • - It shall be designed with Java EE as the main target, although parts of the specification will also be useful on Java SE. The specification has to consider the constraints set by the component models of Java EE.
  • - It shall specify a basic set of features that can be considered as useful for Java EE and possible to support by most availability management frameworks. This implies that only a subset of the features of AMF will be supported.
  • - It shall support Java EE applications that are not at all, to some extent or completely aware of the control of the availability management framework. It is anticipated that the main part of the specification is implemented in the Java EE server and that existing Java EE applications can take advantage of the availability support without any changes.
  • - It shall not handle all aspects of clustered Java systems. Especially it shall not specify any state replication solution, although it may specify that the API can give hints to such replication solutions in the form of reasons for the activation or the deactivation of a unit.

The specification is anticipated to contain the following features:
  • - The Java runtime system is considered to consist of different availability units that can be supervised and controlled by the service provider. The provider can create, activate, deactivate and destroy an availability unit. An availbility unit may be mapped to a Java EE application.
    • - A root availability unit maps on all services that are not modelled as regular availability units. It represents the server instance. A failure of the root availability unit is considered to cause a failure of all the other availability units also.
    • - An availability unit may support health checks and it can report failures to the service provider.
    • - An availability unit may subscribe for state changes of peer units in other JVMs.
    • - An availability aware Java EE application shall get a callback reference via JNDI or injection and it shall get application lifecycle method invocations or notifications containing a reason argument.

    2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

    Java SE and Java EE.

    2.3 The Executive Committees would like to ensure JSR submitters think about how their proposed technology relates to all of the Java platform editions. Please provide details here for which platform editions are being targeted by this JSR, and how this JSR has considered the relationship with the other platform editions.

    The specification is targeted for the Java EE 5 platform. It is a candidate to be included into future Java EE definitions. The specification can be included in one of the profiles for JavaEE when they have been defined in JavaEE 6. The main part of the specification will also be useful on the Java SE platform.

    2.4 Should this JSR be voted on by both Executive Committees?

    No. SE/EE EC Only.

    2.5 What need of the Java community will be addressed by the proposed specification?

    The need to achieve high availability of Java applications with the help of an external availability framework. As AMF of SA Forum now is a standardized availability framework, it is most useful if it can control all applications in a system, native applications as well as Java applications.
    In the same way existing vendor specific solutions for high availability can be used as the external availability framework providing the standardized availability management for Java.

    2.6 Why isn't this need met by existing specifications?

    No other specification is addressing this requirement.

    2.7 Please give a short description of the underlying technology or technologies:

    The goal of this JSR is to enable Java to take advantage of other open standards for high availability, like SAF. SAF is defining a set of specifications for a high availability framework and there exist a couple of open source implementations today.
    Availability in general refers to the probability that a system is in an operating condition that allows it to provide the service(s) for which it is intended to perform. Availability is a measure that conventionally is expressed as a percentage which is calculated as the uptime divided by the uptime plus the downtime of the system.
    An availability management framework manages redundant resources within a cluster to deliver a system with no single point of failure. To get a complete system with high availability other thins like secure messaging, operation and maintenance and state replication is needed.

    2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

    2.9 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?


    2.10 Are there any security issues that cannot be addressed by the current security model?


    2.11 Are there any internationalization or localization issues?


    2.12 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?


    2.13 Please describe the anticipated schedule for the development of this specification.

    Initiation: October 2007
    Early Draft Review: February 2008
    Public Review: May 2008
    Final Release: December 2008

    2.14 Please describe the anticipated working model for the Expert Group working on developing this specification.

    The primary means of communication will be email, with conference calls and face-to-face meetings scheduled as needed.

    2.15 It is important to the success of the community and each JSR that the work of the Expert Group be handled in a manner which provides the community and the public with insight into the work the Expert Group is doing, and the decisions that the Expert Group has made. The Executive Committees would like to ensure Spec Leads understand the value of this transparency and ask that each JSR have an operating plan in place for how their JSR will address the involvement of the community and the public. Please provide your plan here, and refer to the Spec Lead Guide for a more detailed description and a set of example questions you may wish to answer in your plan.

    The specification lead will maintain an interest alias for JCP members outside of the Expert Group. The specification lead will publish periodic milestone drafts and status to this list. The Expert Group may also use the list to request feedback on key issues facing the group.
    The expert group will also have an open communication with Service Availability Forum (SAF) and SCOPE Alliance.

    2.16 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.

    The RI and the TCK will be developed in open source and can be delivered as stand-alone or as a part of Java EE 5.

    2.17 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).


    2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.

    The specification will be licensed under a standard Community Source License. The TCK will be licensed under a standard Community Source License. The TCK binaries will be licensed at no charge, with no support. The RI will be licensed under a standard Community Source License. The RI binaries will be licensed at no charge, with no support.

    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.

    SAF specifications: < a href="">

    3.2 Explanation of how these items might be used as a starting point for the work.

    The specifications from SAF describe one of the frameworks that should be possible to integrate with using the new API. It is mainly the AMF specification that is of interest for this JSR. The AMF specification describes how service availability should be provided by coordinating redundant resources within a cluster to deliver a system with no single point of failure.

    Section 4: Additional Information (Optional)

    4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.