Find JSRs
Submit this Search


Ad Banner
 
 
 
 

JSRs: Java Specification Requests
JSR 249: Mobile Service Architecture 2

This JSR has been Dormant
Reason: The Specification Leads chose to list this JSR as dormant in August 2012.

Updates to the Java Specification Request (JSR)

The following information has been updated from the original JSR:

2012.08.21:
The Maintenance Lead from Nokia Corporation has changed to Erkki Rysä. The Vodafone Maintenance Lead is unchanged.

Maintenance Lead: Erkki Rysä (Nokia Corporation)

E-Mail Address: jsr249@nokia.com

Telephone Number: -

Fax Number: -

2012.08.10:
The Maintenance Lead from Vodafone has changed to Guenter Klas. The Nokia Corporation Maintenance Lead is unchanged.

Maintenance Lead: Guenter Klas (Vodafone Group Services Limited)

E-Mail Address: guenter.klas@vodafone.com

Telephone Number: -

Fax Number: -

2012.07.12:
The Maintenance Lead from Nokia Corporation has changed to Wang Cheng. The Vodafone Maintenance Lead is unchanged.

Maintenance Lead: Wang Cheng (Nokia Corporation)

E-Mail Address: cheng.9.wang@nokia.com

Telephone Number: -

Fax Number: -

2010.01.12:
The Maintenance Lead from Vodafone has changed to Edin Bektesevic. The Nokia Maintenance Lead is unchanged.

Maintenance Lead: Edin Bektesevic (Vodafone Group Services Limited)

E-Mail Address: edin.bektesevic@vodafone.com

Telephone Number: +44 791 999 4675

Fax Number: -

2009.07.03:

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


The targeted schedule for the JSR is as follows:
- Expert Group formation: September 2004
- Early Draft Review: Q2/2008
- Public Review: Q4/2008
- Proposed Final Draft: Q2/2009
- Final Approval Ballot: Q4/2009

2007.09.21: JSR refocused from CDC only to cover both the evolution of the CLDC and CDC based platforms. Emphasis put on both mass market devices and evolution of JSR 248 as well as CDC and advanced devices. While CLDC functionality is a mandatory part of the JSR, CDC functionality is provided optionally.

2.1 Please describe the proposed Specification:

In the past, the Java ME community developed a unified Java application environment standard for mobile phones (JSR-185). The design center for JSR-185 was devices with resources and capabilities to address the current market needs for volume devices. Mobile Service Architecture (JSR 248) then broadened the set of requirements and defined a platform to address new device capabilities.

Since JSR 248 was finalized, Java ME community has developed a number of new JSRs and released new versions of some of the ones included in JSR 248. There is a need to bring Mobile Service Architecture up to date with new component JSRs and define specification clarifications and additional requirements for implementing the JSRs in mobile devices. There is also a need to define additional specification clarifications to the already existing JSRs in JSR 248 to improve the quality and predictability of devices based on the Mobile Service Architecture platform.

Consequently this expert group (EG) will produce the next revision of the Mobile Service Architecture specification: Mobile Service Architecture 2. The specification is an updated architectural description of the essential client components of an end-to-end wireless environment. It will describe the mandatory and optional combinations of technologies using Java ME by referring to selected Java specifications. It is a guide for the correct use and combination of the various Java technologies that can be used in a wireless environment. As a normative specification, the Mobile Service Architecture 2 will trigger compatibility requirements to be reflected in the TCK. Service and content providers can use the Mobile Service Architecture specification as a target for development and require conformance creating a predictable environment for developers. This specification will provide backward compatibility with the existing Mobile Service Architecture specification JSR 248.

In addition to this specification, this expert group may advise the Java ME Executive Committee, JSR-68, the Java ME architecture specification expert group, and other expert groups, which may be doing work in the mobile/wireless arena.

2.3 The Executive Committees would like to ensure JSR submitters think about how their proposed technology relates to all of the Java platform editions. Please provide details here for which platform editions are being targeted by this JSR, and how this JSR has considered the relationship with the other platform editions.

The target platform is MIDP implemented on top of CLDC or alternatively on CDC.

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

This JSR will specify the 2nd revision of Mobile Service Architecture, improving interoperability across devices and potentially expanding the set of component JSRs included in the specification.

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

N/A

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

