 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 249: Mobile Service Architecture 2
This JSR has been Dormant The following information has been updated from the original JSR: 2015.04.13: The Specification Lead from Nokia Corporation has changed to Adamu Haruna. Specification Lead: Adamu Haruna
E-Mail Address: adamu.haruna Telephone Number: - Fax Number: - 2012.08.21: The Specification Lead from Nokia Corporation has changed to Erkki Rysä. The Vodafone Specification Lead is unchanged. Specification Lead: Erkki Rysä (Nokia Corporation)
E-Mail Address: jsr249 Telephone Number: - Fax Number: - 2012.08.10: The Specification Lead from Vodafone has changed to Guenter Klas. The Nokia Corporation Specification Lead is unchanged. Specification Lead: Guenter Klas (Vodafone Group Services Limited)
E-Mail Address: guenter.klas Telephone Number: - Fax Number: - 2012.07.12: The Specification Lead from Nokia Corporation has changed to Wang Cheng. The Vodafone Specification Lead is unchanged. Specification Lead: Wang Cheng (Nokia Corporation)
E-Mail Address: cheng.9.wang Telephone Number: - Fax Number: - 2010.01.12: The Specification Lead from Vodafone has changed to Edin Bektesevic. The Nokia Specification Lead is unchanged. Specification Lead: Edin Bektesevic (Vodafone Group Services Limited)
E-Mail Address: edin.bektesevic 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 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 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 Supporting this JSR: * Ericsson Mobile Platforms 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 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 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: 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. 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:- TCK:
- Available free of charge to qualified not-for-profit organizations and individuals. - 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. |
