Skip to end of metadata
Go to start of metadata

Proof Of Concept

  • This is a functional proof of concept, please feel free to try it out and also post comments, suggestions, etc.

Information

The Hierarchy Service supports general storage of hierarchical nodes within Sakai. It can support multiple hierarchies and has a flexible interface which is meant to be generalized and easy to use. The current implementation is optimized to support many reads of many nodes. Use of this would generally require the developer to write their own service which uses this and the Permissions Token Generator.

Hierarchy Service

  • Goals
    • Generalized storage of hierarchical data in Sakai
    • Flexible and easy to use interface
    • Single point of optimization for hierarchical service
    • Supports high performance permissions handling in conjunction with the Permissions Token Generator
    • Ability to create many hierarchies
    • Support for many children per node
    • Support for multiple parents per node
  • Proof of concept code
  • Usage of the hierarchy
    • Take a look at the sample in evaluation ExternalHierarchyLogicImpl
    • A developer would create a service class which manages the hierarchy for their class or service
      • Each hierarchy would have a single root node which can only have children
    • This service class would use the HierarchyService to create a hierarchy and manage the nodes within it
    • There is a utility class to make it easier to deal with the hierarchy nodes
    • The data associated with each node would be stored within the service (in a database table probably)
      • This allows the developer to focus on what they want to associate with nodes rather than worrying about how they can make them perform well
  • Current Implementation details
    • Uses a hibernate backend to store the hierarchy data in a database table
    • Provides a guaranteed single database call to get a node and information about all associated nodes
    • Ensures the integrity of the hierarchical tree using transactions to create, move, delete nodes
    • Splits nodes and node meta data to ensure cheap updates of meta data without locking

Notes

Use Cases / Requirements

  • Course Management - Josh Holtzman
    1. The ability to query for sections down an institutional hierarchy.
      This might look like List<Section> getChildSections(String
      courseSetEid). Translating to hierarchy speak, it's
      getLeafNodes(Node). I'm pretty sure this simple use case will be covered
    2. The ability to query for memberships up a hierarchy. This might look
      like List<Membership> getMembershipsAboveSection(String userEid, String
      sectionEid), returning all memberships for any course offering or course
      set (node) above this section (leaf node).
      This is complicated by the fact that a child node can have multiple
      parents (e.g. a course can be in multiple departments). We may need to
      model this where a course has a node in multiple places in the CM
      hierarchy... I'm not sure if that's possible, or if that negates any
      performance improvements the hierarchy service is attempting to provide.
  • Checklist - Dick Elis
    1. Simple hierarchies unlimited in number and depth but unlikely to be deep - e.g., Grad Tools checklists consist of two hierarchies of three levels (institutional requirements for most graduate students or for music performance graduate students, which are inherited by associated departments and to which departmental requirements are added, and which in turn are inherited by their students, to which faculty committee and the student may add personal as opposed to institutional steps) - Masters checklists would consist of 100 hierarchies of 2 levels (the department and students under the department), personal or project checklists might consist of 1000 hierarchies of 1 level.
    2. Cascading CRUD - administrators may make retroactive changes to checklists that should be carried over to checklists that inherit from this checklist - interactive batch processing where speed is an issue, as is connection time out
    3. Lock a section of the hierarchy for cascading CRUD
    4. View Progress - At any level above, show all leaf nodes and individual checklists below showing completion progress
    5. allowUpdateChildren, allowBasedOnChecklist, getChildChecklists, getSharedChecklists, hasChildChecklist, getTree(String root)
    6. Attached screen shots show how the root (blank checklist), branch (based on checklist) and leaf (use checklist) are created, and sharing of a checklist by owner

2 Comments

  1. During our discussions around Goal Management, it was determined that a strict hierarchy was insufficient to meet our needs for mapping activities to goals. In most cases, associations are created from a number of course sites in which activities are created to a program site in which goals are defined. There are situations such as cross-listed courses, however, where a course site needs to be associated to multiple program sites. Also, in order to define course level goals, we required that a course site can be associated to itself. It is through established unidirectional associations that we check for existence of defined goals and permissions to perform actions against those goals. From your description, it seems that there is enough flexibility to reuse this Hierarchy Service for our needs by mapping course sites as children of one or more parent program sites. Does this service allow for mapping of a site to itself...or is this entirely implementation dependent?

    I'd like to read more about the Permissions Token Generator. We use permission checks at each of end of an association to determine permission to perform certain actions through the use of permission pairs. So in order to modify a link from an activity in a course site to a goal in an associated program site, we require a permission to modify_link_from in the course site and modify_link_to in the program site. Depending on associations and permissions between sites, we can allow a user, for example, to define goals in a program site, only view links to goals in one associated course site and modify links to goals from another associated course site.

    I don't know if this is the best model for such a requirement, and my guess is the performance will rapidly degrade with high use...but it works for now. Do you anticipate being able to provide such granularity with permissions, so that checks can be made between nodes of the hierarchy, or is this too entirely implementation dependent?

  2. Is the idea/concept on this page still actively being pursued, or has it been superseded by other activities or needs?