Sakai Content Integration Strategies Dan Mc Callum Sakai

Sakai Content Integration Strategies Dan Mc. Callum Sakai 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: Import. Service

Import. Service • An architecture 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/displa y/MIG/Home)

Import. Service • 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)

Import. Service – 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/displa y/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 (Web. CT CP support via out-ofband 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 ‘Samigo. Handler’ which can be registered with the Import. Service 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->edu. Commons 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-datarich, online environment (e. g. a digital repository) – Scalability/up-time considerations recommend distributed tool deployments

Proxied Integration Example: Web. Content

Web. Content • Simplest application “integration” strategy • Sakai auth. Z and context may not map well • Potentially disruptive user experience • iframes can be annoying (XSS Java. Script errors, erratic back-button behaviors) • Wisconsin’s JSR-168 version of CWeb. Proxy might be a candidate alternative to iframes • u. Portal implementors (MUN, Yale, Chico, Johns Hopkins) have been successful with heavy use of the Web. Proxy 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 Link. Tool formalizes this approach – helps pass context and auth. Z 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 Web. CT-Sakai migration • Non-CHS variations also possible. Yale wrapped a thin auth. Z 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 Flow. Talk: 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 Web. CT. “ • 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 v 2. 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.

Questions? Dan Mc. Callum dmccallum@unicon. net www. unicon. net http: //www. unicon. net/support_1089. html