CLDC functionality is assumed, but CDC is also allowed to be used by the device implementation. MIDP 2.0 (or depending on the schedule MIDP 3) is a key element in the specification. In contrast to JSR 248 this specification may optionally include and clarify component JSRs which require a CDC based platform.

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

This JSR is not planned to define new APIs.

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

No.

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

The targeted schedule for the JSR is as follows:
- Expert Group formation: September 2004
- Early Draft Review: Q1/2008
- Public Review: Q2/2008
- Proposed Final Draft: Q3/2008
- Final Approval Ballot: Q4/2008

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

The Expert Group will use email communications, regular telephone conferences and face-to-face meetings at two to three month intervals.

The goal of the Specification Lead for this JSR is to achieve expert group consensus on all decisions regarding the specification and related documents.

In addition to the Expert Group, a group of Observers may be created for interested parties, who can follow the work of the Expert Group but cannot participate in the discussions, work or decision making itself.

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.

Mobile Service Architecture (JSR 248)

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

This specification will be based on the above specification and describe, in a normative fashion, the interaction between the various pieces of technology for the wireless services industry.

2007.05.05: The Specification Lead of the JSR from Nokia changed on 2007.05.05:

Specification Lead: Erkki Rysa (Nokia Corporation) / Kay Glahn (Vodafone Group Services Limited)

E-Mail Address: JSR249@nokia.com / JSR249@vodafone.com

Telephone Number: +358 71 800 8000 / +49 (89) 95 410 0

Fax Number: +358 71 807 4160 / +49 (89) 95 410 111


Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1. Identification

Submitting Member: Nokia Corporation/Vodafone Group Services Limited

Name of Contact Person: Asko Komsi/Mark Duesener

E-Mail Address: JSR249@nokia.com / JSR249@vodafone.com

Telephone Number: +1 650 625 2000/+49 89 954100

Fax Number: +1 650 625 2502/+49 89 95410111


Specification Lead: Asko Komsi/Mark Duesener

E-Mail Address: JSR249@nokia.com / JSR249@vodafone.com

Telephone Number: +1 650 625 2000/+49 89 954100

Fax Number: +1 650 625 2502/+49 89 95410111

Note that this information has been updated from the original JSR.

Initial Expert Group Membership:

* Borland
* Motorola
* Nokia
* Orange France SA
* Siemens
* Sony-Ericsson
* Sun
* Vodafone

Supporting this JSR:

* Ericsson Mobile Platforms
* Insignia
* Orange France SA
* Siemens
* Sony-Ericsson
* Sun
* Symbian
* Texas Instruments
* T-Mobile



Section 2: Request

2.1 Please describe the proposed Specification:

NOTE that this information has been updated from this original proposal.

In the past, the J2ME community has developed a unified Java application environment standard for mobile phones (JSR-185). The design center for JSR-185 was devices with resources and capabilities to address the current market needs for volume devices. This choice led the group to focus on the CLDC configuration with MIDP as the central Profile.

The present JSR broadens the set of requirements to address devices with significantly enhanced capabilities and therefore is targeted at the CDC platform and the Foundation Profile. These devices are referred to as advanced mobile handsets in the industry and represent the most capable devices that are available today, moving to mass-market devices in the near future. Thus advanced mobile handsets are expected to make up a significant portion of the wireless handset market over the next several years.

Both platforms are needed and address distinct segments. We recognize that there are devices that might be suitable for both application environments, but this is inherent in the diversity of devices. Part of the role of the Mobile Service Architecture community will be to address different market views to help successfully set industry direction.

Among the key features required for these advanced devices are:

- High performance, high resolution User Interface
- Advanced Operational Management Environment
- Support for installable third party middleware services
- Advanced Networking including peer 2 peer, web service,
- Backward Compatibility with JTWI 1.0

This JSR expert group (EG) will produce the following documents:

