Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

EclipseLink/DesignDocs/390352

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

Leverages existing Remote Session functionality.

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

Back to the top