Sakai Architecture

1
Sakai Architecture

• Charles Severance / Glenn Golden
• University of Michigan

2
Sakai Deliverables

• Tool Portability Profile - A book on how to write
  Sakai-compliant services
• Tool Functionality Profile - A book on the
  features of the Sakai-developed tools
• Sakai Technology Release - O/S LMS
• Sakai Technology Framework
• Sakai Tools and Services
• Integration, QA, and Release Management

3
CHEF 2 Changes

• uPortal replaces Jetspeed
• Enhanced to support the (jsr 168) Portlet 1.0
  standard
• CHEF component framework (backed by Spring)
  replaces Turbine
• Service Locator and Dependency Injections
  supported (IoC type 2,3)
• OSID Loading supported
• Services Design Pattern unchanged
• OKI OSIDs and full reference / production
  implementations
• Current CHEF services deprecated or re-packaged
  as new OSIDs
• still available for legacy support
• compatible with the new OSID services (i.e. Agent
  User)
• New Tool Design Pattern
• Based on Java Server Faces
• New component Packaging
• Based on Java Web Applications
• Hot deploy of tools service components

4
Sakai Thorny Issues

• How to handle many repositories (Dspace, Fedora,
  JSR-170) though one API?
• How to store information in a way that is both
  efficient/fast and flexible/reusable - perhaps
  RDF/URI is a unifying approach to finding and
  reusing content?
• How to take the OKI APIs and add sufficient
  detail (out-of-band-agreements) so as to make it
  clear how to write tools?
• How to make AUTHZ scalable, fast, portable, and
  interoperable?

5
Federated Interfaces
OKI/Sakai
Tool I
Federated DR API
Local DR API
DSpace DR API
Fedora DR API

DB
Fedora
DSpace
6
Use an Object Store?
External Portfolio Tool
Tool
AUTHZ
AUTHN
DRAPI
Object Store
RDF/URI
7
Use RDBMS?
External Portfolio Tool
Tool
AUTHN
AUTHZ
DRAPI
RDBMS
????
RDF/URI
8
RDBMS RDF APIs
External Portfolio Tool
Tool
AUTHN
AUTHZ
DRAPI
RDF/URI
RDBMS
Until we are sure based on development experience
- this will be TBD - One thing for sure - we will
not sacrifice performance for architectural
elegance
9
Out-Of-Band Agreements
OKI does not specify many schema details for lots
of objects to maintain flexibility. The OKI API
leaves these details to be worked out between the
tool developers and the OSID implementers. The
Sakai project will decide on these schema-like
issues and publish them. But dealing with
schemas directly is often painful and leads to
thick and hard-to-modify tools.
Tool
AUTHZ
AUTHN
DRAPI
Object Store
10
Façade/Schema/Semantic Layer
Sakai will define build convenience classes
(facades ) which enforce semantic details of the
Sakai out-of-band agreements on the OKI APIs.
Not all OKI APIs will have facades, Applications
will be able to communicate directly with the OKI
APIs as necessary, the façade mapping may not
always be one-to-one. Specs like IMS and LOM
will influence these schema decisions within
Sakai. The goal is to keep tools easy, clean,
and portable. Because the façade classes use OKI
APIs, they can move into non-Sakai OKI compliant
environments.
Tool
org.sakai
org.sakai
AUTHZ
AUTHN
DRAPI
Object Store
11
Service Component
Service Component
Service Component
Service Component
Services Pattern
Service APIs
Component Framework
Tool Pattern
Application Configuration
Tool Framework (CHEF enhanced JSF)
Servlet
Portlet
JSP
JSF
Tomcat
uPortal
12
Service Design Pattern
Services Pattern

• Separation of concerns
• Tools to handle user interactions
• Services to handle specific functional, business
  logic, data type modeling responsibilities
• Dependent on interfaces, not implementations
• Clients dynamically bound to implementations by
  API
• Major service or manager API with most methods
• Supporting core interfaces for the data entities
  modeled
• Implemented by many different components

