Because they are all free/open source..costs or less money As Ilja pointed out, there are a lot of free software tools and frameworks. By all means make the decision to use only free software (I often work this way myself), but it is important to choose an
appropriate selection of free software.
In particular, using JSP costs the same (in cash terms) as
not using JSP, using Struts costs the same as
not using Struts, and so on. Before you finalize any technology decisions like these, I would really expect to see some evidence that you have seriously considered whether you really need them.
This is just Web application 100 or so concurrent users..may be less then..
not known at this time.. With web applications it's important to distinguish between "concurrent sessions" (usually only affects memory use) and "concurrent access" (affects CPU and network loading). JavaRanch is a pretty busy site, but even so we typically only have one or two atcual page accesses going on at any time. Most of a user's time is spent reading returned pages or composing replies in the browser.
Servlets are going to be hand written.. for the web pages I will be using JSP's.
I wanted to use the Conroller Servlet to call the appropriate class/bean to make the
data base calls. You seem to ave already decided to use JSP (in particular a "model 2" approach), but I feel that you are still just making assumptions rather than actually designing a solution to fit the real needs of the application. Sure, JSP is
one solution to the problem of dynamically generating HTML pages, but it's not the only one, and it has its drawbacks like any other technical decision.
they might be around 50+ jsp's and htmls collectively..not sure though.. I would strongly suggest that you spend some time understanding what is needed before trying to make wide-reaching design choices like this. Note that I'm not suggesting that you design the whole application before starting coding, rather that you find out "just enough" solid information about what is needed so you can try out alternative approaches before locking your whole project to a particular design choice.
wanted to make jsp's as simple as possible.. The simplest JSPs are ones with no dynamic behaviour, and those should be static web pages! An important part of designing a web application is minimising the amount of processing needed for each page.
I haven't made decision so far.. wanted to use struts (advanced tech..)...to reduce more scriplets in the jsp and make use of JSTL... I'm sorry if I misunderstood you. It certainly sounds as if you have already decided on JSP.
this is just a typical web site... not involed any critical data processing..just data retrieval to web page and data posting to database Ah, this is more useful. Am I right in assuming that your application just does basic CRUD (Create, Retrieve, Update, Delete) operations on one or more database tables. If so I'd expect to see more like four dynamic pages, rather than the tens or hundreds you seem to feel are needed. Can you explain a little more how these other pages might differ and what different operations they might represent?
looking for portability for future migration to different database or different app server not yet known. The best way to achieve portability to an unknown future is to design and build the smallest, simplest, and best factored solution you can. If every design decision is represented in just one place in your code, it is as easy to change as it will ever be.
You can generally encourage database portability by sticking to plain, simple, SQL through
JDBC, not using stored procedures, triggers or other database-specific behaviour, and not mixing persistence and business processing in the same objects.
Give me some broad ideas for design standards.. In the broadest terms, the best design is the one which is most appropriate to the needs of the application
right now. Every un-needed line of code put in "for the future", is one more line to maintain, one more to document, one more to debug, one more to
test, etc. etc. A simpler solution is smaller, easier to understand, easier to get right, quicker to deploy and probably faster in execution.
So: Understand your requirement and build a solution to the needs you really have now, not to problems you only
guess may crop up later. Build the simplest solution you can. Don't choose technologies just because they get a lot of press. Don't lock yourself in to specific features or frameworks until/unless you really have to.
[ March 03, 2003: Message edited by: Frank Carver ]
