Reuse entity on server and client side in EJB<->JSF2 application

Question

I started to learn EJB few weeks ago and I've got question about how to reuse entity class on client and server side. Assume that we've got CRUD application.

1. Server is written as EJB and manages data (create, read, update, delete). It uses JPA to connect with database.
2. Client is written using JSF2 and it's a simple gui which uses remote EJB to manage data.
3. Both (client and server) works on different servers.
4. To use EJB, client needs to have EJB interface and entities (entities are needed to deserialize objects returned by EJB).
5. Server side Entities have got JPA annotations.
6. Client side Entities needs to be the same as server but don't need JPA annotations.
7. Both (client and server) entities should be in the same jar library because it's easier to maintain.

Those are my suggestions to solve the problem:

1. Create library which contains only entity interfaces so client and server can implement it in the way that they need.
2. Create library which contains entity implementations without JPA annotations (server will need to use xml instead of annotations).

What is the best solution? Are my solutions correct? I would be grateful for any suggestions.

Answer 1

If you trust the client or if you don't care if any JPA annotations leak to the client, you can use the JPA entities as data tranfer objects (DTOs). Caveat: Any lazy managed relationships not fetched by the server will be unavailable to the client, may cause exceptions during serialization, or may query and serialize too many things. (This is your option 1)

Alternatively, you may create DTOs for each entity. There may be many DTOs per entity (e.g. a full DTO containing all fields of a forum post, a summary DTO containing only title, date, author). You may use utilities like Commons BeanUtils to reflectively copy from Entity to DTO without writing lots of boilerplate code (dto.setTitle(entity.getTitle()); dto.setDate(entity.getDate()); ...). In this case the DTOs live in a separate JAR, shared by client and server, but the entities live in their own deployment unit and are private to the server. This was the most adverised practice in the old days of EJB 1/2. (This has some similarities to your option 2, but you will be reusing the DTOs instead of the entities themselves)

Then you may expose the server as WEB services or REST endpoints (JAX-WS and JAX-RS make this very easy). With proper configuration it may even be possible to reuse the JPA beans in the client. This has the extra bonus of being interoperable with other technologies, but will probably be slow.

Your option 2 is also viable, but you will add the overhead of maintaining the XML deployment descriptor (XDoclet may be of help in this case, if it supports JPA - haven't used it for many-many years).

When using remoting of any kind, be aware that communication is generally expensive. Therefore remote calls should be as coarse-grained as possible and data exchanged as little as possible (hence the summary DTO mentioned above).