New web site design technologies??

[Srini Vasu]

Hi,
I have a small to medium range web based project(product) to design... I need your help to design the project using best, advanced practices in our Java community..
Here are the expected static's and environment of the project.
1) 100 concurrent users..possible increase in the long run..
2) 70 to 100 JSP pages for presentation possible increase..
3) Moderate user interaction with the forms (not so much complicated...)
3) Tomcat server, MySQL database, Linux environment.
4) NetBeans IDE with Java1.4 and Poseidon UML tool..
Would you guys please provide me some help in designing the system using latest Java technologies..since I am new in designing..
I have some ways in my mind using MVC..I wanted to use XML and Struts must be in any design... correct me if I am wrong..
1) Using Servlets, JSP, Struts, XML ... how feasible this way??
2) Using Servlets, JSP, Java Beans, XML
3) Using EJB, JSP, XML
any issues, pros,cons and online resouces will help!!
Thanks a bunch..
srini.

[Frank Carver]

This seems a strange request so far. I think you'll need to tell us a bit more before we can offer sensible advice.
On the one hand you seem to have made a lot of technical decisions (please explain how/why you have already chosen JSP, Tomcat, MySQL and NetBeans, for example).
On the other hand, you tell us nothing at all about what the application is actually supposed to do! For you or us to try and make any design decisions or offer advice without knowing what is being designed is a sure road to misunderstanding and probable failure.
All we know about the application so far is that it has a web interface. I'm guessing this means a HTTP interface, rather than applet(s). The only sensible way to "talk" HTTP from Java is using servlets, so your solution will likely involve one or more servlets.
How you produce your servlet(s) (hand written, or produced using code-generation tools such as JSP etc.), how you produce the HTML for the web pages (JSP, custom tags, templates, raw HTML in Java etc.), and how you manage the interaction between the HTML data and the "business logic" is still open.
I'm particularly worried that you seem to be leaping to potentially complex solutions (JSP, struts, XML, EJB etc.) with no evidence of need. I'm also having a hard time imagining a system that really has 70-100 entirely different kinds of pages and how you plan to make a usable, testable and maintainable application using this approach.
Please tell us more about why you have made the decisions you have so far, and some idea of what this application is for, in real customer terms. Thanks.

[Srini Vasu]

Originally posted by Frank Carver:

On the one hand you seem to have made a lot of technical decisions (please explain how/why you have already chosen JSP, Tomcat, MySQL and NetBeans, for example).

--> Because they are all free/open source..costs or less money

On the other hand, you tell us nothing at all about what the application is actually supposed to do! For you or us to try and make any design decisions or offer advice without knowing what is being designed is a sure road to misunderstanding and probable failure.

--> This is just Web application 100 or so concurrent users..may be less then.. not known at this time..

All we know about the application so far is that it has a web interface. I'm guessing this means a HTTP interface, rather than applet(s). The only sensible way to "talk" HTTP from Java is using servlets, so your solution will likely involve one or more servlets.

--> Yes, you are absolutely correct.. no applets..

How you produce your servlet(s) (hand written, or produced using code-generation tools such as JSP etc.), how you produce the HTML for the web pages (JSP, custom tags, templates, raw HTML in Java etc.), and how you manage the interaction between the HTML data and the "business logic" is still open.

--> 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.

I'm particularly worried that you seem to be leaping to potentially complex solutions (JSP, struts, XML, EJB etc.) with no evidence of need. I'm also having a hard time imagining a system that really has 70-100 entirely different kinds of pages and how you plan to make a usable, testable and maintainable application using this approach.

-->Yes you are correct... I might over stated the pages.. they might be around 50+ jsp's and htmls collectively..not sure though.. wanted to make jsp's as simple as possible..

Please tell us more about why you have made the decisions you have so far, and some idea of what this application is for, in real customer terms. Thanks.

--> 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... this is just a typical web site... not involed any critical data processing..just data retrieval to web page and data posting to database..not many concurrent hits..looking for portability for future migration to different database or different app server not yet known...can't able to give more specifics..This site is not for commercial usage though..hope this helps!!!
Give me some broad ideas for design standards..
Thanks.

[Ilja Preuss]

Originally posted by Srini Vasu:
On the one hand you seem to have made a lot of technical decisions (please explain how/why you have already chosen JSP, Tomcat, MySQL and NetBeans, for example).
--------------------------------------------------------------------------------

--> Because they are all free/open source..costs or less money

So are Velocity, Tapestry, Castor, HsqlDb, Eclipse and hundreds of other products...

This is just Web application 100 or so concurrent users..may be less then.. not known at this time..

And what will this application do?

[Frank Carver]

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 ]