Hierarchy Service

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
  • Working code here: https://source.sakaiproject.org/contrib/caret/hierarchy/trunk/
  • Example of usage (evalaution): https://source.sakaiproject.org/contrib/evaluation/trunk/
  • Continuum build: http://saffron.caret.cam.ac.uk/continuum/servlet/continuum/target/View.vm/fid/shellProject/id/116
• 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
    • HierarchyService is built from a set of interfaces (this is part of the extendability of the API)
    • HierarchyNodeReader
    • HierarchyNodeWriter
    • HierarchyTokens
  • There is a utility class to make it easier to deal with the hierarchy nodes
    • HierarchyUtils
  • 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

• Chuck has a doc about what he has done with site hierarchies
  https://source.sakaiproject.org/svn//reference/trunk/docs/architecture/sakai_pseudo_hierarchy.doc
• Matthew Buckett at Oxford is doing something with hierarchies related to sites
  Oxford Portal Hierarchy

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.