SOSA (Slovak open-source Academy)


SOSA (Slovak open-source Academy) – is a project aimed to create open source academy management system that will contain following functionality as separate modules:

  1. evidence of students (student module)
  2. evidence of subjects and their structure in academic year (student module)
  3. acceptance tests (acceptance module)
  4. online entry (entry module)
  5. timetable and schedule support (schedule module)
  6. requests and registry journal (request module)
  7. subscription to tests (subcsription module)


project is divided into 3 separate subprojects:

  1. SOSA_DB – database layer with complete data and application layer
  2. SOSA_GUI – application for employees that is using SOSA_DB functionality
  3. SOSA_WEB – or web gui for students access


  • sql server 2005 as database and application layer
  • .NET winforms as presentation layer for employees
  • php or .NET webforms as web presentation layer for students


there are 2 scenarios:

  1. separate servers (server + backup) for each faculty and one common server with daily synchronization
  2. common servers for whole university (requires sql server clusters) without the need to synchronize

In first scenario each faculty has its own server. Students have separate accounts on each faculty, they are studying on, but the accounts are synchronized on daily basis. During entry process, the student has to create a virtual request to subscribe to subject realized on different faculty. These requests are processed during the synchronization (e.g. because the subject might be defined as limited and the number of students can’t be more than X).


  • if something happens with network connectivity on one faculty others are not affected
  • good balance that might be adjusted based on the number of students
  • very good price (typically, sql server express might be sufficient)


  • special handling of subjects on different faculties
  • daily synchronization needed
  • none of the servers contains up-to-date data (1 day delay on common server)

In second scenario everything is stored in one database that is distributed accross sql server cluster nodes (very good performance, but also expensive). This scenario allows students to immediatelly subscribe to any subjects and access the study plan in one place.


  • very good backup scenarios
  • data are up-to-date
  • one common place to check study plan for students


  • if something happens with network connectivity all faculties are affected
  • expensive licences (licence for sql server enterprise)
  • expensive hardware (cisco routers for web servers performance balance management)


  1. students module at the end of march
  2. entry module at the end of april
  3. schedule module at the end of may
  4. acceptance module at the end of june
  5. other modules undetermined