Deployment and Testing
After creating the database records in the App.PROFILE
table, start up the database and the application server. You will use GlassFish as your application server for deployment.
After the project Account.ear successfully deploys as an enterprise archive with the EJB and the web modules, you will see the JNDI entry for the remote SLSB in the JNDI browser provided by the GlassFish console. If Spring didn't find the JNDI entry or any other injection elements, it will give a deployment time error.
The application retrieves the profile of a user based on an ID and updates it. For the read and update, you can see the following output:
Hibernate: select profile0_.PROFILEID as PROFILEID0_0_, profile0_.ADDRESS as ADDRESS0_0_,
profile0_.EMAIL as EMAIL0_0_, profile0_.FNAME as FNAME0_0_, profile0_.LNAME as LNAME0_0_
from APP.PROFILE profile0_ where profile0_.PROFILEID=?|#]
Hibernate: update APP.PROFILE set ADDRESS=?, EMAIL=?, FNAME=?, LNAME=? where PROFILEID=?|#]
Best Practice Tips
As a simple implementation to demonstrate using Spring, EJB 3.0, and Hibernate, the application example includes a few compromises in its architecture and layout. In a real world enterprise application, you should further split the EJB project into a separate domain project (possibly called AccountDomain) and place the classes beyond the EJB in it. This would allow for further separation between the container-specific component implementation like EJB and a purely POJO-based domain. So if the application requirements change at all in the future, the EJB can be cleanly eliminated.
Also, it is always a good idea to implement the Business Method Interface pattern when using remote interfaces in enterprise applications. If the Remote interface class and the Bean implementation class respectively extend and implement a single POJI class, you end up with a robust mechanism wherein the POJI business interface defines the business functions while the Remote interface exposes them and the Bean class implements them. This approach prevents the natural disconnect between the business methods, the Remote EJB interface, and the implementation.
EJB 3.0, Spring, or Hibernate: Why Not All Three?
You have seen how you can leverage tools like Spring with the new EJB 3.0 component architecture. You've also seen how you can implement EJB 3.0 JPA using Hibernate and effectively integrate it with the EJB-based domain tier using Spring. EJB 3.0 by itself is a strong architecture that provides the features found in Spring and Hibernate, but now you have an alternative for circumstances that fit the need. Spring has a ways to go to fully support the EJB 3.0 architecture, which will make a few things discussed here easier. The Spring Pitchfork project is an encouraging step in that direction.