Web App


Provide a community-building on-line information exchange. This will take the form of dynamically generated web pages that are presented in a heirarchical manner. User information is tracked by the system and acts in a feedback loop to constantly change how the pages are presented to the user (such that user preferences, activities, and the activities of similar users modify the information presentation).

The site presents information blocks in the form of user-generated bulletins, live chat sessions, polls and elections, hypertext links, and option settings. The ordering of these is defined by the user, as is the user's own rating of these materials.


The system must be able to provide, at a minimum:

Data Requirements

There are a variety of data sources and repositories that are needed.

Data Sources

Data Repositories

These are general descriptions, not the detailed data definitions. It is important to note that very few data respositories are actually defined by the app engine; rather, most repositories are defined by the information block modules.

Process Details


Recommended roles

Each role in this list inherits all the characteristics of less powerful roles except for the "sign up" right. This is not imply a role heirarchy. Roles are to be individually set up and not arranged in a heirarchy.

Category relationships

The top level category defines universals that are legal through all lower level categories. Below that level, however, category roles or definitions do not inherit or propogate to lower levels.

An information block may belong to only one category.

User tracking

Information Blocks

Information blocks can be nested. If the author of an information block is online and in this category, that information (if author is chat-ok) will be noted.

Information blocks will not appear for a user if they do not have rights to view the block.

The appearance of an information block is determined by XML stored within the database. This contains layout hints as well as definitions of nested information blocks and default values or form field data substitutions.

Each information block has a unique ID that allows it to be referenced from other information blocks and from a URL. This allows it to be linked to from outside sources, bookmarked in a traditional fashion, as well as being linked into other blocks by editors.

Distinguishing types of information blocks

Information blocks may be of almost any type. However, some have repurcussions (polls, elections, etc.) that act beyond simple data storage. In particular, voting and polling have special rights that are coded in. To allow special rights to appear, information blocks have an interface that let the system recognize that special permissions are in place.

Installation information blocks

Information blocks may need new data columns or tables added to the database. They should only impact existing tables by adding rows or adding new tables. In no case, except major version changes, should information blocks delete columns or tables. Prior to adding the new information block to the server, the database should be modified.

Anticipated information blocks

Service Level

Any individual page request should take no more than 1.75 seconds to complete. Up to 50 page requests per second should be able to generated per server.

This system is scalable by distributing the load across several tiers. Tiers identified at this point include:

A strongly object-relational database may imply dropping, changing the location, or modifying the object-relational mapping layer.

Achieving a highly responsive system can happen via precaching requests. User recommendations across all categories are compiled when (a) a user logs in and no current recommendations exist or (b) 20 minutes after the last recommendations were compiled. This is achieved via a recommendation builder queue. The timeout is tunable by administrators.

Additionally, for security and convenience, the system will default to a 20 minute idle timeout, at the end of which the next page load will require a reauthentication. This time can be changed to any number minutes, with 0 indicating no timeout.

End-user interface

The end user will interact with this system via a combination of HTML, Java applets, and frames through a web browser.

The system must be capable of being almost entirely maintained via a web browser. The only activities not possible through a web browser are limited to:

Recommended Platforms

Because this is to be an open source project, is has the potential of working on any system. To speed development, the following are recommended:

Areas of investigation

These need to be investigated before making any final decisions on platform and supporting systems:

Engine Program Flow

Consider that the engine is broken into several discrete layers or components:

Servlet specifics

Assuming that we extend javax.servlet.HttpServlet, we don't have to implement the service method. Rather, we implement doGet, doPost, etc. This is easier, but is this faster? Additionally, is it faster or better to run a single-threaded servlet model, or the multiple threaded servlet model? I don't think the performance hit is so big, and I think this lets us handle more "simultaneous" connections than if we tried to handle all these (with spawning threads) from the servlet service method.

Will servlets execute faster if we define a set of static class methods, or if the classes are normal and handled by the VM?

A set of servlet utilities will need to be defined that will give "helper" functionality:

Module Theory

Objects can have fields and methods that can be modified or supplanted by module fields and methods.

To accomplish this, a solution needs to be found. I haven't figured it out yet, but some ideas include:

Design Patterns hasn't provided a lot of guidance to this point, beyond using Decorators to encapsulate the functionality. This isn't appropriate, as I would like to be able to modify behavior in a global namespace.

Module Signature

module(String id, Session session, Dictionary form)

Utility Classes

Engine Design

General process/design. The static engine starts in the VM and initializes pools of servlet handlers
  1. Question: how to make a class start up with the VM started by JServ?
  2. Utilizes a thread pool to hold threads for connections from JServ.
  3. Creates a new engine for the thread with Engine.create(threadpool.getThread(), servlet environment) [probably from the servlet start method]

Engine Data Dictionary

Context: Engine

Database Manager

The Database Manager (DBM) encapsulates the tier that seperates the modular program from the database back end. It consists of a Database Interface and JDBC connection to a database and provides JDBC connection pooling and connection thread pooling to increase speed when sending queries.

Todo: How do I deal with multiple database ids and logins with the following model?

Design Patterns

The DBM uses two thread pools: a JDBC connection pool and a servlet connection pool. The DBM is a Facade for JDBC and the database. The XML query/update and result/result-set dtds provide a Facade for SQL and result/result-sets respectively.

Note: the caller doesn't need to pick up a result, though one will always be returned, even in an error case.

Suggested DBM Classes

Shutting down the Database Manager

Starting the DBM is covered in the DBM Thread Model. Stopping threads involves:

Database Interface

The Database Interface (DBI) is the process that converts XML queries to SQL and back into XML results. This is embedded in the client communication thread and takes the form of:

Please see the DBM thread model for details of execution and hints for implementation.

The DBM Thread Model

thread init/constructor wait parse execute convert return to client wait
main build client & connection pools (entry point) wait for client get client thread (connect to client)  
check check client pool/check conn pool (repeat)  
client create   XML to SQL get SQL connection result to XML return XML to client close connection/return to pool
conn create/connect   execute/wait get result return to pool  
client   connect call query wait for result got XML result close DBM connection

XML dtd design

In general, XML variables can reference forms, session info, object references, database record ids, etc. Special XML types defined should include:

Semiformal definition:

(fundamental classes--I don't believe we will actually implement this)

Escaping Characters: Use the syntax '\char' to escape the given character (ie, '\<' to escape a left bracket).

Special Types: Consider array, which may be contain objects or types. In this implementation, array is considered to be an object of class name array which will then perform the necessary initialization code.

Intent: This is not meant to be a human-oriented protocol. Humans can read it, but it is intended to be read by a program that will use reflection to recreate object as specified by class name and initialize the field values as given for the new object.

DBM oriented: