I am rewriting my client-server rich client database application (Swing) to a three-tiered application with a Netbeans RCP rich-client.
By default Hibernate and other JPA providers can be used only in a very cumbersome way from rich clients (native database connection not cutting through firewalls, loosing lazy-loading, conceptual problems with managing Session/EntityManager lifecycles…etc other problems). So one needs some kind of extension for using them comfortably in rich clients.
Normally, rich clients call webservices in the business logic tier (on the server). Usually, dedicated web-service methods handle the CRUD operations of every object type.
Now, I wouldn’t like to write a custom web-service for the CRUD operations of each and every persistent class of my application so I thought there may be a generic persistence web-service for these kind of operations which can handle at least all of the CRUD operations of the application.
Is there such a persistence service???
Here are the details of my ideas/requirements:
The service should work with JPA-annotated POJOs so it should use some kind JPA persistence provider on the server. Currently, I am using Hibernate so if it actively supports Hibernate, it is a plus. Of course the POJO classes must be included in the server side JPA configuration, I don’t expect to handle ANY KIND of unknown POJOs.
I wouldn’t like to create separate Value Objects or Data Transfer Objects for sending data between the client and server parts of the service. I would like to use only JPA annotated POJOs even for transfer. I believe this is standard practice nowadays.
The client should receive data and send data with HTTP requests to the server-side of the service, in order to lessen firewall communication problems. HTTP proxy usage should be configurable.
The client side of the persistence service can get POJO list results for its executed JPA QL queries (sent as a simple query string, optionally ** named parameters** also sent in the request). These queries are sent from the client in the form of a webservice call or simple HTTP request to a servlet. It would be nice if several JPA queries could be sent in one request. The client receives the result of the requests as lists of POJOs which may have lazy-loaded collections and object references (these are not sent from the server in query-time).
The client side of the persistence service should be able to fulfill lazy-loading requests automatically/transparently, when the client application accesses a lazy-loaded attribute in a POJO (at a later point in time, not at the initial query). So, transparent lazy loading should remain working after the POJO has been transferred to the client.
New, updated/dirty or to-be-deleted POJOs can be sent by the client side of the persistence service to the server where the changes get persisted and success/failure statuses are sent back (e.g. the ID which was given to the newly persisted POJOs). Several to-be-saved POJOs could be sent in one request.
It should have a mechanism for marking transaction boundaries, so more than one independent HTTP service calls could be executed in one database transaction (keeping something like Session/EntityManager.beginTransaction(), commit() and rollback()).
Would be nice if validation and access control checks could be plugged into the server component.
Is there such a persistence service project???
Possibly as an extension shipped with a JPA persistence provider?
When I designed a similar app back in 2002, we searched far and wide for a framework to use, but finally had to run our own.
Transporting sub-graphs of persistent objects to the swing client was done by translating those to DTO (DataTransferObjects) objects, which maintained an attribute mapping and information if an attribute was being dirtied by the client. On the way back to the server, only the dirtied attributes were updated in a trx.
You might want to use JDO 2.0 as a persistence layer. It supports detaching objects or sub-trees from a persistent object graph, sending those detached objects over the wire and re-attaching those in a later transaction.
However, you lose the ability to minimize the data you send across the wire.
Best bet so far: Run your own mechanism and add a createDTO and updateFromDTO method to your persistent objects, but I’d be very happy to be proven wrong.