Sakai Framework

Added by Mark J. Norton, last edited by Mark J. Norton on May 16, 2006  (view change)

Guide to the Sakai 2.2 Framework

According to The Organization of Sakai Enabling Technologies and Information Models by Glenn Golden (April 10, 2006), the Sakai Framework is now organized into two collections of enabling technologies:

Name Location Notes
Functional Technologies    
  • Universal Components
 https://source.sakaiproject.org/svn/component/trunk component
    • ComponentManager
   Register and find components.
    • ServerConfigurationService
   System properties.
  • Collaborative Tools
 https://source.sakaiproject.org/svn/tool/trunk tool
    • ToolManager
   Manage tools.
    • ActiveToolManager
   Access the active tools.
    • SessionManager
   Access the session.
    • Tool
   A Sakai Tool object.
    • ActiveTool
   An Active Tool object.
    • Session
   A Sakai session.
    • ContextSession
    
    • ToolSession
   A tool session.
    • SessionBindingEvent
    
    • SessionBindingListener
    
  • Database
 https://source.sakaiproject.org/svn/db/trunk db
    • SqlService
   Database access
    • SqlReader
    
  • Server Push
 https://source.sakaiproject.org/svn/courier/trunk courier
    • CourierService
   Heartbeat, content push, etc.
    • Delivery
    
    • ObservingCourier
    
  • Email Out
 https://source.sakaiproject.org/svn/email/trunk email
    • Digest
    
    • DigestMessage
    
    • DigestService
   Manage digests.
    • EmailService
   Send email messages.
  • Memory Cache
 https://source.sakaiproject.org/svn/memory/trunk memory
    • Cache
    
    • Cacher
    
    • MemoryService
   Cache your objects here.
  • Presence
 https://source.sakaiproject.org/svn/presence/trunk presence
    • PresenceService
   Manage who's on-line and visible.
  • JSF
 https://source.sakaiproject.org/svn/jsf/trunk jsf
    • JSF Components
   JSF component implementations for Sun and myFaces.
  • Velocity
 https://source.sakaiproject.org/svn/velocity/trunk velocity
    • Velocity Components
   The old Velocity components.
  • Util
 https://source.sakaiproject.org/svn/util/trunk util
    • Exceptions
   Defintions of general Sakai exceptions.
    • IdManager
   Generate UUIDs.
    • ThreadLocalManager
   Manage local threads.
    • TimeService
   Sakai time management.
    • Logger
   Note that the log4j.properties file is in ..util-impl/log/src/conf
     
Informational Technologies    
  • Entity Bus
 https://source.sakaiproject.org/svn/entity/trunk entity
    • Entity
   Generic Sakai objects.
    • EntityProducer
   Generic entity producer.
    • EntityManager
   Manage Sakai objects.
  • User
 https://source.sakaiproject.org/svn/user/trunk user
    • UserDirectoryService
   Create and manage users.
    • UserDirectoryProvider
   External user service integration.
    • User
   A Sakai user.
    • SakaiPerson
   User metadata.
    • Authentication
   User authentication.
    • Evidence
   Passwords, etc.
    • PreferencesService
   Manage user preferences.
    • Preferences
   Preference properties.
  • Authorization
 https://source.sakaiproject.org/svn/authz/trunk authz
    • FunctionManager
   Register and manage authz functions.
    • PermissionsHelper
    
    • SecurityAdvisor
   Allows policy overrides.
    • SecurityService
   Resolve permission questions.
    • AuthzGroupService
   Permissions by groups.
    • AuthzGroup
   The basic authorization group (realm).
    • GroupProvider
   External group service integration.
    • Member
   Group membership.
    • Role
   Group roles.
  • Context
 https://source.sakaiproject.org/svn/context/trunk context
    • (no code)
   Currently handled by sites. To be broken out later.
  • Usage Events
 https://source.sakaiproject.org/svn/event/trunk event
    • EventTrackingService
   Track events using this service.
    • Event
   A Sakai event.
    • UsageSessionService
   Manage usage sessions.
    • UsageSession
    
    • NotificationService
   Manage notification.
    • Notification
   A notification.
    • NotificationAction
    
  • Course Management
 https://source.sakaiproject.org/svn/course-management/trunk course-management
    • AcademicSession
    
    • CanonicalCourse
    
    • CourseManagementAdministration
    
    • CourseManagementService
   Course management.
    • CourseOffering
    
    • CourseSet
    
    • Enrollment
    
    • EnrollmentSet
    
    • Membership
    
    • Section
    
  • Alias
 https://source.sakaiproject.org/svn/alias/trunk alias
    • Alias
   An alias
    • AliasService
   Manage resource aliases.
  • Site
 https://source.sakaiproject.org/svn/site/trunk site
    • Site
   A Sakai site.
    • SitePage
   A site page.
    • ToolConfiguration
   A tool configuration including skin, etc.
    • SiteService
   Manage sites.
    • Group
   A site group.

These groupings reflect the actual organization of the code. In some cases, top level modules will also include tools that maniuplate the data for administrative purposes.

Guide to the Sakai 2.0 Framework

Glenn R. Golden, March 23, 2005

The Sakai Framework is organized into a few modules with many projects. This
document describes this organization.

kernel Module

The kernel of the framework is in the module kernel in the sakai2 cvs. It is composed of projects that support the following features:

  • ID generation
  • Current (ThreadLocal) Support
  • Developer Logging
  • Components
  • Tools
  • Sessions
  • Request Conditioning

The kernel also provides standard components implementing the kernel APIs. These are packaged into a components package by another kernel module project.

ID Generation

The kernel supports the UUID generation needs for Sakai. This is done using the
IdManager. A standard component of the IdManager is provided that produces IEFT V4
UUIDs using the Apache Commons Id package.

Projects:

Project Name Description
id Id API
id-component IETF UUID Version 4 Apache Commons Id based implementation
of the Id API

Artifacts:

Project Name Artifact Name Type Deployment
id sakai2-id jar shared
id-component sakai2-id-component jar kernel-components

Current (Thread Local) Support

The CurrentManager helps code access data bound to the current request processing
thread, using a "thread local" like mechanism. Data can be cached for the current request here. APIs can support their "current" access (such as the SessionManager's
getCurrentSession) by using the CurrentManager.

The CurrentManager is supported by the RequestFilter, to assure that all values bound to the current request processing thread are cleaned up when the thread is complete.

Projects:

Project Name Description
current Current API
current-component Standard implementation of the Current API

Artifacts:

Project Name Artifact Name Type Deployment
current sakai2-current jar shared
current-component sakai2-current-component jar kernel-components

Developer Logging

Support for runtime message logging to capture normal and unusual and error
programming conditions is provided by the LogManager. The kernel also provisions the environment to support Apache Commons logging and Log4J logging, see [Sakai 2.0 Logging].

Projects:

Project Name Description
log Log API
log-component Standard implementation of the Log API
log-configure Log4J configuration for Sakai

Artifacts:

Project Name Artifact Name Type Deployment
log sakai2-log jar shared
log-component sakai2-log-component jar kernel-components
log-configure sakai2-log-configure jar common

Components

Sakai supports API programming practices by providing a dynamic binding component
loading, injection and discovery system. The kernel also provisions the environment to support direct use of the SpringFramework's component management. See [Sakai 2.0 Components]

Projects:

Project Name Description
component Component API and implementation
components-loader Components Package loader utility, used by the Component
API implementation

Artifacts:

Project Name Artifact Name Type Deployment
component sakai2-component jar shared
components-loader sakai2-components-loader jar shared

Tools

Support for Sakai tools is provided in the kernel. Tools are registered and invoked with kernel support. Tools may be used by dispatchers, navigators, portals, and aggregators, and by other tools in a helper mode.

The ActiveTool API and component support the invocation of Tools - this is dependent on the Servlet API. The Tool API supports the registration and discovery of tools and tool configuration and other meta-data. This is not dependent on the Servlet API. See Sakai 2.0 Tools.

Projects:

Project Name Description
tool Tool API
active-tool ActiveTool API
tool-component Standard implementation of the Tool API
active-tool-component Standard implementation of the ActiveTool API
tool-registration Tool registration Servlet Context Listener

Artifacts:

