• JSRs by Platform
• JSRs by Technology
• JSRs by Stage
• JSRs by Committee
• List of All JSRs



Register for Site

Use of JCP site is subject to the JCP Terms of Use and the Oracle Privacy Policy


• About JCP
  • Program Overview
  • JCP Process Document
  • Calendar
  • JCP Members
  • Executive Committee
  • Elections
• Get Involved
  • Overview
  • Becoming a JCP Member
  • Java in Education
• Community Resources
  • Overview
  • Tutorials
  • JCP Podcasts
  • Spec Lead Guide
  • TCK Tool & Info
  • License Reference
• Community News
  • News
  • Programs & Awards
  • Press Releases
  • Success Stories
• FAQ
• Contact Us

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	Hewlett-Packard : Marc Brandt	Hewlett-Packard : Marc Lamberton
	Hewlett-Packard : Sanjeeva Manvi	IBM : 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
Contributors

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: jens.jensen@ericsson.com

Telephone Number: +46 8 727 3489

Fax Number: +46 8 647 8276

Specification Lead: Jens Jensen

E-Mail Address: jens.jensen@ericsson.com

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)
Hewlett-Packard
BEA
Nokia Siemens Networks
Motorola
Intel

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

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

  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.

  SAF specifications: < a href="http://www.saforum.org/specification/"> http://www.saforum.org/specification/

  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.

  N/A