OSMIS Technical Specification

2. Architecture Overview

Assumptions, Dependencies and Constraints

One of the key characteristics of the OSMIS project is its use of the Open Source development methodology. The way in which this methodology has been applied is to create an initial system (in a traditional closed-source manner), and then to open up the system to third party contributors (in the traditional Open Source manner). This places additional constraints on the architecture to allow easy integration and testing of third-party components.

This system is primarily intended for use in South African schools, with a strong focus on traditionally disadvantaged schools. One of purposes of the Open Source license is that it will allow schools to acquire a license for the system at no cost. Another consequence of this is that the system should be capable of running on older hardware, and should be easy to install and upgrade.

The system has also been earmarked for deployment in other African countries (assuming the project is successful) and so internationalisation is another architectural requirement.

Architecture Summary

Due to the requirements and constraints imposed on the project, a number of difficult decisions had to be made. An important effect of these constraints was a requirement for a well planned, modular system architecture that would be easy to extend and maintain. This is a recurring theme in this document, which is discussed in the various sections in which it occurs.

One of the architecture-related decisions that needed to be made was the choice of development platform. This issue was put forward to the OSMIS Open Source community, and the response was loud and varied. After much consideration, the architecture team decided on a fat client architecture using Java, with a single PostgreSQL database server as the back-end. No application server was to be used, as this would result in a significant performance hit, and the database connectivity would be implemented using standard JDBC.

However, the system was to be structured so that the user interface was decoupled from the business logic, and the business logic was decoupled from the database. This would allow us to move to a thin client (possibly Web-based) architecture fairly painlessly in the future, as well as change the implementation of the permanent store without affecting the rest of the system.

Architecture and Platform Considerations

A number of factors were considered during the discussions relating to the architectural decisions. The discussion will be centered around a set of core topics, with specific reference to the comments made on the OSMIS mailing list. The main platforms suggested on the list were Java, PHP and Python.

In conclusion, while Java is certainly not a panacea in terms of the factors discussed above, we believe it offers the best trade-off. It is a full-blown programming language with a rich library and development tools. It allows for various architectures from fat client (as we're currently using it) to Web-based (in case requirements change at a later stage). It also allows for non-Java additions (such as Python modules) to be added if need be.

Most members of the project team have had at least some previous exposure to Java, and there certainly seems to be no shortage of Java support in the OS community.

  << Previous Up
Next >>