Project Name Artifact Name Type Deployment
tool sakai2-tool jar shared
active-tool sakai2-active-tool jar shared
tool-component sakai2-tool-component jar kernel-components
active-tool-component sakai2-active-tool-component jar kernel-components
tool-registration sakai2-tool-registration jar shared

Session

Sakai supports a Sakai-wide http-like Session, ToolSessions scoped for each tool
placement, and a synthetic HttpSession. See Sakai 2.0 Sessions

Projects:

Project Name Description
session Session API
session-component Standard implementation of the Session API

Artifacts:

Project Name Artifact Name Type Deployment
session sakai2-session jar shared
session-component sakai2-session-component jar kernel-components

Request

The kernel provides support to condition each http request in the form of a Servlet Filter that is used in front of all Sakai Servlet technology tool implementations. See [Sakai 2.0 Requests]

Projects:

Project Name Description
request Request processing Servlet Filter utility

Artifacts:

Project Name Artifact Name Type Deployment
request sakai2-request jar shared

Standard Components

The kernel provides standard implementations of the Kernel APIs and packages them into a components package.

Projects:

Project Name Description
kernel-components Components Package for the kernel components

Artifacts:

Project Name Artifact Name Type Deployment
kernel-components sakai2-kernel-components war components packages

jsf Module

The integration support for JavaServer Faces (JSF) is provided by the projects in the module jsf in the sakai2 cvs.

jsf Projects

tbd.

common Module

The common APIs of the framework is in the module common in the sakai2 cvs.

common Projects

tbd.

edu Module

The common educational APIs of the framework is in the module edu in the sakai2 cvs.

edu Projects

tbd.

Founding Principles of the Sakai Java Framework

The Sakai Java Framework operates in a Tomcat web server environment. However Sakai takes over the entire Tomcat instance and uses the Servlet web application capabilities as a unit of extension within the Sakai framework. This is a departure from the classic web application paradigm.

This is a significant departure from the classic use of a servlet container and is done for several very important reasons:

  • In a JSR-168 portal environment such as Pluto (from Jakarta) each Portlet is also a web application (Servlet) so that Portlets can take advantage of the Servlet API capabilities. This introduces several problems such as the http session timing out separately for each web application. Another problem is that information as to the current logged in user is often placed in the HttpSession - since the session is not shared somehow the user login information must be available to all of the Portlet web applications. Many people believe that somehow between the JSR-168 specification and the reference implementation (Jakarta Pluto) this detail was missed. Regardless of why this gap exists, in Sakai it must be solved. Sakai provides a solution to the problem in the Sakai Java Framework and is working with Pluto, uPortal, and others to produce a standard mechanism to solve this problem.
  • As multiple development efforts begin to be integrated into a Sakai environment, having a single location for jars becomes an intractable problem. By isolating major units of functionality into separate web applications the needed jars can be kept separate from the other components and tools. Earlier CHEF/Jetspeed experience with integration lead to the conclusion that after about four major applications being integrated, that the WEB-INF/lib was so polluted that it was difficult to keep the system reliable. The biggest problem is that different projects operate at different paces and the task of merging the jars of a two-year-old project with those of a very up-to-date project become nearly impossible and causes a reliability nightmare.

Having tool, implementation, and portal functionality placed into separate web applications allows a far superior model of extension and fits well with the JSR-168 and Portlet needs. However, there are several technical challenges that come from separating the overall application into separate web applications:

  • A tool or service in one web application can call a service implementation where the code is operating in another web application. This requires that the service interfaces and the objects returned by the service APIs are placed in Tomcat's shared/lib area. There must be a way to "find" the implementation using service location or service injection (described below). Sakai has a cross-web-application component manager that is based on Spring that facilitates these cross-web-application lookups.
  • When multiple web applications are operating in the normal way, each has a separate Tomcat session. Tomcat tracks these sessions and expires the sessions independently for each web app. In a portal environment where some web applications are not "visible" (i.e. not active), their sessions will expire. There are two solutions to this problem (1) share a session across web applications or (2) have a heartbeat which causes each web applications to "touch" their session to keep it from expiring. Sakai is using the shared session across web applications initially using a tunneling approach pioneered by Jakarta Pluto and is investigating using the heartbeat approach in the future.

The Sakai Java framework solves both of these problems so that the multiple web applications can operate together as an application.

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.