Kirt's got it. There's nothing wrong with JSPs per se, but you really need to use them only as the view, not as the controller and logic/data. Look up Model 2 MVC (model-view-controller) on google, and take a look at
Struts (apache-jakarta). The idea is that all data is posted to servlets that call out helpers or EJBs to do stuff with the data and maintain state, then the servlets forward to JSPs to display pages based on the application state, data just entered, or a scripted process require ordered steps. One servlet can handle multiple JSPs that post to it if one dataset needs to be built over multiple screens. Just don't store the data in the Servlet - put it into a helper object that resides in the session and updated it as each new set of data arrives. The Servlet essentially becomes the script that glues the GUI (HTML) to the logic/data back-end.
This type of scenario happens all the time and it's pretty much accepted as the current 'best practice'. I don't think anyone should post to JSPs, so if your tech team is recommending that, they haven't done their homework. Ask them about MVS and which model they intend to use.
Also, make sure you be careful with when to use EJBs and what types to use. Not every session bean needs to be stateful, sometimes CMP is better than BMP, and vice-versa. Message beans require rigorous design for asnychronous usage. And not all database calls must use an EJB. I'm working on two J2EE projects right now and neither has any requirements that would lead us to use EJBs - hardly any transactions that aren't inside the database as stored procedures already, no need for distribution since there's only one server, and the data is always different so caching doesn't help us. I forsee a future project that will definitely need EJBs, but they aren't a cure-all and can actually complicate matters. I recommend a mixed approach if you need them, especially if scalability matters and you have limited hardware resources.
Good luck on your project!