Printed: Mar 28, 2024
From: http://www.jcp.org/en/jsr/detail?id=12
|
Specification Leads | |||
Craig Russell | Sun Microsystems, Inc. | ||
Expert Group | |||
Adams, Matthew T. | akquinet tech@spree | Bobzin, Heiko | |
Ericsson Inc. | Garulli, Luca | IBM | |
Informix Software | Lawson Software | McClure, Martin | |
Object People | Objectivity, Inc. | Oracle | |
Plotnikov, Constantine | Progress Software | Rational Software | |
Roos, Robin | SAP SE | Secant Technologies, Inc. | |
Silverstream Software | Software AG | Sun Microsystems, Inc. | |
Suraparaju, Rajesh Babu | Versant Corporation | Xcalia |
Original Java Specification Request (JSR)
Identification | Request | Contributions
Section 1: Identification
The primary contact for this submission is:
Craig Russell
Sun Microsystems, Inc.
901 San Antonio Road UMPK16-304, Palo Alto, CA 94303 USA
phone: +1 650 786-7819
e-mail: clr@eng.sun.com
The contact information for the other companies who endorse this JSR is:
Bernard Normier
IONA Technologies Inc.
60 Aberdeen Ave. Cambridge, MA 02138 USA
phone: +1 617 949 4122
e-mail: bnormier@iona.com
Soumitro Tagore
Informix Corporation
300 Lakeside Drive, Suite 2700, Oakland, CA 94612 USA
phone: +1 510 628-3739
e-mail: stagore@informix.com
Richard Plederedar
Sybase Inc.
6475 Christie Ave, Emeryville, CA 94608 USA
phone: +1 510 922-3500
e-mail: pledar@sybase.com
Jack Greenfield
Inline Software, Inc.
751 Miller Drive SE Suite E3, Leesburg, VA 20175 USA
phone: +1 703 737-7750
fax: 1 + 703 737-0110
e-mail: jack@inline-software.com
Sriram Srinivasan
BEA WebExpress
San Francisco, CA USA
phone: +1 415 659-2600
email: sriram@weblogic.com
Fernando Velez
Ardent Software Inc.
1099 18th Street, Suite 2500 Denver, CO 80202 USA
phone: +1 303 313 3133
e-mail: fernando.velez@ardentsoftware.com
Henry Parnell
Object Design Inc.
25 Burlington Mall Road Burlington, MA 01803-4194 USA
e-mail: parnell@odi.com
Ron Raffensperger
Objectivity Inc.
301B E. Evelyn Avenue Mountain View CA 94041-1530 USA
phone: +1 650 254 7113
e-mail: ron.raffensperger@objectivity.com
Lougie Anderson
Gemstone Systems, Inc.
15400 NW Greenbrier Parkway Suite 280, Beaverton, OR 97006 USA
phone: +1 503 533-3600
e-mail: lougie@gemstone.com
John Pompeii
Secant Technologies Inc.
4853 Galaxy Parkway, Suite S Cleveland, OH 44128 USA
phone: +1 216 595 3830
e-mail: jpompeii@secant.com
David Jordan
Ericsson
7001 Development Drive, Research Triangle Park, NC 27709
phone: +1-919-472-6186
email: david.jordan@ericsson.com
Zaid Al-Timimi
Advanced Language Technologies
2030 Main Street, Suite 530, Irvine, CA 92614
phone: +1-949-863-9877
email: zaid@altConsulting.com
Torsten Stanienda
Baan Company - Tech@Spree Software Technology GmBH
Buelowstr. 66, 10783 Berlin Germany
Phone: +49-(0)-30 235 520 0
email: tst.tech@spree.de
Paul Lipton
Computer Associates International, Inc.
Route 206 and Orchard Road, Princeton, NJ 08543-0008 USA
phone: 908-874-9479
email: lippa02@cai.com
Tony Kamarainen
Lawson Software
1300 Godward Street, Minneapolis, MN 55413-3004
phone: +1-612-379-8086
email: tony.kamarainen@lawson.com
Jeff Eastman Windward Solutions, Inc.
395 W. El Camino Real, Sunnyvale, CA 94087
phone: +1 408 523 5811
email: jeff@windwardsolutions.com
Henry Strickland
Versant Corporation
6539 Dumbarton Circle, Fremont, CA 94555
phone: 510-789-1680
e-mail: strick@versant.com
Bernd Hartings
Rosch Consulting
Am Siepbach 9, D-41564 Kaarst, Germany
phone:
+49.21.31.986-3 00
e-mail:
bh@roesch.com
Dirk Bartels
Poet Software
phone: +1-650- 286-4640
e-mail: dirk@poet.com
Section 2: Request
All Java platforms, including desktop, server, personal, embedded, and card, can use this API to access data.
The Java community needs a standard way to store Java objects persistently in transactional data stores. Furthermore, it needs a standard way to treat relational database data as Java objects, and a standard way to define transactional semantics associated with those objects.
The term Java Data Objects is a placeholder for this functionality, pending the choice of a final name.
Existing specifications for persistence include JDBC, SQLJ, and java.util.Serializable. The JDBC and SQLJ mechanisms provide for query, transactions, and large capacity storage, but require that users learn another language (SQL). This proposal allows users to specify their application program logic, including queries, entirely in Java, and express the mapping, if any, to the database with a separate mechanism. The java.util serialization protocol provides for persistence, but it does not offer query capability, transactional behavior, nor large capacity data storage. In addition, both the serialization and SQL APIs require that the programmer explicitly fetch and store Java objects from a database; we propose transparent persistence, doing this automatically.
This is a high level API that may be implemented using lower level APIs like JDBC or SQLJ PART 0 to store data. This specification provides for interface-based definition of data stores, transactions, selection, and transformation of persistent storage data into native Java objects. There are several major parts of the specification:
The working name for the package is javax.jdo. This name is subject to a better proposal during the life of the project.
The Reference Implementation will be implemented in 100% Pure Java. Other implementations may use native code for parts of the underlying mapping to database storage, but native code is neither required nor proscribed.
This specification will exploit existing security mechanisms of both the Java environment and the underlying data storage mechanisms, such as relational databases or file systems.
Internationalization and localization of implementations are not required, nor are they proscribed by this specification.
Several vendors, independent of Sun?s activities to standardize the interface have implemented a similar specification. Thus, there is a corpus of code and techniques upon which to rely while finalizing the specification. The reference implementation can be obtained from parties interested in this specification, but there is no guarantee that negotiations for an appropriate license will be successful. The compatibility test suite is the major source of risk. An industry consortium comprising users and vendors of object databases, object relational mappings, relational databases, and Java tools may jointly develop the compatibility test suite, but there is no guarantee that the consortium will fund the work.
There are no existing specifications or specification requests pending that would be rendered obsolete by this specification.
There are no existing specifications that would need revision as a result of this specification.
Section 3: Contributions
This Specification will incorporate parts of the Object Data Management Group 3.0 persistent storage interface. A number of products from Specification participants, such as Sun's Java Blend, already conform to earlier versions of this API and participants have experience with it. The Object Data Management Group has agreed to grant all present and future rights to the interface for use by the specification lead and the community process, and the group members have volunteered to participate in the community process for work on the specification. As part of the community process, the specification will be extended to include specific requirements for storage of objects in Relational Database Management Systems and file systems, and will be aligned and integrated with evolving enterprise Java APIs such as Java Transactions and Enterprise Java Beans.
Work from the OSGI (Open Services Gateway Initiative) will probably also be used in the Specification. OSGI is currently under the Java Community Process. An effort will be made to satisfy the needs of OSGI with the Specification as well, deriving a common API for both uses.