Difference between revisions of "WebIssues/Architecture"

From MiMec
Jump to: navigation, search
(New page: 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 deskt...)
 
 
Line 1: Line 1:
−
This is a brief introduction to the architecture of the WebIssues system.
+
This is an overview of the architecture of the WebIssues system and its components.
  
−
== Introduction ==
+
== System Architecture ==
  
−
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.
+
The WebIssues system is based on a three-tier client-server architecture and consists of the following components:
 +
* database
 +
* server
 +
* client
  
−
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:
+
The most important part of the system is the rich desktop client application. The client maintains a local cache of data and implements much of the business logic. For example operations like filtering, searching and sorting are performed entirely on the client side practically in real-time, significantly reducing the workload of the server.
−
* 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 [http://freshmeat.net/browse/1017/?offset=0&orderby=&filter_scope=230%2C229 freshmeat]).
+
Version 1.0 of the system introduces a web client tightly integrated with the server, however the desktop client remains the primary focus as something that makes WebIssues distinct from other issue tracking systems.
  
−
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 ==
  
−
=== Server ===
+
The server part of WebIssues, written in PHP, is designed as a thin wrapper over the database, allowing to synchronize data between the client and the server and to perform modifications in the database. It provides independence of the database engine, network transparency, security and data integrity, but it is designed specifically for the rich client and implements very little business logic on its own. The server also provides several additional services like large file storage, logging, sending email notifications, etc.
  
−
The server part of WebIssues is basically a thin wrapper over an SQL database which provides the following benefits over a stand-alone database:
+
A special protocol (see [[../Protocol|WebIssues protocol]] for more information) is used for communication between the client and the server. It is based on plain HTTP request and response, uses no additional markup or metadata to decorate information and consists of only few commands for retrieving data (often in an incremental way). In version 1.0 it is possible to easily implement different communication protocols.
−
* 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.
+
== Desktop Client ==
  
−
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 [[../Protocol|WebIssues protocol]]) instead of SQL. All presentation aspects are left to the client.
+
The desktop client, written in C++ using the Qt framework, uses a variant of the model-view-controller architecture. The model is responsible for storing data retrieved from the server in structures closely resembling the database schema. The views retrieve data from the model and present them to the user. The controller communicates with the server in order to perform operations and to update the data stored in the model.
  
−
=== Client ===
+
== Web 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.
+
The web client, introduced in version 1.0, is an integral part of the server. It is based on the Web MVC architecture (see [[../MVC_Pattern|MVC Pattern]] for more information). The model consists of a data access layer and an API for the database; this part is shared with the server. The controller consists of an application (front controller) and individual pages which process input and retrieve information from the model. The views are simple templates which render the HTML output with provided 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.
 

Latest revision as of 14:10, 25 June 2010

This is an overview of the architecture of the WebIssues system and its components.

System Architecture

The WebIssues system is based on a three-tier client-server architecture and consists of the following components:

  • database
  • server
  • client

The most important part of the system is the rich desktop client application. The client maintains a local cache of data and implements much of the business logic. For example operations like filtering, searching and sorting are performed entirely on the client side practically in real-time, significantly reducing the workload of the server.

Version 1.0 of the system introduces a web client tightly integrated with the server, however the desktop client remains the primary focus as something that makes WebIssues distinct from other issue tracking systems.

Server

The server part of WebIssues, written in PHP, is designed as a thin wrapper over the database, allowing to synchronize data between the client and the server and to perform modifications in the database. It provides independence of the database engine, network transparency, security and data integrity, but it is designed specifically for the rich client and implements very little business logic on its own. The server also provides several additional services like large file storage, logging, sending email notifications, etc.

A special protocol (see WebIssues protocol for more information) is used for communication between the client and the server. It is based on plain HTTP request and response, uses no additional markup or metadata to decorate information and consists of only few commands for retrieving data (often in an incremental way). In version 1.0 it is possible to easily implement different communication protocols.

Desktop Client

The desktop client, written in C++ using the Qt framework, uses a variant of the model-view-controller architecture. The model is responsible for storing data retrieved from the server in structures closely resembling the database schema. The views retrieve data from the model and present them to the user. The controller communicates with the server in order to perform operations and to update the data stored in the model.

Web Client

The web client, introduced in version 1.0, is an integral part of the server. It is based on the Web MVC architecture (see MVC Pattern for more information). The model consists of a data access layer and an API for the database; this part is shared with the server. The controller consists of an application (front controller) and individual pages which process input and retrieve information from the model. The views are simple templates which render the HTML output with provided data.

Retrieved from "https://wiki.mimec.org/index.php?title=WebIssues/Architecture&oldid=226"