OSMIS Technical Specification

2. Architecture Overview

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.

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.

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.

• Extensibility: Since the project is intended as an OS project, an architecture that allows for functionality to be added incrementally is critical. Ideally, OS projects should allow for concurrent modifications to occur, and conflicts should be handled gracefully. It is important to design OS systems in such a way that changes that need to be made are localised as far as possible (i.e. do not affect the entire code base). This factor is probably more important in terms of design, where good modularisation and a sound logical architecture are key.
  
  In terms of platform and programming language, any one of the three considered, given a good design could fulfil this role. However a structured language that can enforce rules (such as adherence to interfaces) can only aid in a good design. Java is a good candidate given these requirements, although this alone would not have swayed the decision in favour of using Java.
• Ease of Development, Testing and Debugging: While scripting languages such as PHP and Python are hailed for how quickly a budding programmer can write his/her first program, testability and long-term maintainability were key factors considered here. In particular, the lack of proper state management inherent in Web-based applications was a major concern as this generally lengthens development time considerably and makes testing and debugging much more difficult. This was a particular concern given that this is intended to be a large-scale project. The idea that scripting languages are not suited for large-scale projects is debatable, but certainly one that the design team believes to be true.
• Current Developer Expertise: A factor that was given a lot of weight in the decision was current developer expertise. It was felt that, given the tight time frames, choosing a platform that the current developers (and design team) had some experience in was important. This is not only important from a productivity point of view, but also from a psychological viewpoint. Throwing the entire project team into the deep-end - as would have happened if Python was the language of choice - did not seem like a good option.
• Future Developer Expertise: Another factor taken into account was the OS community of developers. It is important to design a development platform that allows for easy development and integration. This includes choosing a relatively well-known programming language and developing a solid framework for integration. From the perspective of the availability of future developers, Python, PHP and Java would have been equally good choices. All three have a dedicated OS community of developers, and are considered popular programming languages.
  
  Incidentally, according to the TIOBE Programming Community Index statistics for April 2003 show Java as (consistently) being the most popular programming language, where as PHP ranks 7th, and Python follows at 14th. Another interesting statistic reveals that 50% of the most active projects at Source Forge are Java related projects.
• Barrier to Entry: One of the factors mentioned on the mailing list was the effort required for a new developer to be able to contribute to an OS project. Another question raised here was whether a developer would consider learning a new language just to be able to contribute to a specific project. While the latter is an interesting question, it is not a serious concern here since there seems to be a sufficient number of developers in all the platforms considered.
  
  Any reasonably sized OS project has a framework that a developer must learn and abide by in order to contribute to the source base. In my experience, languages that are considered easy have more complex frameworks since the language itself does not offer much in the way of rigidity and regulations. In some cases, I would argue that the development framework is more complex than the language itself. Thus the barrier a developer faces to contributing to an OS project is not so much based on the programming language, but the learning curve associated with the development framework and design of the system.
• Interoperability: One of the requirements for the project is that the system be platform independent. This immediately ruled out many potential platforms such as C/C++ that could otherwise have been considered. In terms of building a system with a proper (i.e. non Web-browser) GUI, Java was the only viable option. (To qualify the last statement, GUI frameworks for some of the other considered languages, such as Python, do exist but appear immature at this point.)
• User Expertise: This factor addresses issues such as system installation, upgrades, training and support issues. One of the strong cases made for a Web-based architecture was based on the argument that installation, upgrades and maintenance is much easier since they all happen on a single machine. Additional clients are trivial to add because the only requirement for clients is that they have a Web browser. Conversely, GUI applications have the disadvantage that both server and client machines need to be installed and upgraded.
  
  This disadvantage is duly noted and was one of the trade-offs made in deciding on a platform. It is hoped that tools such as Webstart will make these administrative tasks slightly easier to manage, although we realise that it will not reach the simplicity of the Web-based architecture in this regard.
• Performance: One of the criticisms against using Java was that it would greatly affect the performance of the system, and raise the minimum hardware requirements. In terms of speed, there is little evidence to suggest that Python or PHP runs faster than Java. In terms of minimum hardware requirements (which is a more important factor IMO), we concede that Java is typically more memory intensive than the alternatives. However, the minimum hardware requirements (according to Sun) for the JRE is currently a Pentium 166 with 32M of RAM (48M recommended).
  
  It is also hoped that the fat client architecture chosen will help alleviate some of the possible performance problems as it will distribute the processing over multiple machines. In any event, this factor is one that will be considered through the initial development process and will be actively addressed when there is code to test. The system design allows for computation to be moved to the server (to create a thinner client) to the extent where the entire application can be changed into a Web application if the need arises.
• Web-based user interface versus GUI: People have varying opinions about what type of user interface is more suitable for the less computer literate person. Some argue that Web-based interfaces are more intuitive since the user is likely to have seen something similar before. Since GUIs allow for more complex user interfaces to be built, there is a greater chance to overload the user interface and confuse the user.
  
  The stance we took was that GUIs do not have to be used in their most complex form, and if the GUI is kept simple, then we can harness the power of GUIs to direct the users' focus correctly and apply good user interface principles to make the system even easier and more intuitive than a Web-based interface could.

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.