2.1 Please describe the proposed Specification:

In the past two years a number of JSRs that apply to the
wireless communications industry have been initiated. A primary focus has
been on the use of J2ME technologies in the wireless handset: MIDP (JSR-37),
MIDP 2.0 (JSR-118), Wireless Messaging API (JSR-120). In addition, a number
of complementary efforts are currently underway: Mobile Media API (JSR-135).

J2ME technologies have been very successful in the wireless
industry. The MID Profile is incorporated into a wide variety of products.
Not only are handset vendors supporting it, but implementations for PDAs
are available, and implementations for other devices are certain to follow.
What is not clear, and is not within the scope of any existing JSR, is
how the various technologies associated with the MID Profile work together
to form a complete handset solution for the wireless services industry.

What is needed is a clear exposition of an overall architecture,
which would include:

Which optional packages
fit with which profiles

How an end-to-end
solution for interoperable Java applications could work

How the migration of applications can occur and
to which profiles as the devices become more capable.

In addition, it would be beneficial if coordination of new
JSRs and recommendations for new optional packages could take place within
the context of the wireless development community as a whole.

This JSR expert group (EG) will provide an overall architectural
description of a wireless client software stack. An integrated reference
implementation (RI) and technology compatibility kit (TCK) bundle will
be provided for the described technologies. In addition, this EG will provide
advice to the JCP ME Executive Committee and other relevant bodies on the
industry and associated technology.

Scope of this JSR

The output of this JSR is a collection of documents which
may be revised through the maintenance process from time to time, and a
coordinated, complete RI and TCK for the selected pieces of the client
architecture. The EG will produce the following document:

1. The Java Wireless Architecture Specification
(JWAS). The JWAS is an architectural overview describing the essential
client components of an end-to-end wireless environment. It will describe
recommended combinations of technologies using J2ME. It is a guide for
the correct use of the various Java technologies that might be used in
a wireless environment. As a normative specification, the JWAS will trigger
compatibility requirements to be reflected in the TCK which, once met,
can be used to claim conformance, and which service and content providers
can use as a target for development. In addition to the normative specification
for the wireless architecture, this document will include a non-normative
recommended practices section.

In addition, the Expert Group may, in its discretion
and contingent upon the availability of adequate resources provided by
the EG members, develop and deliver the following documents:

2. The Java Wireless Architecture Roadmap
(JWAR). The JWAR is a document that would describe the current roadmap
for the technology. It refers to a particular version of the JWAS as the
current specification and defines a technological direction and plan to
get to the next revision. It does this by outlining technologies of interest,
then referencing JSRs that are in progress and that address the interesting
technologies. This is not a normative document, unlike the JWAS.

3. The Java Wireless Architecture Users Guide
(JWAUG). The JWAUG is a document that provides a descriptive overview
of the architecture specification. It is revised with the JWAS and there
should always be a version of the JWAUG corresponding to the JWAS. In addition
to providing a general overview there are specific chapters of this document
that address the JWAS from the standpoint of a particular market participant
-- for example what the JWAS means to handset manufacturers, or what the
JWAS means to content authors etc.

Because there is a need for a coordinated, integrated implementation
of the complete client stack, this expert group will produce a RI &
TCK bundle of the combined client technologies referenced. This will be
based on the referenced RIs and TCKs of the components, but packaged together
and coordinated to work together in the environment specified by the JWAS.
The EG does not have any authority to compel the incorporation or licensing
of these referenced materials, or to compel changes to such other referenced
materials.

In addition to the documents, RI, and TCK, from time to
time this expert group may find it useful to advise the J2ME Executive
Committee, JSR-68, the J2ME architecture specification expert group, and
other expert groups which may be doing work in the wireless arena. It seems
clear that this expert group will have to work very closely with the JSR
118 (MIDP 2.0) EG.

Finally this JSR EG is intended to act as a filter and
funnel for comments from the wireless industry to the variety of participants
in the JCP.

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

There are a number of JSRs that are currently active and
a few that are in maintenance mode that are used by the wireless community.
There is a very strong need to have a single expert group provide architectural
consistency, focus, and direction to the collection of efforts. In addition
there is a strong need in the marketplace for a clear statement of how
the various technologies fit and work together. Finally, there is a strong
need to provide a general roadmap for the near future that defines what
work is being done and how it fits in with existing work.

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

The existing JSRs and specifications all target specific
APIs and technologies. In addition, the two relevant profile JSRs (37 &
118) define application environments which do not include all end-to-end
considerations. These may be used in other devices such as PDAs and so
cannot specify so much that the profiles become unusable outside of a wireless
infrastructure, e.g. by mandating a particular provisioning mechanism that
can't be supported on a PDA.

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

As stated in section 2.1 the basic underlying technologies
include the J2ME profiles currently based on CLDC, and the optional packages
explicitly defined for MIDP.

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

This JSR should not define new APIs; however it may want
to suggest naming conventions for the use of future JSRs.

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.

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?

No.

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

This is intended to be a one year effort, but should attempt
to be coincident with JSR-118.

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

Continuous email communications, with occasional telephone
conferences and quarterly face to face meetings (as needed), which will
be teleconferenced.

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.