monoliths, apis and extensability - the past and future directions of cms

37
Course Management Systems: Past, Present and Future Scott Leslie May 11, 2005

Upload: scott-leslie

Post on 18-Jan-2015

3.726 views

Category:

Business


0 download

DESCRIPTION

Invited talk for Simon Fraser University on future directions of CMS extensibility, presented June 2005

TRANSCRIPT

Page 1: Monoliths, APIs and Extensability - The past and future directions of CMS

Course Management Systems: Past, Present and Future

Scott Leslie

May 11, 2005

Page 2: Monoliths, APIs and Extensability - The past and future directions of CMS

Goals for the Presentation Discuss the state of CMS from the

perspective of

maximizing flexibility

while

preserving/increasing quality and services

(and at least maintaining costs)

Page 3: Monoliths, APIs and Extensability - The past and future directions of CMS

Outline

History/Context

Enterprise and ‘Standalone’ CMS

Service Oriented Architectures & the E-Learning Framework

Sakai, Open Source

Other Alternatives

Page 4: Monoliths, APIs and Extensability - The past and future directions of CMS

What do I mean when I use the term “Enterprise”

BUT FIRST…

Page 5: Monoliths, APIs and Extensability - The past and future directions of CMS
Page 6: Monoliths, APIs and Extensability - The past and future directions of CMS

Enterprise Systems….• too often has meant “large monolithic systems”• should mean “systems that are core to your

business”• in CMS world, is under pressure to transform

Enterprise Services….• system level services which provide a coherent

level of functionality across all applications and tie in with core administrative systems

Enterprise Service….• The levels and kinds of real “services” you wish to

provide to users

Page 7: Monoliths, APIs and Extensability - The past and future directions of CMS

Pre- & Early CMS Phase

1st Wiki developed

IU’s OnCourse

1993 19951994 1996

ToolBook

(Common Object Request Broker Arch.) 2.0

early explosion of the WWW

Page 8: Monoliths, APIs and Extensability - The past and future directions of CMS

‘Standalone’ CMS Mature

200019981997 1999

“Landonline”

WSDL 1.0 Published

1st Implementation of XML-RPC

XML W3C Recommendation

IMS Enterprise 1.0

WebCT 3 releasedBB 3

Released

Rapid growth of interest and adoption of initial CMS

Page 9: Monoliths, APIs and Extensability - The past and future directions of CMS

2001 200520032002 2004

‘Enterprise’ CMS Phase

‘Blogs’ explode as a phenomenon

Wikipaedia launched

Carnegie Mellon ‘elearning services stack’ diagram

The ‘E-Learning Framework’ released

2.0

1st OKI OSIDS

1.0

Page 10: Monoliths, APIs and Extensability - The past and future directions of CMS

Instructor 1

Tech Admin

Discussion Software

File Exchange

Instructor2

Email/MessagingAnnouncementsQuiz Software

Course 1Course 2

Course 3

-Creates new instance each time

-- People and Software don’t scale

-- No control by instructor

Pre-CMS Model

Page 11: Monoliths, APIs and Extensability - The past and future directions of CMS

Early Generation CMS

Instructor 1

Tech Admin

Discussion Software

File Exchange

Instructor2

Email/MessagingAnnouncementsQuiz Software

CMS ‘Wrapper’

Interact with set of tools on course by course instance

- Scales better

- Promotes silo’d model

- Restricts tool choices

Page 12: Monoliths, APIs and Extensability - The past and future directions of CMS

‘Enterprise’ CMS

Discussion Software

File Exchange Email/MessagingAnnouncementsQuiz Software

Tech Admin

Tech Admin

Instructor 1 Instructor2Instructor 1 Instructor2

Dept 1Dept 2

Provides:

-portal level services

-content reuse across courses, depts, institution

-multi-unit branding, logic

Distributed Unit Administration

Enterprise-wide Administration

Page 13: Monoliths, APIs and Extensability - The past and future directions of CMS

Current Adoption Rates

from Hawkins, Rudy and Madsen, “2003 Educause Core Data Survey,” http://www.educause.edu/ir/library/pdf/pub8001e.pdf

roughly 90% overall

Page 14: Monoliths, APIs and Extensability - The past and future directions of CMS

Current Situation in B.C.

19 of 27 institutions currently using WebCT

5+ homegrown systems

6-8 smaller institutions experimenting with Moodle

