Find JSRs
Submit this Search

Ad Banner

Summary  |  Proposal  |  Detail (Summary & Proposal)
JSRs: Java Specification Requests
JSR 117: J2EETM APIs for Continuous Availability

Stage Access Start Finish
Withdrawn   25 Aug, 2003  
Expert Group Formation   17 Apr, 2001  
JSR Review Ballot View results 03 Apr, 2001 16 Apr, 2001
Status: Withdrawn
Reason: Withdrawn with the agreement of the Expert Group.
JCP version in use: 2.1
Java Specification Participation Agreement version in use: 1.0

This specification defines the programming model and runtime support for implementing J2EE applications requiring continuous availability.

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

Specification Leads
  Max Mortazavi Sun Microsystems, Inc.
Expert Group
  Arjuna Technologies Ltd. BEA Systems Borland Software Corporation
  Compaq Computer Corporation Ericsson Infotech AB Eternal Systems, Inc.
  IBM iPlanet Nokia Corporation
  Novell, Inc. Open Cloud Limited Oracle
  SAP SE Siemens AG Sun Microsystems, Inc.

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.

Original Java Specification Request (JSR)

Identification | Request | Contributions | Additional Information

Section 1. Identification

Submitting Member: Sun Microsystems

Name of Contact Person: Vlada Matena

E-Mail Address:

Telephone Number: +1 408 343 1649

Fax Number: +1 408 863 3195

Specification Lead: Max Mortazavi

E-Mail Address:

Telephone Number: +1 408 343 1634

Fax Number: +1 408 863 3195

Initial Expert Group Membership:

Sun Microsystems



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.

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


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

The specification will address the need of J2EE applications requiring continuous availability. Examples of such applications are telecommunication applications and services.

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

This specification will define the functionality that is required by continuous-availability applications, but it is not defined in any existing JSRs.

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

This is described in Section 2.1.

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

To Be Determined.

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


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

No. We believe that the current J2SE and J2EE security models are sufficient to address the needs of this specification.

2.9 Are there any internationalization or localization issues?


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

The goal of this JSR is not to deprecate or modify any existing Java specifications. In particular, this JSR does not expect to modify any existing J2EE specification. If the expert group finds some issues that would be best addressed by changes to the J2EE JSR, or its constituent JSRs, it will recommend to the appropriate expert group to make the changes.

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

The final schedule will need to be determined by the expert group. It will be dependent on the exact set of goals agreed upon by the expert group.

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

It is anticipated there will be a face-to-face kick-off meeting. Subsequent work will be done by email.

The goal will be to attempt to develop a consensus in the expert group over the main goals of the specification.

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.

1. Existing J2EE specifications.

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

The development of the specification will be constrained by the existing J2EE specifications.