sakai content integration strategies dan mccallum sakai winter conference, dec 7, 2006 © copyright...

Sakai Content Integration Strategies

Dan McCallumSakai Winter Conference, Dec 7, 2006

© Copyright Unicon, Inc., 2006. This work is the intellectual property of Unicon, Inc. Permission is granted for this material to be shared for non-commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of Unicon, Inc. To disseminate otherwise or to republish requires written permission from Unicon, Inc.

1. The Content Problem

2. Transformative Integrations

3. Proxied Integrations

4. Conclusions

The Content Problem

The Content Problem

• Can Sakai deliver content bundled in Archive Format ABC? How do I move my content from System X to Sakai?

• What kind of content?

• Are we talking about content, functionality or both? What about system state?

• Validity of a content integration solution is context-specific

• Migration and Integration – distinct concepts

Transformative Integrations

Transformative Integrations

• Characterized by:

– Mapping external content onto Sakai-native data

structures

– One-time or periodic data synchronization;

offline/batch file processing

– Content delivery via Sakai-native tools and UIs

– XML “packages”

Transformative Integrations

• Appropriate when:

– Migrating users and/or content from another LMS

to Sakai

– Acceptable delivery tooling already exists in the

LMS

– Content does not change rapidly or can be

completely owned by the LMS

– Loose centralized content hosting requirements

Transformative Integration Example:Sakai Archives

Sakai Archives

• Site-oriented import/export using legacy Sakai XML schema.

• Primarily intended for intra-Sakai content reuse rather than cross-platform data interchange

• Support varies from service to service – can be difficult to predict import/export symmetry

• Recently added configurable service and role filters

Sakai Archives Pro/Con

• External content packages could be transformed to Sakai-native archives

• Relatively low risk: maximizes re-use of existing archive consumption code

• Archive schema itself is unpublished (except in Java code); widespread adoption unlikely

• What would a more robust archive service entail? Enter Zach Thomas and the MIG group…

Transformative Integration Example:ImportService

ImportService

• An architecture for format-agnostic inbound

content package handling

• Implementations parse, validate and import

data feeds to Sakai-native objects.

• Development tracked by Migration WG

(http://bugs.sakaiproject.org/confluence/displ

ay/MIG/Home)

ImportService

• Separation of concerns:

– Decouples data interchange formats from core Sakai services and entities

– Decouples object import operations from core Sakai service interfaces

• Fine-grained extensibility

• Flexible deployment/configuration model

• IMS and vendor-specific interchange formats

– Sakai native archive and IMS Common Cartridge 1.0 parsers in trunk

– Bb 5.5, 6, Web CT CE parsers available in contrib

