Slashdot Mirror

← Back to Stories (view on slashdot.org)

Apache's Jakarta-Tomcat Server Explained

Posted by Hemos on from the looking-under-the-hood dept.

Ellen writes "Apache's Jakarta-Tomcat server is an open source, Java-based Web application container that was created to run Servlet and JavaServer Page (JSP) web applications. In O'Reilly Network's "Using Tomcat" series, author James Goodwill previously has explained how to install and configure Tomcat. His latest article provides in-depth information about how to deploy it. Read "Deploying Web Appliactions to Tomcat"

1 of 91 comments (clear)

  1. JSP & Servlets are only part of the problem by macpeep · · Score: 5

    When I read about PHP vs. Perl vs. Java or in this case, about Java servlet & JSP engines, it really bothers me that so many people totally miss the point.

    How you embed a couple of variables into the HTML is a complete non-issue. PHP, Perl, JSP, servlets, ASP, they are all fast ENOUGH and in all of those, it's easy enough for anyone to do. It's completely irrelevant anyway if the response time is 0.1 or 0.3 seconds, even if that's a 3x difference. Even if one technology would mean you have to get 3 servers instead of just one, hardware is so much cheaper than developer time that it's still worth it. There are *major* sites running all of those technologies I mentioned above, which is proof enough that they all scale and the fact that there are supporters for each also proves that for different people, different technologies are differently suitable.

    The real "problem" is how to separate logic well into "something else" and have that "something else" communicate to the front end layer (the ASP, JSP, PHP, Perl etc.) the results so that you don't end up with a back filled with HTML where you should only have logic. Also, how does that back end scale *conceptually* as the application grows more complex? Is it a pile of spaghetti code or does the technology / language promote good design? How does it integrate with existing systems and databases?

    100 line "benchmarks" don't answer those questions and the myriad of clueless Slashdot posts from people who have never actually done anything more than a "hello world" will also not answer the questions.

    Now here comes the controvercial part; in my experience, Java is miles ahead of the rest (ASP + COM is about on par if you are working on something that just has to run on an NT server) when it comes to real world application development. The main reason is that the front end and back end communication is so great. JSP is clearly a better model than servlets as the front end should be as purely HTML as possible. The fact that JSP allows you to make up your own tags and map them to Java code also makes it really easy to do more complex stuff - all tag based (this is why Cold Fusion is so popular among non-techies).

    Still, JSP compiles into Java servlets, which is a great model from a programmer point of view (one instance, one thread per request etc.) so you get the best of both worlds - clean HTML and a great programming model. Also, since a Java servlet is a normal Java class, your can build an application out of it really easily and use all the stuff you would normally use - EJB, Corba, RMI, JDBC, etc.

    The object oriented (sorry, object based) nature of Java also promotes good application design so that you don't end up with a huge "MyPortal.cgi" Perl script with 50000 lines of code and HTML, all mixed up into one big mess.

    That Java is "running" and that only new threads are created for the requests also gives you the benefit that you can do things like caching in-memory between requests etc. really easily. This again makes it possible to employ all kinds of techniques for speeding up sites, bypassing database queries for often-requested stuff etc.

    This is just my point of view though. I'm sure others consider Perl a better alternative and have a lot of reasons to back it up. I'm sure they can list a lot of technologies that I didn't know of (Perl related I mean) that lets them do basically the same things that I just described above. This doesn't bother me at all - quit the opposite. What bothers me is that Slashdot (and IBM) posts idiot stories about "comparisons" that don't mean anything since the real problem is not in the front end.

    That's all.. My rant is over.. :)