dotLRN Architecture

by Ben Adida and Arjun Sanyal, part of dotLRN Documentation.

dotLRN is built on OpenACS 4.x, a modular architecture for community-oriented web applications. dotLRN is also modular in that new course management functionality can be added as desired. Since dotLRN modules must function within the dotLRN architecture, dotLRN modularity must be built on top of OpenACS modularity.

The dotLRN architecture attempts to define a framework within which learning communities develop. A learning community may take many different forms but remains the crux of the architecture.

dotLRN Community

A dotLRN Community is architected as a series of OpenACS components, with a heavy use of the subsite concept. One community is represented by:

an OpenACS group: this serves to define membership and roles within the learning community.
a site node: this serves to define a consistent URL for the learning community, and to segment away each communities from one another. An example is /dotlrn/alumni-1998.
an instance of the dotLRN Community Manager package: this serves to display community-specific data in a way that is clearly segmented away from the other learning communities using the acs-subsite constructs.

OpenACS Group

The core dotLRN group type is dotlrn_community. This group type defines some basic attributes that all communities have:

a short name: a simple name with no spaces, no special characters, usually all lowercase. e.g. finance-101
a pretty name: a name that is used in pretty presentation. e.g. Finance 101
start and end dates: for communities that have certain validity periods, a start date and end date.

There are two different types of learning communities in the basic dotLRN release: class instances and clubs. While Clubs need no additional attributes, Class Instances require information concerning the Term and Year of the Class Instance.

Site Node

In dotLRN, a community is mounted only at one particular node. In the future, if communities end up being multi-mounted, there will have to remain a canonical location for the community in order to ensure maximal modularity - specifically the ability to point to a community's URL using only the community_id as a starting point.

Instance of dotLRN Community Manager

The core dotLRN OpenACS package is called dotlrn (surprisingly enough). This package is meant to be remounted to handle community types and specific communities. A package_id corresponds to each community.

The group types for these two dotLRN Community Types are dotlrn_class_instance and dotlrn_club.

Use of NPA

dotLRN makes heavy use of the New Portal Architecture.

Each full-access user has a personal portal where all data from all communities is centralized in one place. This is called the dotLRN User Portal.

Each community has a non-member portal which displays information to those browsing the system and wanting to find out more about a community before joining it. This is called the dotLRN Community Non-Member Portal.

Each community also has an administrative portal which centralizes all administrative functionality for that community. This is called the dotLRN Community Admin Portal.

Finally, each community member has her own dotlrn Community Member Portal. The important distinction here is that there is a different portal for each member of this community. Thus, if a community has 100 members, there are 100 individually managed portals. These portals are initially created from the dotLRN Community Portal Template that administrators of the community control.

dotLRN Applets

dotLRN Communities have various packages of functionality. These packages (dotLRN applets) are much like existing OpenACS 4 packages, but with added specifications, special callback interfaces, and predictable APIs that not every OpenACS 4 package will have.

Thus, a dotLRN Applet is composed of three pieces that may each be a separate OpenACS package:

OpenACS raw functionality, to provide discussion forum functionality. As much as possible, this shouldn't depend on other dotLRN components. (e.g. bboard)
OpenACS portlet, using the New Portal Architecture (NPA), to provide the ability to display the raw functionality in a portal interface. This obviously depends on the the NPA, but should otherwise be as independent as possible from dotLRN. (e.g. bboard-portlet)
dotLRN functionality hooks, to link the raw functionality into the appropriate dotLRN structure. This obviously depends on dotLRN, but should be as thin a layer as possible on top of the the previous two components. (e.g. dotlrn-bboard).

NPA Interactions

The relationship between the NPA and the portlet functionality is explored in the NPA Architecture Manual.

dotLRN Applet API

The relationship between dotLRN and the specific dotLRN-dependent packages (dotlrn-bboard, dotlrn-faq, etc...) is defined using ACS Service Contract. ACS Service Contract defines a standard provider/consumer interface with special contract APIs. The dotLRN system defines the dotLRN Applet Contract, which includes the following operations:

GetPrettyName: Obtain a pretty, presentable name for the applet in question.
AddAppletToCommunity: Add the applet to a new community. This will most probably entail instantiating a new package for this functionality, mounted below the community's main mount point. It will also involve setting up applet-specific data structures (e.g. a new forum inside bboard).
RemoveAppletFromCommunity: Remove the applet from the community. This will entail cleaning up any applet-specific data structures, removing the mount point and package instance.
AddUser: add a user to dotLRN in general. This user has not yet joined any community, but may need user-specific functionality enabled (a private folder for files, a personal calendar, etc..)
RemoveUser: remove a user from dotLRN in general. This cleans up the AddUser operation.
AddUserToCommunity: add a user to the community, and perform any applet-specific related actions. For applets that are represented via a portlet (which is often, but not always, the case), this will add the right portlet to the user's portal page for that community. It will also add the generic portlet to the user's main, cross-community workspace.
RemoveUserFromCommunity: remove a user from a community, and thus clean up the actions of AddUserToCommunity.

The specifics of creating a dotLRN package are described in the dotLRN Package Creation Guide.