 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 347: Data Grids for the JavaTM Platform
This JSR has been Withdrawn The following updates have been made to the JSR since the original proposal.
2015.01.06:
2013.11.07: Specification Lead: Red Hat E-Mail Address: mmarkus Telephone Number: +44 07540343256 Fax Number: -
2012.12.17: 2.19 Please describe the communications channel you have established for the public to observe Expert Group deliberations, provide feedback, and view archives of all Expert Group communications.Mailing list and public wiki: https://github.com/datagrids/spec/wiki/Expert-Group 2.20 What is the URL of the Issue Tracker that the public can read, and how does the public log issues in the Issue Tracker?https://github.com/datagrids/spec/issues 2.21 Please provide the location of the publicly accessible document archive you have created for the Expert Group.https://github.com/datagrids/spec/wiki Original Java Specification Request (JSR)
Identification |
Request |
Contributions
Section 1. Identification Submitting Member: Red Hat Inc. Name of Contact Person: Manik Surtani E-Mail Address: manik Telephone Number: +44 7786702706 Fax Number: +44 20 7009 4445 Specification Lead: Red Hat E-Mail Address: manik Telephone Number: +44 7786702706 Fax Number: +44 20 7009 4445 Initial Expert Group Membership: Red Hat Inc. Supporting this JSR: Red Hat Inc. Section 2: Request
2.1 Please describe the proposed Specification:This specification proposes to provide an API for accessing, storing, and managing data in a distributed data grid. The primary API will build upon and extend JSR-107 (JCACHE) API. In addition to its genericized Map-like API to access a Cache, JSR-107 defines SPIs for spooling in-memory data to persistent storage, an API for obtaining a named Cache from a CacheManager and an API to register event listeners. Above and beyond JSR-107, this JSR will define characteristics and expectations from eviction, replication and distribution, and transactions (via the JTA specification). Further, it would define an asynchronous, non-blocking API as an alternative to JSR-107?s primary API, as non-blocking access to data becomes a concern when an implementation needs to perform remote calls, as in the case of a data grid. This specification builds upon JSR-107, which is not yet complete. We intend to work with the JSR-107 EG to ensure that their schedule is compatible with the schedule for this JSR. If JSR-107 is unable to complete, we propose merging the last available draft into this specification. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)Desktop, Server 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.While this is primarily targeted at Java SE, it is particularly useful in a Java EE environment, especially when related to other EE technologies such as JTA. Further, it helps enhance Java EE making it more cloud-friendly by providing standardized access to a distributed data grid. Data grids are commonly used along with Java EE in cloud - or any highly scalable - configurations. 2.4 Should this JSR be voted on by both Executive Committees?No. It should be voted on by the Java SE / EE Executive Committee only. 2.5 What need of the Java community will be addressed by the proposed specification?Data grids are commonly used as a technique to manage data in highly scalable and elastic middleware, whether to manage transient, in-flight session state - thereby introducing high availability characteristics - or to front persistent data stores as a distributed cache. This JSR provides a standard API for accessing and working with data grids. 2.6 Why isn't this need met by existing specifications?The closest specification is the currently inactive JSR-107 (JCACHE) specification, which proposes a standalone temporary cache API. We feel that this API is too simplistic to be useful in a distributed environment, as characteristics such as replication and distribution of data is not specified. Neither is interaction with JTA specified or required in JSR-107, which makes it less suitable for the Java EE environment. 2.7 Please give a short description of the underlying technology or technologies:Storing data in-memory for fast, low-latency access helps achieve scalability, but in a clustered, distributed world, such in-memory stores need to be coherently maintained to prevent reading of stale data. Furthermore, to be truly scalable, a data distribution model is needed to ensure adequate copies are maintained in a cluster to provide resilience to server failure, yet not too many copies which would hamper scalability. Such data should also be accessible from any server, regardless of whether the data is locally stored or not. 2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)javax.datagrid 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?No 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?JSR-107 is currently incomplete, but this JSR will build upon and extend JSR-107. See the note in section 2.1 regarding this. Further, specifications such as JSR-317 (JPA2) would be able to make use of a distributed data grid as a 2nd level cache. 2.13 Please describe the anticipated schedule for the development of this specification.May 2011: finalise expert group 2.14 Please describe the anticipated working model for the Expert Group working on developing this specification.The primary means of communication will be email (via mailing list) and conference calls, with meetings on IRC channels if deemed appropriate. Face-to-face meetings will be scheduled if needed. 2.15 Provide detailed answers to the transparency checklist, making sure to include URLs as appropriate:* The public can read the names of the people on the Expert Group. We intend to use the JBoss.org infrastructure, popular among public open source projects. This will be publicly visible and accessible. * The Expert Group business is regularly reported on a publicly readable alias. We intend to use the JBoss.org infrastructure, popular among public open source projects. This will be publicly visible and accessible. * The schedule for the JSR is publicly available, it's current, and I update it regularly. We intend to use the JBoss.org infrastructure, popular among public open source projects. This will be publicly visible and accessible. * The public can read/write to a wiki for my JSR. We intend to use the JBoss.org infrastructure, popular among public open source projects. This infrastructure provides a publicly accessible wiki system. * I read and respond to posts on the discussion board for my JSR on jcp.org. Yes, once the JSR is approved these details will be made public. * There is an issue-tracker for my JSR that the public can read. We intend to use the JBoss.org infrastructure, popular among public open source projects. This infrastructure provides a publicly accessible issue tracker. * I have spoken at conferences and events about my JSR recently. Currently blogged about on http://bit.ly/data_grid_jsr and spoken to interested parties individually. Not publicly spoken about at conferences or other events as yet. * I am using open-source processes for the development of the RI and/or TCK. Yes, this is the plan. Red Hat, as a spec lead, has a track record in this regard, with JSR-299 (Contexts and Dependency Injection) and JSR-303 (Bean Validation). * The Update tab for my JSR has links to and information about all public communication mechanisms and sites for the development of my JSR. We intend to use the JBoss.org infrastructure, popular among public open source projects. This will be publicly visible and accessible. 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.Red Hat will deliver a Reference Implementation (RI) and Technology Compatibility Kit (TCK) compatible with Java EE 7. The license used will be the Apache Software License (ASL) 2.0, an open source license which is compatible with Java EE licensing. 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.Red Hat will deliver a Reference Implementation (RI) and Technology Compatibility Kit (TCK) compatible with Java EE 7. The license used will be the Apache Software License (ASL) 2.0, an open source license which is compatible with Java EE licensing. The Specification will use the standard license template. Note that the following information was added to the proposal on 2012.12.17, when the Specification Lead and Expert Group moved this JSR to JCP 2.9:2.19 Please describe the communications channel you have established for the public to observe Expert Group deliberations, provide feedback, and view archives of all Expert Group communications.Mailing list and public wiki: https://github.com/datagrids/spec/wiki/Expert-Group 2.20 What is the URL of the Issue Tracker that the public can read, and how does the public log issues in the Issue Tracker?https://github.com/datagrids/spec/issues 2.21 Please provide the location of the publicly accessible document archive you have created for the Expert Group.https://github.com/datagrids/spec/wiki 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.* Parts of JSR-107 (JCACHE) 3.2 Explanation of how these items might be used as a starting point for the work.JSR-107's API is, while too limited for a data grid, a valid starting point. Additional features, including an Asynchronous API as well as clear definitions of cluster modes such as LOCAL, REPLICATED and DISTRIBUTED will be taken from the Infinispan project. |
