Recommendations... JavaServer Faces (JSF), Struts, model2, other

Question

We are looking at reworking a java business management web service that has been in use for over 4 years now. The software's internal architecture has been all custom built and with a bad separation of of the presentation layer and business logic. As well the overall model layer has proven it can't effectively keep up with changing business logic and needs refactored. As I am planning out this task I have been looking at available frameworks that I could leverage to make the application more friendly to new developers hired on and changing business logic. I have never used struts or JSF before but read up on them in a somewhat brief and overview method and at first glance am not overly impressed by either, however I find JSF more intriguing.

First Both Frameworks seem to focus on the Controller and View portions of the MVC pattern. Leaving you to do whatever on the model/business layer. (am I correct?)

With the rework we want to be able to employ outside contractors to help expedite the rework so finding a unified development methodology is important to insure quality of code and decrease inconsistencies and ramp-up times.

So what recommendation would you have on frameworks, practices, etc that might help this effort. I really don't want to reinvent the wheel with a custom framework and find us in a similar situation later.

Answer 1

There are a couple of things you should think about when undertaking this approach:

1. Your specific needs vs. the focus of a particular framework
2. Availability of coders who know the framework (in-house and on the market)
3. Learning curve for the framework, and the level of its acceptance & support in the broader community of developers.

Many people speak highly of Spring MVC, though if IOC is new to you (or you don't buy the concept) this may be a bit more than you want to bite off "all at once."

Another well established option is Struts (though I'd strongly suggest Struts 2 for new development).

One thing to be wary of is the size & scope of a "framework transplant" operation. If your app is in dire need of serious structural reorganization, it's quite likely you could end up basically starting from scratch and hanging chunks of your existing business logic off of a skeleton built upon framework. The time/money/resources (and opportunity cost!) should not be underestimated, and you should be certain management really buys off so you don't get the plug pulled on you halfway through. It's really really important to "measure thrice and cut once" here, and make sure you're biting off a chunk of work you can chew -- going from "legacy app" to "brand new state of the art app using all new technologies" is frankly best done in stages, rather than all at once.

It would be helpful to understand the size & relative complexity of the application as well as it's basic nature (is it a very web-UI intensive app, or a back office system which does lots of jobs?) in order to make better suggestions about particular frameworks: though you could certainly build most webapps on any given framework, some are slanted more heavily in one direction than another (e.g., Struts and Wicket have a pretty different focus)

Additionally, there's nothing wrong with trying a couple candidate platforms alongside your existing application. Though I know nothing about your current app's technology backplane, unless you've done something really strange it's likely quite possible to install one or more frameworks and experiment with them alongside your existing app (e.g., write new features against them, or rewrite portions of existing code using them, then hook that code into the backend). This will let you experiment and "try before you buy". I'd suggest having your team give this a whirl on one or more "short list" framework candidates to get the feel for how it'll work in practice. This is, incidentally, not a terrible way to approach refactoring: gradually replace old functionality with your new framework.

Final (I think) piece of advice: look long & hard at your datamodel and the interfaces thereto. That's typically going to be where the real gremlins are, and regardless of framework you want to get that right. I'd strongly consider making that your #1 refactoring target, rather than the adoption of a particular framework. A strong datamodel is going to make implementing ANY framework (and handling upgrades) much easier...and should your management change directions on you and end up delaying the framework upgrade for whatever reason, time spent refactoring the data model will pay off.

EDIT:

Given your comments about the shape of the product, I'd double-down on the "be very, very careful" advice. The spot you're in now is very common (and notorious) and has eaten many teams (and careers) alive. You need strong understanding & support from stakeholders up the chain and on the business side as this is going to be a hugh undertaking which will, by nature, take longer & cost more than you imagine. The technical team's ability to be clear-eyed and realistic about the cost + scope of the changes here is CRUCIAL to success -- if you underestimate significantly you're jeopardizing budget, careers, and potentially the business itself. If you overestimate, you may never get to start :)

One approach, once you have strong buy-in and support from management, is to really treat this as a whole new product -- put the old stuff on maintenance, roll up your sleeves, and start designing the replacement system with all the knowledge you've gained in the previous implementation. In that case, I'd work out the component and data interactions sans-framework, then look at how a given set of candidate frameworks would support that implementation. Starting with the framework may lead you to unnatural places, and could land you back in a similar spot down the road.

Some well-known popular frameworks to check out:

Struts2 - MVC /w AJAX support

Wicket - AJAX heavy

Struts1 - Granddaddy of pretty much all Java frameworks; worth a look

Spring MVC - Spring's IOC webframework

Answer 2

If you liked JSF and want to use it, I would recommend the use of JBoss Seam. You can also use Spring, but I think that using JBoss Seam makes the use of JSF much easier. I am using it for almost 1 year now with good results. And if you want to modelate your process as a business process you can try JBPM (along with Seam).

If you want to know more about agile methodologies so you can improve both your methodologies and practices, take a look first on the agile manifesto http://agilemanifesto.org/ . And then start trying established methodologies like XP or Scrum.

But take your time, start trying one change than another not to confuse yourself

Answer 3

JSF allows you to focus on components, while JSP based solutions don't as well, or as much. You'll still find yourself coding a lot of jsp'ized html stuff, while with JSF solutions, you really don't need to. Look at RichFaces or IceFaces as libs. RichFaces makes it trivially easy to do AJAX type stuff. Just add the tag <a4j:support event="onkeyup" reRender="output"/> to your standard JSF control. In the example above, on the keyup event for the control, it will rerender an area <a4j:region , or another JSF, Richfaces tag. Nothing simpler.