Mark Norton presented the following, supported by powerpoint slides:
sepp-technical-0605-baltimore.ppt
sepp-integration-0605-baltimore.ppt
Sakai Technical Overview, Welcome
Overview: There are two talks here: Quick tech overview, What's new in Sakai 2.0, How you can get involved
What is Sakai, Collaboration Learing Environment, Platform , and also a bundled product
What is a framework: hosting environment for user-programmable parts inside
What is an architecture: Abstract, layered.
What a meeting like this does is allows us to synch up our term usage, common terminology.
From the architecture, we build a framework: Sakai framework.
Sakai 2.0
Sakai 2.0. We have an RC 2 as of Monday. cvs.sakaiproject.org/release/ Bunch of new stuff. Architectural differnces. Completely new kernel. The kernel supports launching web application, session, context, threads, properties, service injection.
Service transition. Legacy services move forward to become modern services. Also new common services.
Portals: Charon and Mercury.
New Kernel Features
New Kernel Features:
Login, AuthN redone. User sessions and context: easier to use, more standards based, good documentation. Tool placement: user, tool, and where that tool lives. Component and app registration. Dependency injection via Spring.
Legacy services start to migrate.
List of legacy services: lots of them.
Tools built upon services.
Providers: a way to "look someplace outside Sakai" for data.
One particular provider approach: using a well-defined database schema intermediary.
New Common services:
AuthZ, super structure, course management. Enable hierarchical site organization and improve integration.
Portals:
Sakai will continue to offer its own portal. Two new portals in Sakai 2.0. Also working towards support for uPortal. WSRP.
Charon
Charon: the new version of the Sakai portal that supports flat worksites and legacy AuthZ.
Mercury
Mercury: development portal new in Sakai 2.0. Allows tools to be accessed independently. No more need for tunnelled access.
Astro
Astro: What's coming. Will be default in Sakai 2.1 (or some future release). Will support hierarchical organization. Will use the new AuthZ service. Reflected in admin tools.
uPortal
Adding WSRP support to Sakai (for IMS TPP project).
Key services in Sakai revealed via WSRP.
Still has a long way to go.
Interested: get involved.
Getting involved in Sakai
Sakai is community based open source dev effort: means that we need many people to be involved. This means you. Not everyone needs to be a developer: DBA, Doco, QA, UI, ... We need people to be involved and contribute and talk about Sakai. Strength in diversity.
Kinds of Sakai development:
- Framework dev: core
- Service dev: specialists
- Tool dev: general
- UI design: HCI specialists
- DB migration: DBAs, etc.
- Skins and style sheets: designers
Framework development
- Chuck, Glenn, Lance, Craig and others will continue to work on the Sakai Framework.
- However, there's room for additional contributors
Service development
User centric design
inside vs. outside (and continuum)
Some tools remain "outside" Sakai as posted contributions, whereas some tolls / plugns become "real" Sakai tools that get drawn into, rolled into the core Sakai deliverables. More Sakai architecture, aesthetics, user centric design applies to tools/plugins on the path to come into core Sakai deliverable. (All this is likely a good idea for "outside" work, but whatever anyone can post anywhere to contribute, contributes). Question from audience about how this works. Process under development.
Gradebook example: because a key, core tool in Sakai, adherence to process more important. The more central to mission, the closer to the core Sakai deliverable, the more of the Sakai community standards and scrutiny applies.
Governance
A focus of this conference.
Mellon funding ends end of this year, so setting up governance for continuation past the end of Mellon funding.
Start a Working Group
DG for discussion, WG for producing code.
CVS process
server cvs.sakaiproject.org
scratch for public contribution of prototypes
contrib for completed contributions
Quality Assurance
Please help by volunteering to do QA. In everyone's interest.
Bug tracking
Docuemntation
- KnowledgeBase at Indiana
- SakaiPedia
- Published docs, report
Questions and answers
How are you testing Sakai?
Carol Dippel / QA. Nightly test scripts. Nightly build. JIRA issue tracking. Gearing up for load testing.
Migration utilities
Yes. See Migration DG.
Integrating tools vs. integrating services
Integrating services rather than integrating tools: Tool A doesn't need to use Tool B, it needs to use the service behind Tool B.
Helper model. Tool A invokes tool B as a helper, via the API.
Sakai Enterprise Integration
Overview
Architectural review, Approaches to integration, service integration points, development considerations
Integration down at the services layer.
Service replacement
Most control, most work. A whole new implementation against the service API.
Providers
A way to "look someplace else" for data. A smaller API than the whole service, to implement and plug into the service. User directory information as a good example. New approach of providers against well defined intermediary db schemas.
Synchronization tools (utilities)
Periodically pull data from remote service/database into Sakai.
Legacy service overview
Remnants of CHEF, will likely be with us for a long time even as some are being modernized, many of them.
Integration points
- Course management
- User
- content
- authz
User / Person
Legacy User and Person objects convey user demographics, group membership.
Users
Legacy user service can access directories (e.g. LDAP). A number of successful LDAP integrations accomplished
Authorization
Legacy CHEF security system in place in Sakai 2.0, including Realms
Content hosting
file and attachments, will be enhanced post Sakai 2.0. Supports Web DAV.
File space integration.
Common Services Overview
Support new requirements derived from gap analysis.
Common service integration.
Authz, related default implementations.
Super structure.
Course objects, repositories
Development tools
Maven for build. Eclipse as a wonderful IDE. JUnit testing for QA. CVS for sharing contributions (and before they become contributions, for scratch work). Document in Sakaipedia, if you like.
Sakai design patterns
- Layered service architecture
- Code to Interfaces
- separation of presentation from application logic
- beans and DAOs (data access objects)
- ORM (object relational mapping) based on Hibernate
- Database and OS independence
Share your integration code
Post to CVS
post module under contrib
Wiki space
DG / worksite on collab.sakaiproject.org for Enterprise (integration) considerations.
Collaborative development
Collaboration is excellent when there's others in the same boat and there's potential for beneficial collaboration. Some work done collaboratively, sometimes you just wander off and write the very custom tool, very custom code, for your local, particular, esoteric need.
For collaboration,
- You can use collab.sakaiproject.org
- SakaiPedia