13
Service API
Service APIs

• OKI OSIDs
• Rich common services
• CHEF 1.x Services
• Higher level feature specific
• Becomes OSIDS, merges with the OSIDS
• New high level (org.sakai.) OSIDS
• Packaged with new feature sets / tool suites

14
Component Framework

• Container for all service components, possibly
  for tool components
• Support many design styles
• Service Locator - a component manager to find
  dependent service components by api name
• Injection - (IoC type 2, 3) - support for
  auto-wiring and configuration through bean
  setters and constructors
• Life-style and Lifecycles
• shared instance, instance per thread, instance
  per usage
• init and destroy methods, possibly others
• Configuration driven
• Component selection for each API
• Configuration values

Component Framework
15
Service Components
Service Component

• Implement one service API and related core
  interfaces
• Dependent on other service APIs
• Implement other aspects
• Authorization, Event tracking, etc.
• Implementation choices
• POJO (plain old java object)
• Resolve dependencies via Injection or Locator
• J2EE Enterprise Beans
• Selected and configured by the application

16
Application Configuration
Application Configuration

• Select a service component for each needed
  Service API
• Configure each component
• Multiple configurations - many packages
• Hot modify configurations (w/ new package
  deployment)

17
Tools

• Orchestrates user interaction
• Present user interfaces (Views)
• Process user requests
• Tracks interaction state
• Responsible for an area of functionality
• Chat, Announcements, Schedule, Resources
• Java classes
• designed to the Tool Pattern
• Static file resources
• png, css, jsp, etc.
• Heavy lifting done by services
• Common services
• Custom services
• Dependent on service API, not implementations

18
Tool Design Pattern
Tool Pattern

• Based on Java Server Faces
• Support abstract high level UI components
• button, menu, text field, alert, table
• Support action model
• Support view selection
• Support interaction state
• Support multiple user agents (browsers) skins
• different renderers
• Configurable by placement instance
• portal
• Achieve our goal of cross tool interface
  consistency Skins

19
GUI Java Server Faces
Render
Service API (OSID)
20
Tool Framework
Tool Framework

• To support the tool design pattern
• Based on Java Server Faces
• Extended with our own special
• UI Components
• Renderers
• Extensions classes to Servlet and Portlet
• Utilities
• Third party packages (velocity, JSF, etc).

21
Navigation

• Like Tools, present UI and handle requests
• Getting around to specific tool instances
• Tools organized in spaces Sites
• Multiple tools per page Portal
• Other modes
• Portal Navigation
• Access Navigation
• URL access to resources.

22
Packaging

• Based on standard java Web Applications
• .war files
• Tool, Tool Suite
• Service Components
• No code change to add new package
• Possible Hot Deploy

23
Standards
Servlet
Portlet
JSP
JSF

• Servlet
• JSP
• Portlet
• JSF

24
Portal Engine
Portlet
uPortal

• uPortal 3
• Enhanced with Portlet support
• Support for others possible
• standard Portlet (JSR 168) portal engines
• Open Source (i.e. Jetspeed 2)
• Commercial (i.e. WebSphere)

25
Portlet Servlet Model
Portlet
Servlet

• Portlets for navigation, tool placement, tool
  configuration, usage sessions
• Servlets for popups and popins
• Tool content without the portal decorations
• New windows, iframes in portal windows
• Servlets for JSF
• included from the standard CHEF JSF portlet
• Servlets for other navigations
• Access, authentication, management, etc.

26
Summary

• We have a long way to go and a short time to get
  there
• The team we have assembled is the key - each
  institution brings deep and complimentary skills
  to the table
• Previous collaboration (Navigo, OKI) over the
  past few years has developed respect, teamwork,
  and trust from the first day of Sakai
• We are taking some time at the beginning to
  insure genuine consensus and that we truly make
  the right choices in the framework area.
• We understand that we may make mistakes along the
  way and have factored this into our apprach and
  resource allocation.
• So far everyone has had an open mind and
  understands the good of the many