Migrating from EJB -> Spring

[jlindwall]

From reading Rod Johnson's books I am sold on the benefits of Spring. I'd like to take a medium-size application we've developed and migrate it to Spring but I'm struggling with the best approach to take.

The application consists of a dozen or so webapp screens and a remote java client application. We use a mixture of entity bean and homebrew JDBC wrappers for data access. The app is currently run under WebLogic 6.1 and makes use of a dozen stateless session beans and 25 entity beans. Other then the remotre client, the rest of the system is co-located. The system uses a single database so no JTA is required.

One goal is to eliminate the use of session beans **except for the stateless session bean that serves as the communications endpoint for the java client **.

I'd also like to eventually replace the entity beans and homebrew JDBC junk with something else: either Spring's JdbcTemplate or maybe hibernate.

With those changes in place I think we could run this app under a simple servlet container like tomcat, which would be cool. I can live with our struts-based webapp for now but I'd love to look at Spring's MVC webapp framework someday.

Where to start? I need to introduce a DAO layer for sure. I'd like the initial implementation to be the code currently in existence but using Spring's DataAccess exception heirarchy to hide the impl details.

Our session beans serve as the typical pointless "facade" of functions -- mainly the methods are data acess oriented, but some are pure business logic. The data access methods need to migrate into my new DataAccess layer. This will leave the existing session beans with just some business logic methods. Where to "migrate" these -- into POJOs?

I know this is a bit of a ramble. Do I sound like I'm at least in the neighborhood?

John

[wpoitras]

Sounds like you are on the right track. Try to break your business objects into interfaces. And try to think about them in those terms. Then implement them using POJOs and DAOs. This would be a great opportunity to start creating unit tests. With well defined interfaces, unit testing easier, especially since you can Mock your DAOs and test your business objects sans database.

You could even eliminate the EJB for the java client by switching to an HTTP based remoting protocol. If you program on the client using Spring and your business interface, switching between EJB, HTTP and straight RMI wouldn't require code change on the client, and very little on the server (since all 3 remoting strategies would still use the same POJO)

[jlindwall]

I would LOVE to have a suite of unit tests that I could run before, during, and after making this change to be able to know everything still works. We have a small number but it is very pitiful at present.

For our other (large, non-Spring) application we use Cactus and DBunit to help with "unit" testing (really integration testing in my mind) because our design is so poor. It was too daunting to separate the data access into a layer because it is sprinkled thoughout the codebase (in JSPs(!), servlets, domain objects, etc).

The Cactus/Dbunit stuff works well enough but the downside is the time it takes to run the tests.

Any advice/pointers for me on this smaller project for implementing quaity unit tests?

Thanks!

[wpoitras]

Adopting a test-driven development model is a good way. Basically as you refactor your objects, you implement your tests BEFORE you write your code. So you use the tests to create expectations for your objects, and then you implement them.

I would recommend finding some good resources on test driven development. Like www.testdriven.com. Can anyone suggest a good book?