We have a main business data object that is currently delivered via an EJB-based service to the front end applications. I'll call it a business DTO
Multiple applications use this main business DTO to perform their individual funtion; such as monthly reports, scenario generation, etc...
The business DTO contains hundreds of points of data, and is growing all of the time as more functionality from legacy systems is asked to be exposed on the web interface.
The problem comes in each time that a new piece of data is added to the business DTO. First the EJB service and all of its artifacts has to be rebuilt. Then, all applications that use that business data object must be rebuilt and regression tested... If not, they fail to deserialize the newest version of the business DTO.
I have been tasked with cleaning this up and converting the EJB-based service to a Spring service.
Would using an interface help clean this up? Can I develop an interface that has getters/setters for the current data set, and then when the business DTO changes, the implementation object will change, but the interface will remain stable until each individual application needs to be updated and recompiled, then it will get the latest version of the interface, and the new implementation.
Of one note, we are using Websphere and are currently stuck using Java 1.4 for reasons that are out of my control, so upgrading is not an option currently.
Should I be doing this Spring service in Spring HTTPInvoker, or would I be better off using Spring-WS and a contract-first web service?
Any advice would be appreciated.
Joined: Feb 24, 2009
Does anyone ever answer anything on Java Ranch? Third time I've posted, not one reply.
Am I doing something wrong?
Any suggestions on a forum to use where one might get some replies?
subject: Using Interface in converting from EJB to Spring - Best Strategy?