Migrating from EJB3 to Spring, Hibernate

Question

We have a desktop application based on EJB3, Oracle 10 and JBoss 4. It was created about three years ago. JPA objects were used for ORM, and business logic is implemented in a session with no state beans. The client was developed using the Swing API.

There is now a requirement to replace previous Spring, Hibernate, and JBoss technologies for the next version of the application. The client will still be in Swing. The plan is to replace POJOs and port business logic from Beans to Spring Beans, that is, data access objects (which extend HibernateDaoSupport).

So the question is, is it possible to completely free our application from Session Beans and move the business logic to Spring Dao? Or do we still need to save a Beans session? If the Beans session is completely ruled out, how can the client application access business methods? As with a JavaEE-based application, a Beans session was available through a Jndi search.

Any suggestion is welcome.

Answer 1

If you are transferring an absolutely wonderful EJB3 / JPA application to Spring / Hibernate just because you think the end result will be easier, then IMHO you are doing this for the wrong reasons, and you can look at the wastefulness of a huge amount of engineering effort.

Spring and EJB3 are both pretty similar. Spring has historically been heavier in the XML division, but now it comes closer to the approach based on EJB3 annotations. All in all, these two seem to be participating in rabbit jumping competitions. Sometimes Spring innovation and one step forward, but then EJB3 innovation and again one leap. Both constantly base their functions on others.

Instead of switching to Spring, I would suggest upgrading your server from JBoss AS 4 to 6, or if you can wait, wait a couple of months and go straight to JBoss AS 7.

Ps If you already have a perfectly working Spring application, I would also not recommend switching to EJB3 just to become easier.

Answer 2

This is quite possible, because these technologies are not so different. To get started right away, try the following:

<context:component-scan base-package="com.example.project" scope-resolver="org.springframework.context.annotation.Jsr330ScopeMetadataResolver"> <context:include-filter type="annotation" expression="javax.ejb.Stateless"/> </context:component-scan> 

Snap! Now all your SLSBs are now a prototype of Spring beans. If some SLSBs have a state (duh!), You will have to wrap them in a proxy pool, and much more needs to be done. But Spring already supports most of the EE features. For example, at the beginning, stick to the JPA and Hibernate backend - no changes to the DAO code are required, @EntityManger can be introduced in the same way as Spring beans.

In addition, you can mix Spring, and EJB - EJB can be easily injected into Spring beans, providing good interoperability.

UPDATE Also, why do you want to downgrade from JPA do Hibernate? If your application works fine with JPA, use it also in your Spring application - and when you need Hibernate special features, you can still use them.

Answer 3

Spring beans are not only “DAO”, you can also have “services” for implementing business logic (see http://biese.wordpress.com/2007/10/08/service-layer-and-dao-architecture/ )

Services will be dependent introduced at the presentation level. If you need RMI between the presentation layer and the business layer, you should use Spring Remoting http://static.springsource.org/spring/docs/2.5.x/reference/remoting.html (with RMI).