Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Introduction

In LAMS 1.0.x, there is no separation between tools and core services. Although, LAMS 1.0.x is a modular application (with four modules: Authoring, Monitor, Administration and Learner), if a new tool is implemented, different pieces of code must be added to all four modules. In addition, once the new code is added, the whole LAMS system must be recompiled and redeployed (see diagram below).



...

Additionally, we were always asked "I have this sensational assessment engine that my university has bought for a 10 million dollars, but it doesn't do the sequencing that LAMS does. Can you guys integrate it as a tool in LAMS?". Unfortunately, the answer was: "Well, it's not very simple". And truly it isn't, as it requires changes to all modules and an interface to the assessment tool, take care of authentication/authorization issues, etc.


LAMS 2 .0 implements a modular architecture where tools and learning activities can be added on-the-fly to a LAMS 2.0 server. In order to provide such modularity, LAMS 2 .0 implements a Tools Contract. The Tools contract is a set of expected behaviours and APIs that each tool has to implement to communicate with LAMS Core. The LAMS Core has modules for Authoring, Monitor, Administration and Learner.

The new architecture proposes a clear and defined separation between tools and core service responsibilities/functionalities.



As you can see in the diagram above, LAMS Core is mainly the same main modules we previously have but now LAMS 2 .0 has abstracted the interface to "talk" the activity tools.

...

Using this Tool Contract, not only LAMS tool can be "LAMS Tools" but also -in principle- external tools that implements it can become LAMS Tools.

Component Technologies

The diagram below illustrates the various technologies used in LAMS and how the different components communication. Apache is not required for LAMS however it is common in large deployments.

...