Difference between revisions of "WebIssues/Architecture"

Revision as of 14:46, 3 November 2008

This is a brief introduction to the architecture of the WebIssues system.

Introduction

WebIssues is a client/server system consisting of a rich client implemented as a native desktop application and a server consisting of a database and a thin application layer. The basic design principle is that almost all logic is implemented on the client side.

Although many systems have a tendency to use a thin client architecture and implement most logic on the server side, and especially most issue tracking systems are web applications whose client is basically a web browser, there are still at least two major advantages of a more traditional rich client architecture:

• comfort of use - traditional desktop applications are far ahead of even the most advanced web applications when it comes to usability and comfort of the user interface and offer features like contextual menus, key shortcuts, multiple windows, docking in system tray, etc.
• efficiency - all operations like filtering, searching and sorting are performed on the client side practically in real-time, the workload of the server is very low, and the system can be used efficiently from remote locations with slow internet connections

WebIssues is the only free issue tracking system which offers a native desktop client for both Linux and Window (according to freshmeat).

Moreover, the flexible architecture of WebIssues makes it more that just an issue tracking system. It can be thought of as a shared general-purpose database, very much like MS Access, but shared across the Internet and allowing to work on-line in a multi-user environment.

Server

The server part of WebIssues is basically a thin wrapper over an SQL database which provides the following benefits over a stand-alone database:

• abstraction - it doesn't matter to the client if the database is actually a MySQL, PostgreSQL or MS SQL Server
• network transparency - regular HTTP protocol is used to communicate with the server, which works nicely with firewalls, proxies, etc.
• security - the application layer provides user authentication and authorization (permission checking); in addition SSL encrypted connections can be used
• data integrity - the application layer validates all data and ensures that data integrity is preserved

The server can also provide additional services like large file storage, logging, sending email notifications, etc.

Apart of that, the WebIssues server can still be thought of as a kind of a DBMS (database management system) which uses a custom, simplified query language (i.e. the WebIssues protocol) instead of SQL. All presentation aspects are left to the client.

Client

The most important design principle of the client is that it stores a local cache of all required data in memory. These data is periodically updated to ensure that changes made by other users are synchronized. All modifications are performed by sending an appropriate command to the server and then updating the affected data.

For maximum performance, lists of issues and details of issues are updated incrementally, so only the changes made since the last update are fetched from the server. Lists of issues are stored permanently in a disk cache, so they don't have to be fully downloaded again after shutting down the application. Issue details, on the other hand, are removed from memory when they're not used for some time, to prevent too high memory usage.

Since the client has all the required data in its own in-memory database, it can very efficiently perform all operations such as filtering, searching, sorting, etc.