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.

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.

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

No.

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?

No.

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.