SFU signed up as SEPP ‘partner’ on Sakai

Page 15: Monoliths, APIs and Extensability - The past and future directions of CMS

How are Enterprise CMS different? Typically re-developed, re-designed and re-

architected Database-driven (and database-dependant) Improved ‘out of the box’ integration with other major

enterprise systems (SIS, Library) ‘Portal’ Functionality; extending into new parts of

organization; prospect of increased vertical integration

Multi-unit role, authorization and administration capabilities

Content sharing and reuse across course, department and institutional boundaries

Mature APIs to allow integration of 3rd party products

Page 16: Monoliths, APIs and Extensability - The past and future directions of CMS

BUT…

Page 17: Monoliths, APIs and Extensability - The past and future directions of CMS

Choices and Cost CMS, even ‘enterprise CMS,’ are often

criticized for lacking flexibility, requiring a ‘one-sized fits all’ approach

Even though they have APIs, these have not spawned an explosion of 3rd party or discipline-specific toolsWhose API do you build to?APIs only allow so much integration

and oh yeah…they’ve gotten pretty expensive

Page 18: Monoliths, APIs and Extensability - The past and future directions of CMS

Service-oriented architecture (SOA) definition

“A service-oriented architecture is essentially a collection of services. These services communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is needed.

“Service-oriented architectures are not a new thing. The first service-oriented architecture for many people in the past was with the use DCOM or Object Request Brokers (ORBs) based on the CORBA [Common Object Request Broker: Architecture] specification.”

from “Web Services and Service-Oriented Architectures,” http://www.service-architecture.com/web-services/articles/service-oriented_architecture_soa_definition.html

Page 19: Monoliths, APIs and Extensability - The past and future directions of CMS

E-learning frameworks Emerging high level frameworks that

outline ‘services’ needed to provide comprehensive e-learning architecture (larger than just CMS)

Early instances found in Carnegie Mellon’s ‘E-learning Stack”

Evolved into IMS Abstract Framework which inspiredJISC/Industry Canada E-learning Framework

(ELF)

Page 20: Monoliths, APIs and Extensability - The past and future directions of CMS

Carnegie Mellon’s Original Elearning Services Stack Diagram

Page 21: Monoliths, APIs and Extensability - The past and future directions of CMS

IMS “Abstract Framework”

Page 22: Monoliths, APIs and Extensability - The past and future directions of CMS

JISC’s “E-Learning Framework”

(cf. www.elframework.org/)

Page 23: Monoliths, APIs and Extensability - The past and future directions of CMS

OKI Open Service Interface Definitions (OSIDs)

“The OSIDs are an abstraction layer between the programmer and the enterprise infrastructure systems of his or her campus.

“This approach offers a number of important benefits to applications designed to the OSIDs:Simple integration with existing infrastructure Local innovations can be shared across

campuses or universities Adaptation to new technology without

destabilizing the overall environment”

from “OKI: About Specifications,” http://www.okiproject.org/specs/index.html

Page 24: Monoliths, APIs and Extensability - The past and future directions of CMS

OKI OSID diagram

Page 25: Monoliths, APIs and Extensability - The past and future directions of CMS

So what are the typical “Common Services?”

Page 26: Monoliths, APIs and Extensability - The past and future directions of CMS

Common Services across Frameworks and Systems

JISC Common Services

OKI Common Services

CHEF (Sakai 1.0) Services

Authentication Authentication Authentication

Authorization Authorization Authorization

Logging Logging Logging

Messaging Messaging Messaging

Filing Filing Filing and Resources

Scheduling Scheduling and Calendar

Workflow Workflow

Search Search

Types Roles

Identifier Identifier

Page 27: Monoliths, APIs and Extensability - The past and future directions of CMS

Put another way…When I access any e-learning tool,

• I should be automatically logged in with the appropriate permissions

• If the tool is a part of a larger ‘workflow’ it should be able to contact me in my desired locations

• I should be able to schedule activities with the tool and by the tool

• If it’s searchable I should be able to search it from wherever I want

• it should report my usage back to a useful location in an actionable way

Page 28: Monoliths, APIs and Extensability - The past and future directions of CMS

Sakai Sakai 2.0 released June 2005 Promise of Sakai: To deliver both an “application

framework and associated CMS tools”

Current ‘Reality’ Starting with a number of homegrown products (Coursework,

OnCourse, Stellar …) and are trying to bring these into a new framework

