Case for Moodle

From MoodleDocs
Revision as of 10:11, 17 March 2006 by Dan Stowell (talk | contribs)

The structure of this document was drafted by Terence Armentano, and the answers filled in with the collaboration of some members of the Moodle community. If you have suggestions about the sections included, please feel free to contribute - or suggest via this page's comments page.


High availability

The LMS must be robust enough to serve the diverse needs of thousands of learners, administrators, content builders and instructors simultaneously.

Usage patterns will vary strongly with the specific context of the deployment. But in general, Moodle presents a high-availability web-based interface, allowing learners, tutors, and administrators routinely to log in and carry out their daily taks. See the scalability section for other relevant information.

Scalability

The infrastructure should be able to expand or scale to meet future growth, both in terms of the volume of instruction and the size of the student body.

Moodle runs on a wide variety of webservers/database technologies. As with any installation of a server-based software system, it is crucial to refine carefully the choice of hardware, operating system, and database system, to ensure that the system can cope with a high throughput. The largest live Moodle installation at time of writing (Open Polytechnic of New Zealand) handles 45,000+ students and 6,500+ courses registered. There is a page about other large installations.

The consensus in the Moodle community seems to be that a Linux-based webserver running Apache, with PHP installed as well as a PHP accelerator, is commonly the best choice, and that the webserver and database server should sit on separate machines.

It should be possible to load-balance a Moodle installation, for example by using more than one webserver if necessary. The separate webservers should query the same database and refer to the same filestore area, but otherwise the separation of the application layers is complete enough to make this kind of clustering feasible. Similarly, the database could be a cluster of servers (e.g. a MySQL cluster).

All this implies that Moodle's architecture makes it easy to respond to future demand, by adapting the technologies upon which it runs. This should be possible even in a live setting, to improve the service without major disruption.

Usability

To support a host of automated and personalized services, such as self-paced and role-specific learning, the access, delivery and presentation of material must be easy-to-use and highly intuitive — like surfing on the Web or shopping on Amazon.com.

Perhaps the best sentence to short Moodle usability is: "simple and powerful".

There is some talk about Moodle usability.

The Interface guidelines aim to help developers work towards a highly usable system. And the general consensus is that Moodle excels in this area.

Interoperability

To support content from different sources and multiple vendors' hardware/software solutions, the LMS should exchange data using open industry standards for Web deployments.

  • For authentication, Moodle supports authenticating against LDAP, which is the most widely-used standard protocol for this purpose. It also supports authentication based on direct database lookup (e.g. in an external Oracle database), or on the Shibboleth protocol, or alternatively using IMAP, NNTP, CAS or FirstClass.
  • For enrolment, Moodle supports the use of an LDAP server (e.g. Active Directory), and the IMS Enterprise standard (via a downloadable plugin).
  • For content, there are a number of aspects:
    • Moodle supports the import/export of Reusable Learning Objects packaged according to the SCORM / IMS Content Packaging standards.
    • Quiz questions can be exported in the international standard IMS QTI 2 format.
    • RSS newsfeeds can be integrated into a Moodle site or course.
    • Forum discussions can be accessed as RSS newsfeeds, and therefore integrated into other RSS-capable websites or systems.

The use of XML for import/export is standard in Moodle. The "web services" method of exchanging data with other systems (e.g. via SOAP or XML-RPC) is not yet standard - but is in active development.

Stability

The LMS infrastructure can reliably and effectively manage a large enterprise implementation running 24x7.

This is the same issue as discussed in Availability and Scalability above.

Security

As with any outward-facing collaborative solution, the LMS can selectively limit and control access to online content, resources and back-end functions, both internally and externally, for its diverse user community.

Moodle's current system of roles includes administrators, teachers, teachers without editing privileges (sometimes called teaching assistants), students, and guests. Each has a clearly defined set of privileges and cannot act beyond those privileges.

The basic unit of organisation is the course. An administrator can assign any number of teachers (with or without rights to edit content) to a given course, which has its own file area as well as its own discussions forums and other activities. Teachers can decide whether content is visible or hidden to students.

Moodle is designed and audited to be secure for its purpose. A security issues/announcements site exists at http://security.moodle.org

See also