Migrating from EJB3 to Spring, Hibernate

We have a desktop based application based upon EJB3, Oracle 10 and JBoss 4. This was created around three years back. JPA entities were used for ORM and the business logic was implemented in the Stateless Session beans. The client was developed using Swing API.

Now there is a requirement to replace the previous technology with Spring, Hibernate and JBoss for the next release of application. Client will still be in Swing. The plan is to replace the entities with POJOs and put the business logic from Session Beans to Spring Beans i.e. Data Access Objects (which extend HibernateDaoSupport).

So the question is, is it possible that we completely free our application from Session Beans and move the business logic to Spring Dao? Or do we still have to keep the Session Beans? If Session Beans are compl开发者_如何学Goetely avoided, how will the client application be able to access the business methods? Like in case of JavaEE based app, the session beans were accessible through Jndi lookup.

Any suggestion are greatly appreciated.

This is completely possible, in fact these technologies aren't that different. To get immediately started, try this:

<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 SLSB are now prototype Spring beans. If some SLSBs have state (duh!), you will have to wrap them in pooling proxy and there is much more to be done. But Spring already supports majority of EE features. For instance at the beginning stick with JPA and Hibernate backend - no changes in the DAO code required, @EntityManger can be injected the same way to Spring beans.

Also in the meantime you can mix Spring and EJB - EJBs can be easily injected to Spring beans, providing nice interoperability.

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

If you are migrating a perfectly fine EJB3/JPA application to Spring/Hibernate just because you think the end result will be more lightweight, then IMHO you're doing it for the wrong reasons and you may be looking at wasting a massive amount of engineering effort.

Spring and EJB3 are both fairly similar. Spring was historically more heavyweight in the XML department, but it now follows EJB3's annotation based approach more closely. In general, the two seem be in a bunny hopping contest. Sometimes Spring innovates and is one hop ahead, but then EJB3 innovates and is one hop again. Both constantly base their features on that of the other.

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

P.s. if you already had a perfectly fine working Spring application, I would also not advice migrating to EJB3 just for becomming more lightweight.

Spring beans are not only "DAOs", you can also have "services" to implement business logic (see http://biese.wordpress.com/2007/10/08/service-layer-and-dao-architecture/).

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