Difference between revisions of "Aquila Component Overview"
(Created page with "{{ProductTopic|Technical|Overview}} == App Server Overview == The app server component is alternatively known as the middle-tier. It's role is to accept incoming requests ...") |
m |
||
| Line 2: | Line 2: | ||
| − | == App Server | + | == App Server == |
| − | The app server component is alternatively known as the middle-tier. It's role is to | + | 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. |
| − | + | 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. | |
| − | a) A Windows DLL | + | 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 (ILOG). This provides a comprehensive audit trail of all changes made to the database: inserts, updates & deletes complete with before and after values. |
| − | + | ||
| − | + | Finally, the app server also provides some non-data related functions such as the ability to receive uploaded files. | |
| + | |||
| + | The app server is available in 3 builds: | ||
| + | |||
| + | # 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. | ||
| + | # 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. | ||
| + | # 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. As the replication process runs | ||
| + | |||
| + | == Rebuild Engine == | ||
| + | |||
| + | The rebuild engine | ||
Revision as of 11:55, 18 September 2012
This is a Technical Overview topic
App 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.
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 (ILOG). This provides a comprehensive audit trail of all changes made to the database: inserts, updates & deletes complete with before and after values.
Finally, the app server also provides some non-data related functions such as the ability to receive uploaded files.
The app server is available in 3 builds:
- 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.
- 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.
- 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. As the replication process runs
Rebuild Engine
The rebuild engine
