Project Apollo was born sometime during July of 1998 and was founded
by myself, Joe Kislo. I was
examining Java servlets as a viable platform for developing my future web
applications. I had previously used perl, perl with FastCGI, Python, and
finally Python with FastCGI. Servlets appeared to be architecturally
superior to all my previous programming environments, but still lacked from
a common weakness. Servlets although more sophisticated, still kicked you
out at the curb -- the doService() method. You were responsible for putting
some code behind that method, which made everything work. It became clear that servlets written at one
company, would end up looking -nothing- like servlets written at a different
company. No common framework existed. The first service written for
apollo was the session system replacement for the JSDK. When I was
examining the session system specified by the JSDK, and the first
implementation in the JWS, I found some serious limitations. The servlet
specifications were too lax on specifying a sessioning system which would be consistent
across servlet implementations. Also, it was geared mostly at
keeping sessions through the use of cookies. Cookies are something I have
never used, and it became clear that a consistant sessioning system was
needed, one which specifically catered to cookieless sessions, making them
easy, if not easier then cookie based sessions, with all the advantages of
avoiding the use of cookies.
Once the sessioning system was complete, the PageManager was built,
forming the backbone of the Apollo Framework.
In Fall of 1999, I embarked on my senior honors
thesis. Using the
existing apollo framework as a basis I proposed adding load distribution to
the framework. Using Java's Jini lookup service, Apollo would automatically locate
suitable nodes on the network for sustaining processing load, and
automatically move load to those systems. Jini's lookup services are highly
dynamic, and would allow suitable "RemoteNodes" to come and go as
often as they like. Once this was completed, any application written using
apollo's services could be instantly distributed, by simply activating the
Jini search module in the framework, and running RemoteNode software on
suitable machines. The initial theory was that web traffic is bursty,
bringing on new webservers cannot be done instantly, and the application cannot
suffer if a RemoteNode fails in any manner. Bringing on remote
nodes using Jini can be instantly achieved, and a single machine may act as
"spill over processing power" for multiple apollo applications. Imagine the case where your web application is
suddenly overloaded, and customers start complaining. You can in a matter
of minutes you can simply run the RemoteNode java program on any of your employee's
workstations. Employees can still continue to use their machine, browse
the web, use Microsoft Word, but the RemoteNode software will use their CPU
resources as necessary. If for some unthinkable reason their operating
system crashes, Apollo and Jini automatically compensates, and removes them
from the node pool without interruption of service. You could also imagine
the case where you are running a number of applications for different
clients. You could create a pool of servers which those applications could
draw resources from. Any one of those applications has the entire pool of
resources at it's disposal. If one client is particularly important, you
could possibly devote a single machine which only services requests for that
client. The project was a complete success and my final honors
project paper is available here. Included in that document is also a
lengthy discussion on
benchmarking particular JVMs, probably worth a good read.
I have now used Project Apollo's services in several web
applications, both for commercial production and private use. Project
Apollo has now been released publicly to the open source community, and can be
used to implement commercial and non-commercial web applications.
-jk
Joe Kislo ([email protected])