Technology

A glimpse of the code behind your onCourse web site.

The web site component of onCourse is engineered with several fundamental principles: ease of use, speed and reliability.

Ease of use

The last thing you want with a new web site is more work in maintaining and updating yet another listing of courses. And you don’t want to engage a web designer every time you alter something on your site. So onCourse is designed to automatically send the relevant data from onCourse to the web site. This includes course information, classes, sessions, tutor information, sites, rooms and much more. In addition, students are able to see their enrolment history online and tutors login to see upcoming classes. Naturally all this happens automatically without any intervention from you. All this data is pushed regularly from onCourse Server to the web site in the background, compressed and over secure channels.

Even better, we also send pictures, pdfs, Word docs, and any other attachments up to the web site, along with any web pages you create. We allow you to define your own menu structure, both for the web pages and for the subject categorisation of the courses. You can change these things at any time, without knowing a single html code and have the changes reflected on the web site almost immediately.

Ease of use has been a guiding goal for how we want students to interact with the site. Particularly since they are probably only potential students when they reach your web site and you have to convince them to enrol. Every step in the site which isn’t absolutely clear will cause some students to give up; even if you lose 5% at each step, that’s a big chunk of your revenue by the end. So we have tested the enrolment and searching processes both technically and with a range of people with different skills. We don’t require students to log in before enrolling: why lose an enrolment to gain a marketing list of dubious value?

Reliability and speed

Our programming environment is the object oriented programming language Java and the WebObjects framework. This environment is very scalable and robust, allowing us to make updates to the live application without any downtime or interrupting any user in the middle of an enrolment. WebObjects runs systems such as the Apple iTunes Music Store, processing millions of enquiries per day and over 100,000 sales per week, and the BBC web site where it pulls together huge news databases for web presentation. This is because the WebObjects toolkit allows us to add extra applications and servers to deal with load in a fully clustered configuration.

The backend database is mySQL which is an extremely fast open source database with years of proven reliability. It also scales to support millions of records and thousands of simultaneous users. In our environment we have it replicating in real time between two separate database servers. This gives us effectively a real time backup down the last second.

The operating system, FreeBSD, is descended from the original Unix operating systems from AT&T. It is completely open source and has a reputation for outstanding stability. The development of FreeBSD is similar to Linux but is typically more cautious and focussed on reliability over features. It tends to be used as a server platform and is in wide use at places like Yahoo and Google.

A second redundant server is available at all times for backup. Database records are replicated in real time to the second machine, ready to be switched into production at any time. If load were to peak we are able to share the processing across both servers simultaneously. The machines are server class Xeon. Both use error checking memory and fast 15,000rpm SCSI disk systems. The machines are firewalled from outside attack; a third party performs regular scheduled vulnerability tests.

The servers are located in a secure hosting facility in Sydney. They are connected by three independent high speed links to the internet, supported by uninterrupted power and a diesel generator, in a temperature controlled high security environment. This data centre also hosts servers from all the major telecommunications companies and banks.

You might look at the above and think “this seems like a little overkill for my little site”. But this approach has saved us thousands of hours of worry and support. When we have a web solution which just works, we can focus our energies on other things.

Methodology

We approached the design of this system in a way that involved more work up front but significant rewards now and into the future. To understand what we did, we will first look at the alternatives we considered.

Serving web pages from your office

Technically this is a simple solution. Web pages could be served directly by onCourse Server in your office. Students therefore access your main database server directly when they view the web site. However:

  • The internet link to your office is probably neither very fast nor guaranteed, important features as you rely more and more on your web site. ADSL connections are much slower sending data out of your office to a student than downloading pages (that is why they are called Asymmetric). This means a poor experience for a student browsing the site. High quality internet connections are extremely expensive, usually over $500 per month. It is not uncommon for lower cost ADSL connections to be down for several days at a time.
  • Our data centre by contrast has three independent very high speed connections to the internet, two of which would need to fail before you would notice the difference. A team of technical staff monitor the connections 24 hours a day.
  • Our servers in the data centre have error correcting memory, a temperature controlled environment and are maintained and monitored constantly. It is unlikely you can achieve quite the same level of reliability in your office without spending quite a bit of money.
  • Because our servers don’t contain all your financial data, nor we store student credit cards for more than the few seconds required, security is easier to achieve than if students were connecting directly to your main database in your office.

Using web site as the master database

Another solution is to have no database in your office at all. Instead, every time you wish to access the system you do so through a web page.

  • Your entire database is stored offsite in the hands of someone else. Should relations sour, how easy would it be to recover all the invaluable student, course and enrolment data you’ve built up over the years? Could your business continue without it?
  • Web applications are significantly slower for office staff because the user interface is very limited. It is complex to have multiple windows open, autocompletion (eg searching for a student) is clunky and in general the interface is not as helpful.
  • Web applications are slower. Page redraws might only be a few seconds, but when taking a phone enrolment, the cumulative delays could double the total time taken.
  • Printed reports are clumsy and hard to format cleanly in a web application. This includes invoices and documents which must be presented to the customer.
  • Your entire business becomes dependent on your internet link. An outage there stops any enrolments, enquiries or other work.

Our system

So we devised a “third way”. This split system uses onCourse in your office as your internal management tool. It is client/server: meaning that that you can have as many users connected to the system at the same time as you require. We then wrote a secure communications system between onCourse and the web site using a protocol called SOAP.

The major part of our work went into modelling every scenario. What happens if the office internet connection is down? What happens if a user enrols online in the last place of a course at exactly the same time as someone takes a phone enrolment at the office for that course? What happens when your staff change the details for a course? We have detailed answers to all these questions and the system gives the student clear directions at all times.

Every time you make a change in onCourse, that change is automatically uploaded in the background to the web site. Also, new students and enrolments from the web site are automatically downloaded into your onCourse server without any interaction from you.