Image courtesy of Mark Norton (http://bugs.sakaiproject.org/confluence/display/MIG/Archive+Service)

ImportService – Improvements?

• Plug-in auto-registration

• Export

• Error handling, rollback

• Automated tests

• ‘Dry run’ mode

• Published archive format support document

• UI-configurable IMS parsing

Transformative Integration Example:Melete

Melete CP Support – Upsides

• Demonstrable LAMS integration via IMS CP

(http://bugs.sakaiproject.org/confluence/displ

ay/MIG/Melete+and+LAMS)

• Straightforward UI

• Easily reusable content -- Unicon has used

Melete IMS CP for replicating Sakai training

materials across multiple Sites

Melete CP Support – Downsides

• Limited support for inlined exams, complex sequencing, meta-data…

• No content change synchronization workflow

• Silo-ed infrastructure: IMS CP de/serialization implementation not easily reused by other Sakai services

• Vendor CP profiles not supported architecturally (WebCT CP support via out-of-band XML transforms)

Transformative Integration Example:Samigo

Samigo

• Traditionally, QTI import/export embedded

exclusively in the tool and its services

• Sakai 2.3 distro includes a ‘SamigoHandler’

which can be registered with the

ImportService for consumption of inbound

QTI documents.

• UC Davis recently added question pool import

to the UI. (2.1.x, 2.4)

Transformative Integration Example:OCW

OCW

• Ambitious content export project, focused on Sakai->eduCommons integration

• OCW sites are generated from IMS CPs

• Theoretically, this architecture should overlap with the abstract Import/Export model above

• The overhead associated with OCW export illustrates some of the drawbacks of transformative migration – moving data between delivery engines comes at a price.

Proxied Integrations

Proxied Integrations

• Characterized by:

– Aggregated content delivery rather than content

ownership.

– Delegation to best-of-breed rather than tight

integration

– Application-to-application interaction rather than

periodic data synchronization

– Sakai as portal rather than applications suite

– Messaging rather than packaging

Proxied Integrations

• Appropriate when:

– Content requires sophisticated delivery tooling which is not tightly integrated with Sakai.

– Data transformation/synchronization is prohibitively complex and/or adds little value

– Content already available in convenient, standards-based, LMS-agnostic, feature- and meta-data-rich, online environment (e.g. a digital repository)

– Scalability/up-time considerations recommend distributed tool deployments

Proxied Integration Example:WebContent

WebContent

• Simplest application “integration” strategy

• Sakai authZ and context may not map well

• Potentially disruptive user experience

• iframes can be annoying (XSS JavaScript errors, erratic back-button behaviors)

• Wisconsin’s JSR-168 version of CWebProxy might be a candidate alternative to iframes

• uPortal implementors (MUN, Yale, Chico, Johns Hopkins) have been successful with heavy use of the WebProxy channel

Proxied Integration Example:RSS

RSS

• Sakai ships with an RSS reader tool (aka “News”)

• If external data can be published as an RSS feed, Sakai users can access it.

• Simple, well understood technology

• Appropriate when external content conforms conceptually to a ‘feed’ model.

• Delegates delivery of “heavy weight” content objects to external systems

• Sakai as a portal-style dashboard onto enterprise application events (registrar add/drop reminders?), course-specific content feeds, etc.

Proxied Integration Example:Direct External Links/SSO Gateways

Direct External Links/SSO Gateways

• Provide users with a value-added links from a Sakai

context to an external application

• Another low-complexity alternative to data

synchronization or full-blown application integration

• Rutgers LinkTool formalizes this approach – helps

pass context and authZ assertions to external

applications

• Lightweight Sakai-Elluminate integration has been

demonstrated with this approach

Virtual Content Hosting

Virtual Content Hosting

• Enhance Sakai content hosting capabilities to transparently expose externally-maintained data

• Provide virtualized fine-grained views onto complex, coarse grained content blobs.

• Register content handlers or launchers to present users with the appropriate delivery environment, e.g. a SCORM player connected to a tracker service.

• Sakai architecture plug: CHS implementation is completely swappable. (Highly) motivated institutions can always reinvent CHS to support their specific needs.

Virtual Content Hosting Examples

• See Ian Boston’s proposed architecture on the Sakai

wiki

• Portland State University elected to host some

content in Hive during WebCT-Sakai migration

• Non-CHS variations also possible. Yale wrapped a

thin authZ enforcement tool around legacy Classes

web content.

Virtual Content Hosting – Upsides

• Reduces risk of data transforms

• Allows for arbitrary resource re-use (i.e.

content need not be mapped to ‘canonical

Sakai entities’)

• Ensures long-term course content

accessibility and portability

• Leverages investments in dedicated digital

content repositories.

Virtual Content Hosting – Downsides

• Potential latency problems

• Complex configuration

• Searchability?

• CHS bottlenecking?

Distributed Tooling

Distributed Tooling

• Sakai tooling acts as (hopefully) lightweight facades encapsulating interactive access to external applications and data.

• A Sakai tool renders distributed application responses in a Sakai-appropriate fashion.

• IMS TIF (Tool Interoperability Framework) and WSRP – may or may not be viable in the short term

• Sakai-LAMS distributed integration has been demonstrated with lightweight web services

• Cambridge FlowTalk: highly sophisticated distributed tool integration w/ custom wire protocol

Distributed Tooling – Upsides

• From TIF literature: "Most tools/applications

are NOT going to be ported into … Sakai...

and/or Blackboard... and/or WebCT.“

• LMS scalability and uptime enhanced by

distributed computing load, memory footprint

and data storage requirements

• Allows for consistent user experience across

a range of best-of-breed tools

Distributed Tooling – Downsides

• Latency

• Development, deployment and support

complexity

• Unproven standards

Conclusions

Modes of Integration

Transformative Proxied

Migrate Integrate

Own Aggregate

Import/Export Query

Producer/Consumer Peers

Data Applications

Synchronize Delegate

Local Distributed

Application Portal

Packages Messages

Destination Gateway

Summary and Conclusions

• Major advances in Sakai content import/export for v2.3, 2.4 Should reduce historical barriers to Sakai adoption.

• Migration is great, but…

• Can we actually deliver more value to users by treating Sakai as a portal or dashboard rather than a destination?

• Distributed tooling can expose arbitrary best-of-breed apps to Sakai while potentially addressing scalability issues

• You may not need heavy-weight remoting technologies and standards (TIF, WSRP) to implement distributed tooling or expose already web-enabled content

• What about library content? Integration can have highly specialized requirements. Anticipate some flavor of virtualized content hosting-based integration.

Dan McCallumdmccallum@unicon.net

www.unicon.nethttp://www.unicon.net/support_1089.html

Questions?