1

I am currently working on a 3-tier application with Java-EE6 (GlassFish 3.1.2, MySQL Server 5.1 and Netbeans 7.1.1).

The project currently consists of 3 projects:

  • Enterprise Application / EJB's: facades to control entities on the database
  • Java Class-Library: @Entity annotated classes that represent the database model (this project is shared by the EE-app and the fat-clients in order to exchange the entity instances between tiers)
  • J2SE Fat-Client: JNDI lookup of server resources (remote access to EJB's)

For updating the client's GUIs when entities are created/modified/deleted I decided to make use of JMS by implementing a Topic where each client subscribes on start-up and a message-driven bean on the EJB-container serves as publisher.

Now I face the following big issue:

  • I attached life-cycle listeners (@PostUpdate, etc.) to the entity objects which then should publish the update messages to the subscribed clients. The entity classes reside in the class-lib project, whereas the publisher resides in the EE-app. The problem is, that the EE-app references the class-lib project, but not vice-versa (since cyclic project references are not allowed). Thus the life-cycle callback methods in the entity classes do not have a reference on the message-driven publisher bean in the EE-app.

This is a more design-related question & thus asking you if this is basically the right approach to design a 3-tier application with Java-EE6 ?

I want to avoid DTO/DAO if possible in order to keep complexity as low as possible and the application does not produce heavy network traffic.

Thanks for your advise in advance !

salocinx
  • 3,715
  • 8
  • 61
  • 110

1 Answers1

0

I solved the problem by passing the @Entity objects directly between all the layers. By activating static weaving (using eclipse-link as jpa provider) I was able to use lazy fetching for the heavy relations. In order to only fetch particular important relations from the client side, I use load groups to define the lazy relations that should be pre-fetched before serialized over the network which detaches the entity from the entity manager. vis-versa to send an entity to the server again, I just use EntityManager.merge(T) on the server side facade to put the entity back to managed state. This design works fine, even for very complex data hierarchies.

salocinx
  • 3,715
  • 8
  • 61
  • 110
  • Do you mean that you send @Entities to the thick client, out of the EJB server context? but these entities are not serializable since the relationships are proxies, how do you manage to make this work without DTOs? – Mr.Eddart Oct 24 '12 at 08:51