I actually don't use either. I guess my version is closest to Service-To-Worker, though. My
servlets act as both controller/dispatcher.
As a rule of thumb, I put all domain objects that do processing (algorithms, database access, remote connections, rule parsing) in stand-alone
java classes, and ONLY the controller knows about them. I post to servlets, they package the parameters and ship 'em off to the domain. When the domain returns with results, I then figure out which view to show or if I need to report an error. I just take the result data, package it into the request using setAttribute(), then forward to the
JSP view that extracts the data and displays it. The way I do it, the data doesn't have to be a JavaBean (Helper). More commonly I'll have Hashtables or Lists of Hashtables (each hash in the List representing a 'row' of data). This allows me to change the data format without requiring the JSP to recompile because I've changed a bean class.
Once the view has the data, I have no problem using custom tags/taglibs to do view processing (such as text formatting, table-ization, color-ization, etc), but at that point I disallow any and all domain processing. This way I can rewrite my view without affecting any domain processing activity. This increases robustness and debuggability.
Part of the reason I let the domain objects handle all the processing and responsibility is that the separation allows for much more flexibility, but I also think it's better perfomance-wise. Using JSPs and taglibs adds overhead that I'd rather not incur. Also, you can ship your domain off to an app server, or split it out into multiple app servers and let your controller servlets or other mechanism farm out the work in a balanced way.
My recommendation is to figure out what you like best by trying both out! Or try mine! :-) I've a big believer in throwaway
test prototypes as a learning tool. You can simulate database and remote system interaction and figure out how the patterns really work without dealing with setup issues.
To finish up, I'm against content retrieval from JSPs. It's plain awkward and it's difficult to do many of the things you can do in plain java, like use inheritance and interfaces, unless you stick it all in taglibs, but that's actually more work than writing plain java, and more difficult to debug! JSPs are horrible when you're trying to debug anything. BTW, whenever you start your project, make logging and error-handling a BIG priority! Here's one last thought - if you put all your processing in plain java classes, you can use the same code to serve not just servlets, but
applets, applications, or other remote services! Anyway, I like to keep things simple and flexible, so avoid undue complexity!
Good luck, and let us know what your research leads you to!