Aquila Component Overview

This is a Technical Overview topic

Overview

Application Server

The app server component is alternatively known as the "middle-tier". It's role is to deal with requests from the client app, much like a web server. All our app server components use the HTTP protocol.

App Server Functions

For the majority of the time, the app server simply queries data from a database and returns the result set to the client app, and accepts data update requests from the client that it applies to the database. In a small number of cases, the app server will manipulate data itself, however these methods are not required by the central database.

An important role of the app server is to audit changes to the database. The app server intercepts successful data update requests and logs the changes to a data table. This provides a comprehensive audit trail of all changes made to the database: inserts, updates & deletes complete with before and after values. Each audit trail record contains changes made to a single database table within a single transaction.

Finally, the app server also provides some non-data related functions such as the ability to receive uploaded files.

Versions

The app server is available in 3 builds:

1. A Windows DLL (aquilaserverlib.dll) - when used with the client app it turns it into a classic two-tier, client/server app. Can be used for standalone config with SQLite database.
2. Windows Service (aquilaserver.exe) - intended for use in a LAN environment. Listens on a specified port (default 8099). Can also be used for WAN via port forwarding.
3. An IIS CGI web module (aquilaweb.exe) - intended for use with IIS to enable client to app server communications via the internet/intranet over port 80.

Security

All communications between the client and the app server are encrypted using AES-256. In addition, every method call on the server requires a valid session id that is verified against the session manager data table in the database. The only way for a client to obtain a valid session id is via a successful login.

All user authentication logic is in the app server. The client sends encrypted login information (i.e. username, password) and it then receives success information with a new session id, or a failure notice with an error message.

Replication

The client app is designed to send audit trail data to a second server. This second server is the replication slave and for the iBID project will be hosted by MDSAS. Each burn service installation is effectively a replication master database.

While the client app is in use, it starts a replication process on a timed interval (roughly every 3 minutes) that fetches the oldest unsent audit trail records from it's own database (maximum 300 records) & inserts these records into the same table on the replication slave database (at MDSAS). After a successful insert, it marks the record as "sent" in it's own database.

The net effect on the replication slave is that the AquilaWeb.exe will handle several database inserts on an ad-hoc basis.

Rebuild Engine

The rebuild engine is a continuous process designed to re-create the contents of the clinical tables from the audit trail. At a timed interval the rebuild process does the following:

1. Retrieves a set number of records from the audit trail, oldest first (Note 1)
2. Parses the contents of the audit trail into the individual changes
3. Locates the appropriate record in the target database table (Note 2)
4. Compares the existing values in the table with the "old values" in the each change
5. Applies the change to the table or logs an error if there's a value mismatch

(1) the interval and number of records retrieved are configurable (2) locating the existing record and comparing existing values does not take place if the change type is "insert" for obvious reasons.

The rebuild engine is available as a desktop application or a windows service. The preferred deployment is as a windows service to enable continuous processing. The configuration file can be changed without needing to stop/start the service. The service can be controlled