Architecture

The Polaris voting system will be implemented as a J2EE application, relying upon a database for persistence, and supporting communication with remote clients over RMI.

In order to fulfill the functional and non-functional requirements given in the IRV proposal, the system will use a traditional three-tier, architectural with a stateless middle tier, as shown in diagram 1, below.

This architecture, and specifically the stateless middle tier, will allow the system to meet the quality attributes of fault-tolerance (easy failover to other clustered servers), real-time, and high-performance (easy addition of more middle-tier machines).

There are two kinds of servers within the system: middle-tier and database.

The middle-tier servers run J2EE servers with EJB objects acting as a the system's distributed object interface to clients.

The servers receive RMI requests from Java clients (J2SE, J2ME, or J2EE Servlets) requesting the application's features, processes the requests, and returns the results.

The servers use only stateless session beans. This allows client requests to seamlessly switch between middle-tier machines without noticing any disruption and will greatly easy accomplishing the fault-tolerance, real-time, and high-performance goals later in development.

Given that the middle-tier servers are stateless, the server requires clients to do some state management (discussed in the Client sub-section) and also invokes the database server to access all of the system's state.

The database server stores all of the state for the system. For a list of the table schema, see the Database Tables section.

The database server can only receive SQL requests from the middle-tier, ensuring that the clients can not directly access the database and bypass critical business rules in changing the system state.

The team is deferring picking a client implementation until more is known about the effort required for the server implementation. The current choices being considered are:

• J2SE - A "fat-client" GUI
• J2ME - A cell-phone/hand-held GUI
• J2EE Web - A web-based HTML interface (which in turn has other clients, browsers)

Regardless of which implementation is chosen, the considerations are the same.

The purpose of each client is to allow its user (or multiple users, in the case of the web-based implementation) to vote in and see the results of elections in the system.

The client is responsible for remember its state (currently just the user's email address, password, and current election), allowing the middle-tier to be stateless

The user may only vote once per election, but may also periodically check on election results. Each user (not server) session will also have several physical server invocations (for logging in, viewing elections, viewing results, etc.), resulting in periodic bursts of invocations from each client.

The number of non-simultaneous users (and hence potential clients) is however many users are registered for an election within the system. This should be bound only by the backend database implementation (as the system requires at least one row per user).

The number of simultaneous clients is more directly bound by the middle-tier, though is subject to scaling through adding more servers. It is currently targeted at supporting 20 concurrent users.

The application exceptions are documented in the Javadocs accompanying this document. Application exceptions will percolate back to the client, which will be responsible for giving the user a reasonable option to response.

The system exceptions are the responsibility of the J2EE/EJB implementation and are not known at this time. System exceptions can happen on the client or middle-tier and will be handled differently for both:

• The client should handle system exceptions from the server and assume it was the result of a fluke or a middle-tier server going down. The client will retry the user's operation again, trusting that another server within the cluster will successfully handle its requests. However, after a certain number of successive failures, the client should fail and report to the user that the system is temporarily down.
• The middle-tier will treat system exceptions as critical errors and immediately fail the current request (aborting the transaction, so as to keep the data safe), deferring back to the client to try the request again, or decide if the system is indeed down and alert the user.

Transaction ensure data integrity, which is critical to the system, but also affect performance, which is also critical to the system.

As such, the number of transactions will be minimized and no on-going transactions will be utilized.

On each request, stateless session beans will start a transaction and then work with a simple (non-EJB) domain model to retrieve and store data in the database without the overhead of bringing other EJB beans into the transaction. Once the operations for the request are complete, the stateless session bean will commit the transaction (assuming no errors occurred).

This course-grained approach to transactions will help ensure the real-time and performance goals later in development.