- The Mobile Service Architecture Specification: The Mobile Service Architecture Specification is an architectural overview describing the essential client components of an advanced end-to-end wireless environment. It will describe recommended combinations of technologies using J2ME (referring to selected Java specifications). It is a guide for the correct use and combination of the various Java technologies that can be used in a wireless environment. As a normative specification, the Mobile Service Architecture Specification will trigger compatibility requirements to be reflected in the TCK. Service and content providers can use the Mobile Service Architecture Specification as a target for development and require conformance creating a predicable but extensible environment for developers
- The Mobile Service Architecture Roadmap: The Mobile Service Architecture Roadmap is a document that describes a roadmap for the technology. It is the basis for the new versions of the Mobile Service Architecture Specification and defines a technological direction and plans to get to this new revision. This makes this JSR a living JSR that plans for multiple revisions. This document describes relevant technologies, then references JSRs and other possible Java specifications developed and in progress. This is not a normative document, unlike the Mobile Service Architecture Specification.

In addition to these specifications, this expert group may advise the J2ME Executive Committee, JSR-68, the J2ME architecture specification expert group, and other expert groups, which may be doing work in the mobile/wireless arena. This expert group will also guide the work of the Mobile Service Architecture JSR.

NOTE that this information has been updated from this original proposal.

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

Mobile Handsets.

2.3 The Executive Committees would like to ensure JSR submitters think about how their proposed technology relates to all of the Java platform editions. Please provide details here for which platform editions are being targeted by this JSR, and how this JSR has considered the relationship with the other platform editions.

NOTE that this information has been updated from this original proposal.

The Foundation Profile on CDC.

2.4 Should this JSR be voted on by both Executive Committees?

No

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

NOTE that this information has been updated from this original proposal.

There is a need to have a single expert group select technologies, which are relevant for the specification defining the advanced mobile handset platform for the wireless industry. In addition, this specification will provide continual architectural consistency, focus, and direction to this collection of efforts for J2ME. Also there is a need in the marketplace for a clear statement of how the various technologies fit and work together.

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

NOTE that this information has been updated from this original proposal.

The existing J2ME JSRs and specifications target specific APIs and technologies almost only for CLDC. In addition, the relevant configuration and profile JSRs, CDC and Foundation Profile define an application environment that is not specifically scoped at mobile handsets. JSR-185, is targeted at the volume handset, not the much more capable advanced mobile handset.

The net result is that many of the JSRs are more general than appropriate for mobile phones. This JSR provides guidelines to integrate J2ME JSRs in a uniform and predictable arrangement that is customized specifically for the advanced mobile handset. It will issue clarifications on certain components if necessary and will aim at reducing the number of available options.

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

NOTE that this information has been updated from this original proposal.

As stated in section 2.1, the basic underlying technologies include the J2ME profiles currently based on CDC 1.1 and a collection of J2ME optional packages, which provide APIs for functionality expected in the advanced handset. In addition new JSR may need to be filed to fill the architectural gaps left by the current uncoordinated JSRs.

One essential part of this foundation will be Operational Management, JSR-232, which will provide for a management environment suitable for mobile devices capable of installing, and managing Java components in a dynamic fashion including the associated native components in the CDC environment.

Mobile Service Architecture will provide a suitable rich and advanced UI architecture to support the needs of these advanced devices. This environment will offer an unparalleled set of capabilities for Java developers and an exceptional environment for tool providers.

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

NOTE that this information has been updated from this original proposal.

This JSR does not define new APIs.

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

No

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

NOTE that this information has been updated from this original proposal.

The CDC Java security system provides a useful base for a comprehensive security model. On top of this framework both management and runtime security enhancements will be overlaid as needed to meet the needs of the developers and system managers.

2.11 Are there any internationalization or localization issues?

No

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

No

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

NOTE that this information has been updated from this original proposal.

The targeted schedule for the JSR is as follows:
- Expert Group formation: September 2004
- Early Draft Review: December 2004
- Public Review: January 2005
- Proposed Final Draft: May 2005
- Final Approval Ballot: September 2005

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

NOTE that this information has been updated from this original proposal.

The Expert Group will use email communications, regular telephone conferences and face-to-face meetings at two to three month intervals.

Since this Expert Group will also be working on Mobile Service Architecture JSR, the purpose is to try to synchronize the work on both specifications and the corresponding meetings.

The goal of the Specification Lead for this JSR is to achieve expert group consensus on all decisions regarding the specification and related documents.

In addition to the Expert Group, a group of Observers may be created for interested parties, who can follow the work of the Expert Group but cannot participate in the discussions, work or decision making itself.

2.15 It is important to the success of the community and each JSR that the work of the Expert Group be handled in a manner which provides the community and the public with insight into the work the Expert Group is doing, and the decisions that the Expert Group has made. The Executive Committees would like to ensure Spec Leads understand the value of this transparency and ask that each JSR have an operating plan in place for how their JSR will address the involvement of the community and the public. Please provide your plan here, and refer to the Spec Lead Guide for a more detailed description and a set of example questions you may wish to answer in your plan.

Transparency plan: a) The specification lead will maintain an Observer interest list for JCP members outside of the Expert Group (EG). Observers may follow the progress of the JSR by the periodic short briefs about the progress in solving the remaining open issues and specification drafts created by this JSR as will be decided by the Expert Group. However, Observers will not be entitled to participate in the Expert Group meetings (face-to-face or telephone conferences). The Expert Group may also use the list to request feedback on key issues facing the group.
b) The specification lead will, on a quarterly basis, provide a brief JSR status to the JCP PMO, for publication to the Java community. This will include the current schedule for the JSR and notes on any major events that have occurred in the previous quarter.

2.16 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.

The TCK will be delivered separately from the RI, if any.

Due to the special nature of this JSR, the TCK from this JSR will contain the documentation and software, covering Mobile Service Architecture compliancy requirements, and a list referring to TCKs of those Java Specifications that are part of Mobile Service Architecture Specification, additional testcases created in this JSR and instructions and guidance of how to run the tests.

The individual Component JSR TCKs are not included in the Mobile Service Architecture TCK delivery package. However, this JSR may explore the possibility to deliver the TCK, which would include the tests included in the TCKs for the referred individual Java Specifications.

Due to the special nature of this JSR, the RI code, if any, will be created, only for those additional clarifications and complementing portions of the specification which have been created in this JSR

2.17 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).

N/A

2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.

Specification:

- The Specification will be made publicly available under two separate, royalty-free and fully paid-up licenses:-
a) A license for the purpose to analyze and use the specification for research, evaluation, and development will be available. No rights to use an implementation of the Specification for internal deployment, the creation and/or distribution of implementations of the Specification for direct or indirect commercial (including strategic) gain or advantage, the modification of the Specification (other than to the extent of the licensee's fair use rights) or the distribution of the Specification to third parties will be granted under that license.
b) A second license will be available granting rights for the creation and/or distribution of commercial implementations of the Specification in accordance with the JSPA.

TCK:

- Available free of charge to qualified not-for-profit organizations and individuals.
- The TCK will be licensed on a royalty free or direct cost recovery (over reasonable number of licensees and save for cost outside the control of the licensor) flat fee basis having a cap of a maximum of 50,000 USD, including all updates and new releases if any. The license will be worldwide, non-exclusive and will be granted on an AS IS basis without any warranties given and with the exclusion of all indirect and consequential damages.
- The license grant will be for a term not less than three (3) years.
- The TCK license will allow licensees testing implementations on behalf of third parties as a free or for-fee commercial service under certain conditions. This right may result in a higher license fee.
RI:

- The RI, if any, in binary form, will be licensed without a charge. The TCK and RI will be licensed separately to all interested parties.

Specification Leads of the selected Component JSRs will be requested to apply the same principles in order to become part of the Mobile Service Architecture specification, excluding: Connected Device Configuration, Connected Limited Device Configuration, Foundation Profile, Personal Basis Profile, Personal Profile, IM Profile, and Mobile Information Device Profile.





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.

NOTE that this information has been updated from this original proposal.

As already mentioned the specification is intended to be based upon CDC and the J2ME Foundation Profile 1.1 specification. In addition to that base platform, this JSR will explore all JSRs which are fulfilling the selected criteria, such as being able to deliver a TCK for the CDC environment, and are fit for the purpose defined for Mobile Service Architecture Specification. Additionally, this JSR may also refer to Java specifications created in other standards bodies. It is expected that this specification will reference, to begin with, the, JSR 232, JSR-185 and/or the Mobile Service Architecture JSR that is being developed parallel to this JSR. One of the essential tasks of this JSR is to select and refer to those additional Java Specifications that enable the JSR to fulfill its objectives.

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

NOTE that this information has been updated from this original proposal.

This specification would reference the above specifications and describe, in a normative fashion, the interaction between the various pieces of technology for the wireless services industry.