 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 230: Data Sync API
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. The following information has been updated from the original request: 2005.10.17: The Spec Lead changed from Siemens AG to BenQ Corporation. Original Java Specification Request (JSR)
Identification |
Request |
Contributions
Section 1. Identification Submitting Member: Siemens Name of Contact Person: Jens Paetzold E-Mail Address: jens.paetzold@siemens.com Telephone Number: +49 89 722 58563 Fax Number: +49 89 722 35087 Specification Lead: Jens Paetzold E-Mail Address: jens.paetzold@siemens.com Telephone Number: +49 89 722 58563 Fax Number: +49 89 722 35087 Initial Expert Group Membership: Motorola Supporting this JSR: Motorola Section 2: Request
2.1 Please describe the proposed Specification:This JSR will be a J2ME optional package that can be used with the J2ME configurations CLDC and CDC. It enables applications to synchronize their application specific data stored in the terminal with corresponding data stored on a server, replicating any changes made to either instance of the data. It should provide a generic interface to the data synchronization device implementation, to enable data synchronization via underlying implementations of data synchronization protocols. One example of the data synchronization protocols to be accessed from Java applications will be SyncML / OMA Data Synchronization. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)The API will support the configurations CLDC / CDC and the MIDP profile (Mobile Information Device Profile v2.0) using MIDlets. Nevertheless this API should be usable with any profile on top of the J2ME CLDC and CDC configurations. 2.3 What need of the Java community will be addressed by the proposed specification?The need of Java applications for data synchronization by using well defined Sync protocol such as SyncML Data Sync as standardized by SyncML.org and Open Mobile Alliance (OMA). 2.4 Why isn't this need met by existing specifications?The current J2ME specifications do not cover synchronization. 2.5 Please give a short description of the underlying technology or technologies:The JSR uses the data synchronization frameworks 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.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)For new packages: javax.microedition.* 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?Most data synchornization protocols 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.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.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.12 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.13 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. 2.14 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.15 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.Early information on license terms as defined in the JCP process: Siemens will license to all interested parties. TCK and RI will be available separately for license, independent
implementations will be allowed. 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.? SyncML.org and Open Mobile Alliance Specifictions for Data Synchronization version 1.1 (1.2 if available in time) 3.2 Explanation of how these items might be used as a starting point for the work.Due to the optional package character of the request, considerable cross references towards configurations and profiles the package is based on are expected. |
