The progress engine controls the progress of a lesson. When a learner starts a lesson or moves from activity to activity, it is the progress engine guiding their way. Without the progress engine, LAMS isn't LAMS.
This page covers some background to the progress engine, the overall system design as well as the implementation algorithm.
To understand the progress engine, it is necessary to review some background concepts that related to LAMS progress engine. The main purpose of this section is to let new developers to understand the e-learning concept behind the design of progress engine and what progress engine is doing from user's point of view. If you knows LAMS concept already, please feel free to skip this section.
The concept of learning design has been defined in the IMS specification. This is not a document to debate about the concept of learning Design. We are more interested in what does learning design mean for LAMS and progress engine. From progress engine's perspective, learning design defines a sequence of collaborative learning activities and tools required to support these activities. It defines the basic navigation rule that progress engine should cope with.
Activity is the major element of a learning design. In another words, it is the learning object that sit inside the learning design. From progress engine's point of view, activities are the nodes of the sequence that the engine needs to navigate through. Generally they are a "box" of some kind on the learning design picture.
While a learning design is a reusable template, the lesson is one instance that using the learning design template. A lesson should have a number of participated learners, who are going to do the learning tasks that are defined in a learning design. Therefore, data that involved in the learning design instance of a particular lesson should not be shared across lessons. In terms of progress engine, the start of a lesson is the trigger of the progress engine. At this point, progress engine should initialize any resources of the learners.
The learner progress is the data holder that records the progress status of runtime learning design instance. In other words, learner progress record where the learner is in a lesson. Therefore, learner progress has to be specific to a particular learner and a particular lesson.
Learner Progress Bar
The learner progress bar is a Flash component that sits on the LAMS learner GUI interface. It gives learner a user friendly graphical representation of where they are in the learning design. It is a Flash reflection of learner progress data sitting on the server side.
The LAMS 2.0 progress engine is the third version of the algorithm of progressing the learning design since the born of LAMS software. LAMS has gained lot of lessons from previous implementation in terms of scalability and maintainability. To understand
the current design, it is necessary to review the experience and pitfalls from previous version.
The first version of LAMS progress engine is based on JMS asynchronous messaging. This approach has been referred to a Polling. Under the polling architecture, instead of LAMS itself to figure out what is the next activity for the learner, the client side (essentially the Flash component) drive the progress engine to keep moving by keep sending message to the server. This approach works fine if the number of concurrent learners is very small. However, once we moved onto the loading testing stage of LAMS application, the overhead generated by client messaging quickly becomes the major bottleneck that halted the whole system. The high concurrency nature of progress engine decides asynchronous messaging is not a suitable technology choice for LAMS.
This was then replaced with an approach that completely removed the overhead result from polling architecture, which make it possible for LAMS to scale under hundreds of concurrent users. However due to the lack of proper data structure to hold the learner's progress status, the Flash learner progress bar has to request the server to go through the entire learning design to calculate the exact position for display. Profiled showed this calculation consumed 65% of the system resources. The bigger the learning design is, the more resources need to be consumed by this profiling. Even worse, this calculation needs to be done every time when each learner wants to progress to next activity. Consequently, designing a flexible data structure that holds necessary progress data becomes the major rationale we followed in LAMS 2.0 Progress engine.