Migrating from EJB3 to Spring, Hibernate

Question

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 completely 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.

Belcher

Answer 1

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.

Airplane

@Tomasz: Thanks for the clarification. One more thing, once the session beans are converted into Spring Beans, how can my client application access the methods of the Spring Beans? In my previous application, all the session beans had Remote and Local interfaces which were called through Jndi lookup. What should i do in the new scenario? – Belcher

You can either stick with RMI (remote EJBs style) and use Spring remoting support to expose POJOs in RMI registry or use other technology like Hessian, SOAP/REST, Spring remoting, etc. Also see my update to the original answer. – Airplane

Reason behind moving to Spring & Hibernate is the that it is considered a light weight architecture. We are still exploring the options and checking how much of a performance boost we can get by replacing JavaEE with Spring + Hibernate. If however, there is not much difference than will stick with JavaEE. – Belcher

I don't think Spring & Hibernate is more lightweight than Java EE. JPA -is- often Hibernate, and Spring only markets itself as being lightweight, but has consistently failed to clearly define what lightweight exactly means. Whatever lightweight means, in practice I found EJB easier to program for. Performance depends more on your own algorithms and architecture than the difference between Java EE and Spring. Mostly I'm able to create better performing Java EE applications, but that's mainly because I know Java EE a lot better than I know Spring. – Ecg

Why the downvote? I never said Spring/Hibernate are more lightweight than Java EE... – Airplane

Answer 2

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.

Hardej

I strongly disagree... The class-loading, security, transaction management and so many other departments, Spring is very light-weight as compared to EJBs.. Specially, the testing domain, EJB does not even come closer to Spring. – Kahn

Answer 3

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).

Billybillycock

I do plan to have services in the new application i.e. one service for a group of related Spring DAOs.. just like one session bean for a group of related entities. These services are then added as beans in the application context file. But still my confusion lies is that how my client application can access the methods of these services? – Belcher

Maybe you should tell me what is not clear in "Services will be dependency injected in the presentation layer. If you need RMI between presentation layer, and business layer, you should use Spring Remoting static.springsource.org/spring/docs/2.5.x/reference/… (with RMI)." – Billybillycock

Thanks for the info. I understand the Spring Remoting option.. I am just about to start working on this new application and want to be absolutely sure the framework I select is the most suitable. In your experience, for a desktop based client server application, what do you advice would be better.. JavaEE or Spring + Hibernate + Spring Remoting? My understanding is that Spring is light weight if its a web application because we can avoid application server and go for a webserver like tomcat.. but if its a desktop based app.. then is it just a matter of personal preference? – Belcher

Spring can be seen as "javaEE without EJB". Since 2004, Spring is far more popular than EJB. I tend to choose the most popular tool, what ever my preference is (because you will find more examples, more documentation, and you will get more help). see google.com/insights/search/… – Billybillycock