Early releases (1 & 1.5) look mostly like just another CMS Upcoming 2.0 release, along with proof-of-concept demos with

Navigo assessment tool, Sakai and Vista, will be a major milestone

Page 29: Monoliths, APIs and Extensability - The past and future directions of CMS

Tool Portability Profile “The ultimate goals of the Sakai Tool Portability Profile

and the Sakai Java Framework is to provide an environment where tools and the services to support those tools can be dropped in as "units of expansion" or "building blocks" as to allow an organization to assemble the componentized units of functionality together to solve their particular application problem.”

In theory, a profile of the OKI OSIDS would an OPEN standard for tool integration, not just with Sakai, but with other OSID implementers

In practice, early releases have relied on internal Sakai API for much of the integration

Page 30: Monoliths, APIs and Extensability - The past and future directions of CMS

Other Open Source http://www.edtechpost.ca/pmwiki/pmwiki.p

hp/EdTechPost/OpenSourceCourseManagementSystems currently lists at least 46 known OS options

ATutor• developed out of U of T• SCORM and IMS CP support; integration with

TILE repository• PHP-based• currently “watching” OKI but hesitant about

adopting before benefits are clear

Page 31: Monoliths, APIs and Extensability - The past and future directions of CMS

Other Open Source II Moodle

originated as PhD project by Australian aimed at a CMS to support more constructivist style education

currently “many hundreds” of adoptions SCORM and IMS CP support; repository in development;

supports Shibboleth and CAS authentication PHP-based currently “watching” OKI and TPP/TIP but hesitant about

adopting before benefits are clear

.LRN developed at MIT on top of existing OpenACS Portal technology recently acknowledged by ADL as SCORM capable supports Unix PAM and LDAP authentication written in TCL

Page 32: Monoliths, APIs and Extensability - The past and future directions of CMS

Loosely coupled or alternative approaches

Page 33: Monoliths, APIs and Extensability - The past and future directions of CMS

Important Recent Announcements WebCT chairing IMS Tools Interop group (

http://www.webct.com/service/viewcontentframe?contentID=25561480)

IMS to partner with OKI on next OSIDS (http://www.imsglobal.org/pressreleases/pr050413.cfm)

IBM partners on Sakai project (http://www.umich.edu/news/?Releases/2005/Apr05/r042605a)

WebCT Campus Edition 6 Public Beta Commences (http://home.businesswire.com/portal/site/google/index.jsp?ndmViewId=news_view&newsId=20050425005245&newsLang=en)

Page 34: Monoliths, APIs and Extensability - The past and future directions of CMS

Important Upcoming Milestones Sakai 2.0 release

Mid-June 2005

Alt-i Lab 2005 Tools Interop Demo between WebCT, Sakai, QuestionMarkJune 20-22 in Sheffield, UK

Sakai 3.0 release end of 2005

Page 35: Monoliths, APIs and Extensability - The past and future directions of CMS

Recent ‘Relevant Read’Rebecca Sausner, “Course Management:

Ready for Prime Time,” in University Buisness, May, 2005. http://www.universitybusiness.com/page.cfm?p=791

Compares 4 large institutions with 4 different CMS implementationsMarshall U. – WebCT VistaU of Cincinnati – Blackboard EnterpriseU Michigan – SakaiBerry College - Jenzabar

Page 36: Monoliths, APIs and Extensability - The past and future directions of CMS

SOAs and Workflow http://www.e-framework.org/SOAandWorkflow2.pdf

“This does, however, raise one potential issue around workflow for web services: the need for service specifications to be written with workflow in mind... This means that anyone thinking of deploying a web service that may be used within an automated workflow really needs to consider, in advance, the needs of the workflow system when designing the service interface. Because workflow, like security, is heavily dependent on the deployment choices made in an implementation environment, generalization and standardization of “workflow-aware” services may prove problematic. “

cf. also OKI Workflow OSID, at maturity level 1 - http://www.okiproject.org/specs/osid_17.html

Page 37: Monoliths, APIs and Extensability - The past and future directions of CMS

Food for Thought Is it possible to achieve “enterprise quality service” without

imposing or assuming a well-defined, hierarchical structure?

What are the other pieces of the envisioned learning environment, in addition to a CMS, and how should these interact with the CMS?

What level is the appropriate level to standardize at? Course? Instructor? Program? Department or Faculty? Institution?

And WHAT, specifically, is it important to standardize on?