• 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

This JSR has been Withdrawn
Reason: Withdrawn with the agreement of the Expert Group.

Updates to the Original Java Specification Request (JSR)

The following section has been updated to the original JSR:

Section 4: Additional Information

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

It should be noted that although the APIs defined by this JSR are important for achieving applications' availability, the APIs do not themselves provide continuous availability.

The Reference Implementation of this JSR will be a J2EE system that implements the APIs defined by the JSR. However, the RI system will not achieve continuous availability.

The compliance test suite for this JSR will test that the system under test implements the APIs defined by the JSR, but it will not test that the system actually achieves continuous availability. The CTS will not be a certification of system availability.

Identification | Request | Contributions | Additional Information

Section 1. Identification

Submitting Member: Sun Microsystems

Name of Contact Person: Vlada Matena

E-Mail Address: vlada.matena@eng.sun.com

Telephone Number: +1 408 343 1649

Fax Number: +1 408 863 3195

Specification Lead: Max Mortazavi

E-Mail Address: masood.mortazavi@eng.sun.com

Telephone Number: +1 408 343 1634

Fax Number: +1 408 863 3195

Initial Expert Group Membership:

Sun Microsystems

Ericsson

Siemens

Section 2: Request

2.1 Please describe the proposed Specification:

There is considerable interest in using the J2EE platform for applications requiring continuous availability, such as for applications used in the telecommunication industry. These applications typically require 99.999% or higher availability. The vendors of these applications would like to migrate to a standard Java platform. We also believe that the vendors of other J2EE applications, such as enterprise applications, might benefit from the functionality defined by this specification. In particular, applications deployed as network services might benefit from the specification.

While the J2EE platform and its programming model have been designed to support the development and deployment of continuous-availability applications, the J2EE platform does not currently provide API support for certain functions required by these applications. Therefore, the vendors of J2EE platforms either do not support these functions in their products, or support them with vendor-proprietary APIs. The goal of this JSR is to standardize the APIs for some of the functions that are essential to continuous-availability applications.

The submitters do not presume that this specification will become a required part of the J2EE platform. The inclusion of the output of this JSR, in whole or in part, into the J2EE platform should be decided within the J2EE JSR process.

The J2EE platform has been designed with the philosophy that the applications do not need to interface with low-level system services. Instead, the J2EE containers inject various system services on behalf of the application components. This injection of the system services is as transparent to the application components as possible. The support for continuous availability is one of such system services provided by the J2EE platform. While the J2EE platform can provide most of the availability management services transparently to the applications (and therefore no APIs between the application components and the platform are necessary), some availability functions require collaboration between the platform and the applications. This specification identifies such collaborations and defines APIs between the platform and the application.

The specification does not attempt to define high-availability APIs used between the J2EE platform implementation and an underlying clustering framework at the operating system level.

Specifically, we propose this JSR to focus on the following areas:

• The JSR will describe the availability-related functionality that the J2EE platform containers should perform transparently to application components. Fail-over is an example of such a function. There are no APIs for these functions.

• Support for Field-Replaceable Units (FRU). The J2EE platform uses the Enterprise Application Archive (EAR) file as the format for software distribution. This specification defines the application-packaging conventions that are necessary for using EAR files as self-describing Field-Replaceable Units. The support for FRUs might require an XML deployment descriptor as a supplement to the standard J2EE descriptors.

• Support for online upgrades. The capability to upgrade an application to a new version of its software without disruption in the service offered by the application to its users is a required feature of a platform for continuous availability applications. As a new version of the application may use different format of its persistent state, collaboration between the platform and the application during the online upgrade process is required to upgrade the state to a new format. The specification will define the collaboration between the J2EE platform and the application during the online upgrade process and the APIs that support the collaboration.

• Support for application-specific error handling policies. The J2EE containers are responsible for supervising the execution of method invocations on the application components and for the error recovery of system exceptions thrown from the method invocations. Some applications for continuous availability need to collaborate with the platform in error handling. The specification will define the API support for such error-handling collaboration.

• Conventions for using the Logging API Specification (JSR-047) in the J2EE containers and in the application code to facilitate application tracing. The ability to trace a running application in order to diagnose the cause of application's abnormal behavior is perceived as a required functionality for a platform for continuous availability. While J2EE containers can perform low-level tracing transparently to the application components, high-level tracing typically requires that the application components emit tracing messages. This JSR will standardize the levels used for J2EE application tracing, and will describe the expected level of tracing information emitted by the containers and applications at each tracing level. This standardization is necessary to ensure uniform handling of trace information across multiple applications and multiple platform implementations.

• Application programming model guidelines for applications requiring continuous availability.

It should be noted that in order to support the availability-management related collaborations between the platform and the application, the specification does not intend to change the existing J2EE APIs or the J2EE programming model, which are both unaware of availability management. The specification intends to add the availability APIs in a way that is non-intrusive to the existing J2EE application programming model.