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])