Hey Guys - I have a few questions/request for feedback - this covers a few areas (solution design/architecture as well as application environment) and I was hoping to get your feedback on any/all of the areas below that you can comment on.
Current solution described is (back to front)
DB2 Database -> J2EE DAOs (using jdbc) -> EJB 3.0 running on WAS -> POJO (serialized object layer used to communicate front vs. back) -> Struts 2.0 based Front End -> JSP/JQuery
The front end manipluates the POJOs and then sends them back to the EJB for mapping into the DTO for CRUD
Most back-end EAR projects have a LookupBean (searching/find by id etc.) and a MaintenanceBean (CRUD operations)
I guess the meat of the post is we are trying to move toward a modernized architecture and have a few questions:
1. Should we be replacing Struts with Spring - current understanding is Spring is more robust vs. Struts being more stable. Concern is that most of the analysis I've read is that Spring adoption is much higher vs. Struts that seems like it will reach an end-of-life soon.
2. Would like to move to a new app server and assuming we do NOT need to support EJBs moving forward, what is our best option. Currently evaluating JBoss vs. Tomcat (would hope to be able to have some form of enterprise support if possible)
3. Would like to move the backend to a service based approach. Would RESTFul or SOAP based services be optimal. Current understanding is that RESTFul is quicker, more robust and less secure where as SOAP based is noted as being heavier because of the nature of XML vs JSON but more secure.
4. Should we move toward an ORM (hibernate) backend to replace the DAO pattern - currently the DAO pattern has been working pretty well for us and allows us to write robust SQL where necessary
5. WAS Replacement - seems like we are only leveraging a small piece of what WAS has to offer (dynacache that I know for sure JBoss has an acceptable replacement) - or move toward tomcat - or are there any others that are similar that offer a high level of functionality with enterprise support.
5. POJO Layer - would like to keep the POJO layer for the front end only because it allows us to mock up data for wireframing/prototyping before the persistence/new service layer is designed.
6. Not as important but may be looking to move toward a new DB (Oracle/MySQL/SQL Server) over DB2 - any comments here would be appreciated as well.
7. Re-use - currently there is a good amount of re-use between applications, simple example - each library would be able to look up books from a centralized separate master catalog of books to get all book info and the library would only store book ID in their catalog.
Hopefully this is clear and enough info - please let me know, I would be happy to answer any additional questions.
I won't comment on specifics since you don't give enough detail for me to make recommendations one way or another. I will, however, share my opinions about "re-architecting" efforts in general.
1. You want to do it slowly and surely
2. To move forward surely, you need to have lots of tests. Automated tests.
3. To have lots of tests, your code needs to be well factored. Very well factored. The risk involved in making changes is inversely proportional to the number of tests you have that can tell you when you've messed something up.
4. Decide on what your focus will be. Messing around with architecture just so you can use more up-to-date technology is not a good enough reason if the application is working fine and delivering value as it is intended to right now. There has to be a more compelling reason to change. Are you finding it difficult to make additions or enhancements? Are there bugs that the architecture makes difficult or impossible to fix? Are there significant gains/savings achieved from making the change? What is/are your compelling reason(s) to change the architecture?
Matthew M. Walton wrote:3. Would like to move the backend to a service based approach. Would RESTFul or SOAP based services be optimal. Current understanding is that RESTFul is quicker, more robust and less secure where as SOAP based is noted as being heavier because of the nature of XML vs JSON but more secure.
I would not necessarily rely on those generalizations to make a decision. What do you mean exactly by one being "quicker" than the other? Quicker in terms of what? Performance? Rate of adoption? Development? Change? Can you cite any references to support the assertion that REST is less secure than SOAP? IMO, neither is inherently more or less secure than the other -- they just have different requirements and technical challenges when it comes to security. It really comes down to context and justifying the costs vs benefits of implementing an acceptable and appropriate level of security measures with either REST or SOAP. Search for Security in REST vs SOAP
There are many reasons for choosing one over the other but the decision should be based on the context and the constraints you have to work with. Each will come with its own distinct set of advantages and disadvantages and it's up to the architect/developer to figure out which ones apply in a given context. Search for articles on choosing between REST and SOAP
The best ideas are the crazy ones. If you have a crazy idea and it works, it's really valuable.—Kent Beck