JSRs: Java Specification Requests
JSR 117: J2EETM APIs for Continuous Availability
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)
This JSR has been Withdrawn
The following section has been updated to the original JSR:
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)
Section 1. Identification
Submitting Member: Sun Microsystems
Name of Contact Person: Vlada Matena
E-Mail Address: firstname.lastname@example.org
Telephone Number: +1 408 343 1649
Fax Number: +1 408 863 3195
Specification Lead: Max Mortazavi
E-Mail Address: email@example.com
Telephone Number: +1 408 343 1634
Fax Number: +1 408 863 3195
Initial Expert Group Membership:
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:
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.
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.