 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 246: Device Management API
JCP version in use: 2.6 Java Specification Participation Agreement version in use: 2.0 Description: Enabling J2METM applications to access device management implementations Please direct comments on this JSR to the Spec Lead(s) Team
This JSR has been Dormant The following information has been updated from the original JSR: 2009.07.06: The Maintenance Lead changed to Sun Microsystems. Specification Lead: Jens Paetzold E-Mail Address: jens.paetzold@sun.com Telephone Number: +49 89 46008 1248 Fax Number: - 2007.04.11: Jim Lee is the current temporarily acting Spec Lead. Updates to the Original JSR for Reconsideration This information has been updated from the original request. 2005.10.17: The Spec Lead changed from Siemens AG to BenQ Corporation. 2004.07.13: These updates were submitted by the Spec Lead for the EC's JSR Reconsideration Ballot. Initial Expert Group Membership: Matsushita Electric Industrial Co., Ltd. Supporting this JSR: Matsushita Electric Industrial Co., Ltd. 2.1 Please describe the proposed Specification:
This JSR will be an optional package for the J2ME CLDC configuration. It should provide a generic interface to the Device Management implementation in the device, to enable device management via natively implemented Device Management protocols.
The API will provide the possibility for Java applications to access parameters that can be managed remotely using the Device Management protocols. It enables the use of the underlying device management implementation. It also provides mechanisms to control additional functionality in the framework, such as triggering management sessions, notifications on changes etc.
The API's focus is on the widely available Device Management protocols SyncML/OMA DM and WAP/OMA Client Provisioning.
2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)J2ME CLDC
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 API will support the configuration CLDC. On top of this configuration this optional package will run in the context of the corresponding profiles MIDP and IMP.
2.6 Why isn't this need met by existing specifications?Currently available mobile devices already include support for device management. A Java API as described above is currently missing for CLDC configuration. This API is an immediate need and is independent from the different possible device management implementations, which allows an independent API definition with best time to market. This JSR's scope is the CLDC configuration and is complementary to the CDC scope in JSR 232. As already agreed, the spec leads of JSR 232 and JSR 246 will closely work together to prevent fragmentation of the DM API.
2.7 Please give a short description of the underlying technology or technologies:The JSR uses the Device Management implementations already available on most mobile platforms. It focuses on the definition of a generic API that covers most of the existing implementations. For example, this enables the use of SyncML Device Management technology as standardized by SyncML.org and Open Mobile Alliance.
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.The expert group will remain open for new nominations until Early Draft Review (EDR). Interim drafts of the specification will be made available on the JSR community page. The schedule will be defined by the expert group. Additionally the observer alias will be used, to inform interested members of the community about progress and open issues in this JSR. The users@jsp-spec-public mailing list will be open to the public to discuss issues related to the JSP specification.
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.Due to the optional package character of this request, RI and TCK will be delivered as standalone products.
3.2 Explanation of how these items might be used as a starting point for the work.The base configuration and profile documents provide the framework in which the Device Management API must operate. The protocols specifications used in the framework, i.e. the SyncML, OMA, and WAP forum specifications describe the technology that have to be implemented to ensure interoperability. This device management protocols and their implementations can be used as a starting point.
Original Java Specification Request (JSR)
Identification |
Request |
Contributions
Section 1. Identification Submitting Member: Siemens AG Name of Contact Person: Jens Paetzold E-Mail Address: jens.paetzold@siemens.com Telephone Number: +49 89 722 31010 Fax Number: +49 89 722 35087 Specification Lead: Jens Paetzold E-Mail Address: jens.paetzold@siemens.com Telephone Number: +49 89 722 31010 Fax Number: +49 89 722 35087 Initial Expert Group Membership: Matsushita Electric Industrial Co., Ltd. NOTE that this section has been updated for the JSR Reconsideration Ballot. Supporting this JSR: Matsushita Electric Industrial Co., Ltd. Section 2: Request
2.1 Please describe the proposed Specification:NOTE that this section has been updated for the JSR Reconsideration Ballot. This JSR will be an optional package for the J2ME configurations CLDC and CDC. It should provide a generic interface to the Device Management implementation in the device, to enable device management via natively implemented Device Management protocols. The API will provide the possibility for Java applications to access parameters that can be managed remotely using the Device Management protocols. It enables the use of the underlying device management implementation. It also provides mechanisms to control additional functionality in the framework, such as triggering management sessions, notifications on changes etc. The API's focus is on the widely available Device Management protocols SyncML/OMA DM and WAP OTAP. The API should also seamlessly integrate with management framework implementations in this area (e.g. OSGi/MEG). The API should be a high level API, that provides a common set of management commands, that are available in all management protocols. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)NOTE that this section has been updated for the JSR Reconsideration Ballot. embedded, card 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 section has been updated for the JSR Reconsideration Ballot. The API will support the configurations CLDC and CDC. On top of this configurations this optional package will run in the context of the corresponding profiles (MIDP, FP, IMP). 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?The need of Java applications for Device Management by using well defined standardized APIs and to enable Java applications to access management information, such as configuration and setup data stored in the device. This information can be managed remotely from a server using the Device Management protocols implemented in the device. 2.6 Why isn't this need met by existing specifications?NOTE that this section has been updated for the JSR Reconsideration Ballot. Currently available mobile devices already include support for device management. A Java API as described above is currently missing. This API is an immediate need and is independent from the different possible device management implementations, which allows an independent API definition with best time to market. This JSR?s scope does not include deployment-, lifecycle- and policy-management, as JSR 232 does, therefore no overlapping. It should be the goal that already defined APIs in the J2ME space will be reused by the different services to plug into management framework implementations (e.g. into OSGi), to avoid J2ME space fragmentation. Therefore this API should also be reused as for example existing ones like JSR 205 (to be reused by a potential MMS service). 2.7 Please give a short description of the underlying technology or technologies:NOTE that this section has been updated for the JSR Reconsideration Ballot. The JSR uses the Device Management implementations already available on most mobile platforms. It focuses on the definition of a generic API that covers most of the existing implementations. For example, this enables the use of SyncML technology as standardized by SyncML.org and Open Mobile Alliance. 2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)For new packages: javax.microedition.* 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?Most Device Management implementations already contain their own security model. As far as possible this security model should be mapped to the Java security model, with no changes in security as a design goal. 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.It should be possible to complete this API specification in a reasonable time (12 months) since it is narrowly scoped and it will build on the previous work using vendor specific APIs and experience. 2.14 Please describe the anticipated working model for the Expert Group working on developing this specification.It is anticipated that a combination of email discussion, feedback on regular drafts, conference calls and face-to-face meetings will work well. 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.NOTE that this section has been updated for the JSR Reconsideration Ballot. Due to the optional package character of this request, RI and TCK will be delivered as standalone products. 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.NOTE that this section has been updated for the JSR Reconsideration Ballot. Stand-alone. 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.We will license to all interested parties. Independent implementations will be allowed. TCK and RI will be licensed separately. For TCK we will charge a single one time fee of max $50 000 USD and an annual maintenance fee, max $20 000 USD/pa. TCK will include the binary environment and source code of the test suite. Maintenance fee covers limited basic support, first level TCK appeals process, bug fixes and updates, which are due to changes in the specification, and when made available by the specification lead. Major new releases (esp. follower JSR) might be subject to additional single one time fee. For RI in source code form we will charge one time access fee, and annual maintenance fee. Maintenance covers bug fixes, updates and new releases necessary due to spec changes, and when made generally available by specification lead. 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.
3.2 Explanation of how these items might be used as a starting point for the work.NOTE that this section has been updated for the JSR Reconsideration Ballot. Due to the optional package character of the request, considerable cross references towards configurations and profiles the package is based on are expected. The base configuration and profile documents provide the framework in which the Device Management API must operate. The protocols specifications used in the framework ? i.e. the SyncML, OMA, WAP forum and OSGi specifications describe the protocols that have to be implemented to ensure interoperability. This device management protocols and their implementations can be used as a starting point. |
||||||||||||||||||||||||||||||||||||||||||||||||
