head	1.6;
access;
symbols;
locks
	nobody:1.6; strict;
comment	@# @;


1.6
date	99.05.13.18.59.46;	author nobody;	state Exp;
branches;
next	1.5;

1.5
date	99.05.11.18.03.02;	author nobody;	state Exp;
branches;
next	1.4;

1.4
date	99.05.11.18.02.43;	author nobody;	state Exp;
branches;
next	1.3;

1.3
date	99.05.11.18.02.34;	author nobody;	state Exp;
branches;
next	1.2;

1.2
date	99.05.11.18.01.48;	author nobody;	state Exp;
branches;
next	1.1;

1.1
date	99.05.11.18.01.40;	author nobody;	state Exp;
branches;
next	;


desc
@null
@


1.6
log
@null
@
text
@IDependOn-Set: 1
IDependOn-Set: 119
IDependOn-Set: 140
IDependOn-Set: 151
IDependOn-Set: 159
IDependOn-Set: 2
LastModifiedSecs: 926445782
Parent: 119
SequenceNumber: 3
Title: Why are we using Java?
Part: 0
Author-Set: jon@@working-dogs.com
HideAttributions: 1
LastModifiedSecs: 926445782
Type: monospaced
Lines: 120
----------
From: Ari Halberstadt <ari@@shore.net>
To: "Java Apache Servlet List" <java-apache@@list.working-dogs.com>
Subject: Re: Reliability/Scalability
Date: Tue, May 11, 1999, 10:06 AM


Nicholas Tang <ntang@@rga.com>
>The rest of the members of the team, ie management and programmers are
>leaning fairly heavily towards IIS/ASP on NT and probably Oracle on
>Solaris for the db end.

Oracle/Solaris is ok, provided you have good DBAs to set it up and keep it
running. But ASP is, from what I hear from people, not a very good
solution. ASP is not portable, so you're pretty much tied to MS solutions.
It's slow because it's interpreted and uses COM; each request needs to
start up a whole new COM object--not very fast. It isn't particularly
scalable, partly because it's so slow. It's cumbersome to program in
because its interfaces aren't thought out. Anyway, this is what I've heard
of ASP.

>Personally, I'd much rather work on a project with Apache, but they were
>saying it's too hard to develop for and too slow (external cgi's vs.
>internal processes).  However, they do have some experience in using Java
>Servlets with Netscape's webserver.

Servlets are good because, provided you stick to pure Java APIs, you won't
be tied to any single web server. Let's say you spend one year and hundreds
of thousands of dollars developing software and business logic. A year
later it turns out your web server sucks. Well, with servlets you can pick
up and move to another server. So the specific choice of web server is not
nearly as important with portable solutions like servlets. There can be
other reasons to go with a specific server, but at least your investment in
custom software is not what binds you.

Java has other good things going for it. It's reasonably efficient. You can
get decent development tools to work with it. You can run code
analyzers/optimizers to figure out where things need to be tightened up
(e.g., optimizeit, jinsight), try doing that with perl or asp! Lots of
people can figure out its syntax. etc. etc. Just be sure to manage memory
reasonably well before blaming the JVM--a lot of performance problems are
caused by unnecessary object allocations.

>So, I thought - maybe the Java servlet thing and Apache would be
>acceptable to them.  It would give them the development environment that
>they're looking for and let me work with Apache - which I find both easier
>to administrate and also a lot more fun.

Java is very scalable. One of the lessons I learned was to have a very good
object/relational persistence layer. Whatever you do, do not start out
without getting a good mapping layer for your relational data model. (More
of my "lessons learned" are at
<http://www.magiccookie.com/computers/lessons.html>.)

>So what I'm looking for are answers, about the reliability and scalability
>of java servlets for Apache.  I'm also wondering if anyone out there has
>used them on their site (I'm looking for corporate/large scale websites
>please - while it'd be great to know 30,000 people are using them for
>their personal home pages, that isn't going to impress the suits) or of
>any sites (specifically large e-commerce sites) that use Apache JServ?

Can't help you here except to relate some things I've found with setting up
my own site. Of the things beyond my control: The database was the most
likely thing to crash on me, but this may be because I'm using a freebie
database and not a big thing like Oracle. The next thing to cause problems
were crashes in the JVM; this means using a transaction system to store
session data and having some way to quickly restart and/or failover to
another JVM. After that there were problems on my web host side.

Of the things that I could control, concurrency may be one of the hardest
to work with: everything ends up being multithreaded and you have to be
careful to avoid deadlock and concurrent modifications. It is a good idea
to have monitor scripts and/or threads that detect when something is stuck
and kill it off and restart it. You don't want your site stuck because of
some deadlock in a block of code. It is also helpful to use various
simplifying patterns to avoid synchronization issues (this is something I'm
still learning how to implement).

JServ uses a process that is separate from the server. This means that a
single server can talk to multiple JVMs and split load among them. There
has been some discussion and preliminary implementations of load balancing
approaches for Apache JServ.

>For that matter, does anyone know of any Apache-based technologies that
>are as easy and fast as ASP to whip together and that have been used for
>big e-commerce sites?  Maybe mod_perl or PHP or something...?

I think Sun's JSP variants, including GnuJSP and GSP, may be a good
solution. These let you embed Java code in your documents and let you make
calls to code that you have written and previously compiled into libraries.
When such a file is modified it is automatically recompiled into a .class
file which subsequently is run directly via the JVM to generate the output,
so the overhead of compilation is only incurred the first time a modified
source file is accessed.

With database servlets, the architecture should really be separated into a
presentation layer, a logic layer, and a database persistence layer. The
servlets do the presentation layer, which is kept as thin as possible,
basically just loading forms, validating input, calling the logic layer,
and returning display data. Your logic layer shouldn't know that it is
generating HTML or is part of a servlet, it should just take care of things
like managing users and purchases. The database layer should be a good
object/relational layer; there are a couple of good white papers on
object/relational requirements at <http://www.ambysoft.com>.

For a different perspective, you might take a look at Philip Greenspun's
endeavours at <http://www.photo.net/wtr>. His online book is especially
worth reading. Philip is an advocate of simple, lean software written using
TCL and AOLServer. There is a lot to be said of the rapidity with which he
can deploy a solution, as well as for his intelligence and ability to
analyze and distill his learned ideas. His approach is in contrast to the
OO/Java style that creates layer on layer of abstraction. Philip also does
not have much regard for Microsoft solutions; you can do a search on his
site, or see, for instance, the excellent Q&A forum on web/db issues which
has a recent thread on the reliability of Microsoft solutions. His book
also includes a section on selling a particular solution to the business
guys.

-- Ari Halberstadt mailto:ari@@shore.net <http://www.magiccookie.com/>
PGP public key available at <http://www.magiccookie.com/pgpkey.txt>
EndPart: 0
@


1.5
log
@null
@
text
@d5 1
@


1.4
log
@null
@
text
@d6 1
a6 1
LastModifiedSecs: 926445763
d8 1
a8 1
SequenceNumber: 2
d13 2
a14 1
LastModifiedSecs: 926445763
@


1.3
log
@null
@
text
@d6 1
a6 1
LastModifiedSecs: 926445753
d8 1
a8 1
SequenceNumber: 1
d10 126
@


1.2
log
@null
@
text
@d6 1
a6 1
LastModifiedSecs: 926445700
d8 2
a9 2
SequenceNumber: 0
Title: New Item
@


1.1
log
@null
@
text
@d3 1
@
