Embed Size (px)
Citation preview
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.
