Difference between revisions of "EclipseLink/DesignDocs/390352"

From Eclipsepedia

Jump to: navigation, search
(Testing)
(Functionality)
Line 44: Line 44:
  
 
= Functionality =
 
= Functionality =
Leverages existing Remote Session functionality.
+
Currently EclipseLink supports a RemoteSession feature which allows remote access through the Session API.
 +
 
 +
The following is required to enable this functionality through JPA:
 +
* JPA classes must accept any Session type (AbstractSession instead of DatabaseSession).
 +
* JPA uses attribute change tracking, which does not work with current RemoteSession.
 +
* JPA supports flush (RepeatableWriteUnitOfWork), which does not work with current RemoteSession.
 +
* JPA requires more meta-data than RemoteSession currently exposes through descriptor serialization.
 +
 
 +
===API===
 +
The JPA API will be the same on client versus server.  Remote connection properties will be specified through persistence unit properties.
 +
 
 +
===Querying===
 +
RemoteSession supports sending DatabaseQuery objects, as well as calling queries remotely by name.
 +
 
 +
Currently JPA parses JPQL to create a DatabaseQuery, so this will need to occur on the client, or a new type of generic JPQL DatabaseQuery will need to be used.
 +
Named queries in JPA are not currently invoked as named queries in the Session, but just looked-up and executed normally.  A different mechanism would be required to execute a query remotely by name.
 +
 
 +
The queries could be prepared on the client or on the server.  Preparing on the client could mean more data is serialized as part of the query definition, but it could also mean less data as SQL is less data than serialized Criteria or Expression objects.  Preparing the queries on the client is the simpler solution, so will be used in the first phase.  Preparing queries on the server will be investigated for future phases.
 +
 
 +
===Tasks===
 +
The work will be broken into the following phases:
 +
 
 +
Phase 1:
 +
* JPA will be made compatible with RemoteSession (or any AbstractSession).
 +
* JPA artifacts and meta-data will be ensured to be serializable.
 +
 
 +
Phase 2:
 +
* Basic querying (queries will be prepared on client, database call sent to server)
 +
* Basic units of work (no change tracking, no flushing).
 +
 
 +
Phase 3:
 +
* Complex units of work (change tracking, flushing, etc.)
 +
 
 +
Phase 4:
 +
* Optimized querying (named queries, jpql prepared on server)
 +
* Optimized units of work (only send change sets, no objects)
  
 
= Testing =
 
= Testing =

Revision as of 11:18, 3 October 2012

Design Specification: Remote JPA

ER 390352

Feedback

Document History

Date Author Version Description & Notes
2012-10-03 James 0.1 Draft

Project overview

Remote JPA would allow access to the JPA API from a remote Java client. This would allow fat Java clients to access the richness of the JPA API, and not require a data transfer layer. This can avoid the need for remote SessionBeans, merging, and data transfer objects. It provides querying, transactions, change tracking, and lazy relationship support on the Java client.

It could also be used in distributed architectures to perform database intensive work closer to the database, for more optimal interaction.

Concepts

  • Java fat-client - client user interface is Java, (versus html), this could be a Java desktop or WebStart application, Java applet, or possibly an Android client.
  • RMI - Java communication framework, makes use of Java serialization to send objects.
  • CORBA - language independent communication framework
  • RemoteSession - existing EclipseLink feature that provides the EclipseLink native Session API to a remote Java client.

Requirements

  • JPA API
  • query execution
  • transaction/unit of work
  • change tracking, flushing
  • lazy relationships
  • load groups, eager relationships

Design Constraints

  • security - need to determine how security will be provided
  • communication protocol - what protocols should be supported
  • serialization - should provide alternative serialization options to Java serialization

Functionality

Currently EclipseLink supports a RemoteSession feature which allows remote access through the Session API.

The following is required to enable this functionality through JPA:

  • JPA classes must accept any Session type (AbstractSession instead of DatabaseSession).
  • JPA uses attribute change tracking, which does not work with current RemoteSession.
  • JPA supports flush (RepeatableWriteUnitOfWork), which does not work with current RemoteSession.
  • JPA requires more meta-data than RemoteSession currently exposes through descriptor serialization.

API

The JPA API will be the same on client versus server. Remote connection properties will be specified through persistence unit properties.

Querying

RemoteSession supports sending DatabaseQuery objects, as well as calling queries remotely by name.

Currently JPA parses JPQL to create a DatabaseQuery, so this will need to occur on the client, or a new type of generic JPQL DatabaseQuery will need to be used. Named queries in JPA are not currently invoked as named queries in the Session, but just looked-up and executed normally. A different mechanism would be required to execute a query remotely by name.

The queries could be prepared on the client or on the server. Preparing on the client could mean more data is serialized as part of the query definition, but it could also mean less data as SQL is less data than serialized Criteria or Expression objects. Preparing the queries on the client is the simpler solution, so will be used in the first phase. Preparing queries on the server will be investigated for future phases.

Tasks

The work will be broken into the following phases:

Phase 1:

  • JPA will be made compatible with RemoteSession (or any AbstractSession).
  • JPA artifacts and meta-data will be ensured to be serializable.

Phase 2:

  • Basic querying (queries will be prepared on client, database call sent to server)
  • Basic units of work (no change tracking, no flushing).

Phase 3:

  • Complex units of work (change tracking, flushing, etc.)

Phase 4:

  • Optimized querying (named queries, jpql prepared on server)
  • Optimized units of work (only send change sets, no objects)

Testing

Will use JPA fieldaccess EntityManager test suite (JPA SRG).

API

Native API

Config files

Documentation

Should be documented under a new Remote JPA section.

Open Issues

Issue # Owner Description / Notes
1 Can unit of work commit only send changes, instead of objects? Currently sends both, commit currently requires objects.
2 What communication protocols should be supported? Currently RMI, maybe CORBA.

Decisions

Issue Description / Notes Decision

Future Considerations