Transcript 2004_02_19_stanford_.. - Personal

Sakai Architecture
Charles Severance / Glenn Golden
University of Michigan
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
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
Sakai: Thorny Issues
• How to handle many repositories (Dspace, Fedora, JSR170) 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 (outof-band-agreements) so as to make it clear how to write
tools?
• How to make AUTHZ scalable, fast, portable, and
interoperable?
Federated Interfaces
OKI/Sakai
Tool I
Federated
DR API
Local
DR API
Fedora
DR API
… DSpace
Fedora
DSpace
DR API
DB
Use an Object Store?
External
Portfolio
Tool
Tool
RDF/URI
DRAPI
Object Store
AUTHZ
AUTHN
Use RDBMS?
External
Portfolio
Tool
Tool
RDF/URI
DRAPI
????
RDBMS
AUTHZ
AUTHN
RDBMS + “RDF” APIs
External
Portfolio
Tool
Tool
AUTHZ
AUTHN
RDF/URI
DRAPI
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
“Out-Of-Band Agreements”
Tool
DRAPI
Object Store
AUTHZ
AUTHN
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 schema’s
directly is often painful and leads
to thick and hard-to-modify
tools….
Façade/Schema/Semantic Layer
Tool
org.sakai
org.sakai
DRAPI
AUTHZ
Object Store
AUTHN
Sakai will define build convenience
classes (facades …) which enforce
semantic details of the Sakai out-ofband 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 nonSakai OKI compliant environments.
Service
Component
Service
Component
Service
Component
Service
Component
Component Framework
Services
Pattern
Service APIs
Tool
Pattern
Tools
Access
Navigation
Application
Configuration
Tool Resources
(jsp, css, png. …)
Portal
Navigation
Tool Framework (CHEF enhanced JSF)
Servlet
JSP
Tomcat
Portlet
uPortal
JSF
2
Services
Pattern
Service Design 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
Service APIs
Service API
• 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
Component Framework
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
Service
Component
Service Components
• 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
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)
Tools
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
Tool
Pattern
Tool Design 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
GUI: Java Server Faces
get…()
set…()
processAction…()
view
Render
Service API (OSID)
tool_bean
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).
Access
Navigation
Portal
Navigation
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.
Packaging
• Based on standard java Web Applications
– .war files
•
•
•
•
Tool, Tool Suite
Service Components
No code change to add new package
Possible Hot Deploy
Servlet
JSP
Portlet
JSF
Standards
•
•
•
•
Servlet
JSP
Portlet
JSF
Portlet
uPortal
Portal Engine
• 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)
Portlet
Servlet
Portlet + Servlet Model
• 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.
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…”