Status: FinalJCP version in use: 2.7Java Specification Participation Agreement version in use: 2.0

Description:
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.

Please direct comments on this JSR to the Spec Lead(s)

Team

Specification Leads

Jens Jensen

Ericsson AB

Expert Group

Chopra, Vivek

de Castro Filho, Paulo Roberto

Ericsson AB

Hewlett-Packard

IBM

Kleemann, Jens

Nokia Siemens Networks GmbH & Co. KG

Red Hat

Reedy, Dennis

Sun Microsystems, Inc.

If you would like to be added to the observer alias for this JSR and receive e-mail updates on the progress of the JSR, please send e-mail to the Spec Lead with "Add to observer alias" in the subject line.

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.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.)

javax.availability.management

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

No

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

No

2.11 Are there any internationalization or localization issues?

No

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

No

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).

N/A

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.

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.