Open Knowledge Initiative. Data Specifications – IMS/SCORM Enterprise Application A Enterprise Application B Data.

Open Knowledge Initiative

Data Specifications – IMS/SCORM

EnterpriseApplication A

EnterpriseApplication B

Data

An ApplicationBefore OKI

OKI in a Nutshell


An ApplicationAfter OKI

Tool and Implementation Portability

CourseWork and Stellar

Demo – Filing API

Provides Abstraction Boundary Between Application and one or more “file directories” known as “Cabinets.”

Application

Local and Remote Cabinets

File Sync.Demo

File Synchronization Demo

Client UI Same code on Mac, Windows, Linux Rich User Experience Supports Disconnected Use

Different Byte Stores/Same application Local, Remote, AFS, IMAP – Go Crazy!

Application Portability

Possible Uses

Group Collaboration with multiple users synching to central file space

Group Collaboration using Specialized Tools Exploiting “Universal” File System

Add Authentication/Authorization for security, Logging to track activity, Workflow and Usermessaging to manage projects, etc.

More integrated authoring environments Other…

Development/Maintenance Effort as a Function of System Complexity

Eff

ort

Complexity

Common Service Spec Status

Authentication Authorization DBC Logging LocalID Shared Filing Hierarchy User Messaging Scheduling Workflow

0.9 – Public0.9 – Public0.9 – Public0.9 – Public0.9 – Public0.9 – Public0.9 – Public0.90.50.50.5

CS Implementation Activity

Current Activity: Authentication Authorization Filing DBC LocalID Logging Hierarchy

Required Activity: User Messaging Workflow Scheduling

OKI-In-A-Box

Educational Service Spec Activity

Class Admin Core Partner Engagment MITSIS Engagement

Content Management/Digital Repository Digital Library Community DSpace Engagement

Learning Asset Model Tool Model Assessment

OKI Application Activity

LMS’s Stellar – MIT CourseWork – Stanford University CHEF – University of Michigan Indiana University

Demo Apps Filing Demo Hierarchy Demo

Digital Library DSpace Fedora

Various Educational Tool Development

Core Institutional Partners

Cambridge University Dartmouth College MIT North Carolina State University Stanford University University of Michigan University of Pennsylvania University of Wisconsin

Specification/Standards Groups

Instructional Management Systems Global Learning Consortium

Advanced Distributed Learning Network DOD funded SCORM

See IMS/ADL/OKI Press Release

http://web.mit.edu/oki/news.html

OKI Architecture

OKI Services

Course MgmtContent Mgmt Assessment

AuthN

Etc…

LocalIdFileDBCAuthZ Hierarchy UserMessagingLogging Etc…

Etc… Etc…

SharedObjects

EducationalService

APIs

CommonService

APIs

Educational Service Implementations

Common Service Implementations

Educational Software“LMS”

Institutional Infrastructure

ClientObjects

ClientApps

ClientObjects

ClientApps

ClientObjects

WebApps

Browser

Browser

ClientObjects

WebApps

Browser

Browser

ClientObjects

ClientApps

OKI ServicesOKI ClientsCampus

Infrastructure

OKI Service Model

Assumptions

Things Change New Services & Functions Method of Accessing Services More Central Software Services

Authorization, Calendaring, etc.

Evolving Systems Definition

More Assumptions

All Enterprises won’t have the same Technologies

All Enterprise Systems won’t use the same Technology

The need for sharing will grow Differing “connectedness” Not Web only

Goals

Better Integration Allow data to be exchanged Allow software to be integrated

Predictable Evolution Allow for changing functionality Minimize the negative impacts

Expanding Market Possibilities

Possible Integration Goals

Allow enterprise systems to exchange & synchronize information

Allow different organizations to exchange & synchronize information

Allow systems to use enterprise services Allow for modular software which plugs

into a known framework Single System Responsible for Information

The API Approach

API are Interfaces only, not Implementations Code Reuse Could Achieve Real-time Integration Clean Separation or Boundaries Minimizes Impacts of Changes

Common Service Level APIs

Allows Integration with Enterprise Services Adapts to Multiple Standards Allows Several Sites to Share Services Independence from Changing Technology

APIs

Definitions

ExampleAPI

APIs

Definitions Implementations

Service

API

Implementation

Infrastructure

public class Factory implements org.okip.service.APIName.api.Factory { private static final blah blah bhal

private static final yada yada yada } …

Example

Service Based Architecture

public class Factory implements org.okip.service.Example.api.Factory { private static final blah blah bhal


ExampleAPI

…org.okip.service.shared.api.Thing things = myFactory.getSomething();

if (null != thingss) { for (int i = 0; things.length != i; i++) { out.println(things[i]); System.err.println(types[i]); } } …

Application

Implementation

Infrastructure

Service

Data and Functional Specification

Data standards serve two goals Data exchange inter/intra enterprise

Both Data & Function needed for all Goals Data duplication and propagation

data specifications can’t address all issues Both Needed for Interoperability

And more!

Systems Exchanging Data

System A System B

1 2

Systems Integrated Functionally

System A System B

2

Deployment Possibilities

One system using another systems service Framework & Component

System using enterprise service Allow for system to use service to hide:

Functions performed different places Different system responsible for data sets

Multiple OKI ServersSharing Common Infrastructure Services

SIS Data

Authentication/Authorization

Digital Repository

Messaging

Multiple OKI Servers Serving Different Content, But Sharing Some Enterprise Services

SIS Data


Digital Repository

SIS Data

Digital Repository

Kerb5

One Application Using Multiple Implementations of One API

X509

AuthN

App

Two Back End Systems –Single Access Method

Class Admin

EnrollmentApp.

SIS System HR System

Group Integration

Group Function Group Function

Group Service

System A System B

Implementation Supporting Multiple Protocols

API X API X

SRMI SOAP

Infrastructure ServiceSupporting both SRMI

And SOAP

Independent or Tightly Coupled Implementations

AuthN AuthZ AuthN AuthZ

Application A Application A

API Implementations May Call APIs

API 1 API 2

Application X

AuthN AuthZ DBCLUID

“LMS”

Varying Granularity of Service Exposure

Assess

Application Y

AuthN AuthZ

C.M. Etc.

AuthZ

Assess

Application Z

C.M. Etc.

Web Service Implementations?

WebService

X

SOAP

Imp.of X

API X

WS RegistryServer

UDDI

WSDL

App. A

APIs

Anatomy of APIs

What does an API look like? Java interfaces Factory interface Object interfaces Used for

Presenting services to applications Separating services from applications

Anatomy of APIs

What does an Implementation look like? Java classes Factory class Object classes Used for

Creating objects for an application Accessing “real” services

An API can have many implementations

Anatomy of APIs

How do APIs differ from frameworks? An API presents a service A framework tells you how to code An API can run in a framework A framework might be able to run in an API APIs are enabling APIs foster compartmentalization

Anatomy of APIs

How do APIs relate to other technologies? APIs allow the use existing software APIs do not dictate the implementation APIs do not dictate the application An application doesn’t need to use all APIs An application doesn’t need to use only APIs API impls only need a thin Java shim

Anatomy of APIs

Factories A mechanism to bind Implementations to APIs Are used by apps to get API impl objects Typical impl objects have factory references Factories have owners (Agents and Context)

Anatomy of APIs

Factories - How the code changes (Before) App getting an object instance

Athing a = new Athing(args); (After) App getting an API impl object

Afactory f = FactoryManager( apiPkgName, implPkgname, owner);

Athing a = f.createAthing(args);

Anatomy of APIs

Example application using an API and Implementation - Jeff Kahn

Anatomy of APIs

Agents and Context Factory owner is an Agent Agents

Implementation specific Application specific Out of band agreements Contain context Proxy - next Agent in context chain

Anatomy of APIs

Agents and Context Application context as owner

AppAgent appAgent = new AppAgent(context); Afactory f = FactoryManager(api, impl, appAgent); … AppAgent owner = f.getOwner().getProxy(AppAgent.class()); Context c = owner.getContext();

Implementation context as owner … Agent owner = someFactory.getOwner(); Afactory f = FactoryManager(api, impl, owner);

Anatomy of APIs

Authentication/Authorization Who are you?/What can you do? Close association Each is an API and implementation Each has session context Owner proxies can keep context

Anatomy of APIs

ROMI - remote object method invocation Client/Server with invoke method Example

public String toUpper( String s ) { if(hasClient()) { Class[] types = new Class[1]; types[0] = String.class(); Serializable[] args = new Serializable[0]; args[0] = s; String upCase = return getClient().invoke(this, “toUpper”, types, args); } return s.toUpperCase(); }

Anatomy of APIs

What does an API do for an architect? Compartmentalizes the code Hides implementation details Provides an abstraction layer Provides a way to change implementations Provides a specification mechanism Provides a way to spec app as a service Separates User Interfaces and services.

Anatomy of APIs

What does an API do for an programmer? Provides a clear specification Removes architectural detail Isolates the implementation Minimizes coupling between modules Maximizes cohesion Encourages writing for reuse

Anatomy of APIs

What does an API do for the dev manager? Allows tracking of progress

Is the API done? Is the Implementation done? Is the Implementation ROMI-ized? Who is working on the xyz implementation?

Provides a context for project metrics How’s the performance of the abc Impl? How many APIs/Implementations are done?

Anatomy of APIs

What does an API do for the CIO? Provides tracking and metrics Provides a way to cost integration Provides a way to cost development Provides a way to generate vendor requirements

“Your product must use this Authentication API” “Your product must implement the api API”

Opens a path for multiple vendor product use

Anatomy of APIs

What does an API do for the Vendor? Provides a way to create factored products Provides a way to use existing customer services Provides the customer with an upgrade path Provides a way to way to work with other

products

Interoperability and Conformance

Dimensions of Interoperability

Data Definitions

Technology Choices

UI/Application Frameworks

Service Definitions

Dimensions of InteroperabilitySe

rvic

eD

ata

UI

Tec

h

Gov.CorpHESchool

Open Knowledge InitiativeSe

rvic

eD

ata

UI

Tec

h

Gov.Corp.H.E.School

J

Data Agreement Among ProfilesSe

rvic

eD

ata

UI

Tec

h

Common

Interoperability ChoiceSe

rvic

eD

ata

UI

Tec

h

Gov.CorpHESchool

Conformance Conclusions

Interoperability is not easyTherefore:

Conformance will not be simple However:

We can make our lives better through intelligent choice and the company we keep.

OKI Strategic Efforts

Core Initiative CS and ES API Specs Reference Implementations Exemplar Applications OKI-in-a-Box 1.0 Communications/Marketing Sustainability Strategy

OKI Strategic Efforts (cont)

Spec. Maintenance and Conformance IMS?


Developer CommunitiesInitial Effort → Consortia(Web/Portal, Component, Vendor)

Outreach Coordination Consolidating Spec Change Requests

Voice for Maint and Conformance Dev Support, Training, Doc, Forum Conformance? IDE?


OKI in a box V2 (Consumers)Initial Build → Consortia/Vendor Support

Product Management Packaging/Installation Distribution Documentation Support Marketing

OKI Developer’s Network

Hosted by IMS See http://web.mit.edu/oki for more info

http://web.mit.edu/oki

End

Sustainability

Spec. Maintenance and Conformance

Development Community Web Client

MIT Infrastructure Build (one-time funding) Support Operate/Maintain

Consortium (IMS)

Consortium (?)

MIT

MIT-OKI Convergence

Libraries DSpace E-Reserves

“LMS” Stellar SloanSpace/.LRN

Educational Innovation Projects (e.g. iLabs, BCS, Teal, etc…)

Enterprise Applications MITSIS DSpace Coeus

MIT OKI Infrastructure

MIT-OKI Convergence

Libraries DSpace E-Reserves

“LMS” Stellar SloanSpace/.LRN

Educational Innovation Projects (e.g. iLabs, BCS, Teal, etc…)

Enterprise Applications MITSIS DSpace Coeus

MIT OKI InfrastructureFunding

InternalExternal

End

Stellar

OCW and Stellar: Fall 2002

OCWInt.

Web

OCW IP Restricted Content

OCW IP Cleared Content

Discussion Boards for OCW Internal

Other

OKI Digital Repository Services Impact on MIT Initiatives

DSpace

OCW

AFS+

Local

Stellar

OCWExt.Web

Bb

“Madagascar Institute of Technology”

= OKI “Content Management” API

Design Dimensions for Educational Applications

Technical Specs(W3C, IETFJava, I2, etc)

Interoperability Specs(IMS, ADL,

OCLC, OKI, etc.)

Learning Activity Design(?)

Philosophy

Service-based Infrastructure for Educational Software (Development and Delivery)

Driven Primarily by Higher Education Technology Requirements and Pedagogy

Open (low threshold for access/adoption) Collaborative (H.E., IMS, ADL) Enable Sharing of Instructional/Training

Applications Implementation Independent Service Definitions

Assumptions

Things Change New Services & Functions Method of Accessing Services More Central Software Services

Authorization, Calendaring, etc.

Evolving Systems Definition Boundaries

More Assumptions

All Enterprises won’t have the same Technologies

All Enterprise Systems won’t use the same Technology

The need for sharing will grow Differing “connectedness”

Goals

Better Integration Allow data to be exchanged Allow software to be integrated

Predictable Evolution Allow for changing functionality Minimize the negative impacts

Expanding Market Possibilities

EALP

Educational Activities and Learning Practices LMS Summit – April 2001 Needs assessment/scenarios Tool Definition Workshop – Oct 15, 16 OKIO LMS (sic) Summit II

Architecture Group

Primary team is at MIT Approximately 3FTE Provide bulk of day to day effort

Core partner designers Face to Face engagement every two months on average Critical input and contribution Competencies range from system design, instructional

application design, library systems

End of Part 1

Deliverables

1.x Version of OKI Framework Spec. Implementations of Framework APIs Collection of Exemplar Tools/Applications

(Including “LMS” Solution) Developer Community Strategy Sustainability Strategy

APIs

Definitions

ExampleAPI

APIs

Definitions Implementations

Service

API

Implementation

Infrastructure

public class Factory implements org.okip.service.APIName.api.Factory { private static final blah blah bhal


Example

Service Based Architecture

public class Factory implements org.okip.service.Example.api.Factory { private static final blah blah bhal


ExampleAPI

…org.okip.service.shared.api.Thing things = myFactory.getSomething();

if (null != thingss) { for (int i = 0; things.length != i; i++) { out.println(things[i]); System.err.println(types[i]); } } …

Application

Implementation

Infrastructure

Service

OKI Services


AuthN

Etc…

LUIDFileDBCAuthZ Rules UserMessagingLogging Etc…

Etc… Etc…

SharedObjects

EducationalService

APIs

CommonService

APIs





Example

public class Factory implements org.okip.service.authorization.api.Factory { private static final blah blah bhal


Authorization

…org.okip.service.shared.api.Type[] types = myFactory.getAuthenTypes();

if (null != types) { for (int i = 0; types.length != i; i++) { out.println(types[i]); System.err.println(types[i]); } } …

public class Factory implements org.okip.service.authentication.api.Factory { private static final blah blah bhal


Authentication



Assessment

Admit One

Same Application Using Different Implementations

Service 1 Service 2

Application A

Service 1 Service 2

Application A

Two Back End Systems –Single Access Method

Class Admin

EnrollmentApp.


Implementation Supporting Multiple Protocols

API X API X

SRMI SOAP

Infrastructure ServiceSupporting both SRMI

And SOAP

Kerb5

One Application Using Multiple Implementations of One API

X509

AuthN

App

Independent or Tightly Coupled Implementations

AuthN AuthZ AuthN AuthZ

Application A Application A

End of Part 2

Dimensions of Sustainability for OKI

Influence

Evolution

Conformance

Sustainability

Adoption

Support

End of Part 3

Influence and Outreach

Related initiatives/projects IMS/ADL Digital Library

Interest and Adoption Licensing Arrangements (IP) OKIO

OKI in a Nutshell


Thank You

Moving Ahead…

OKI in a Nutshell


An ApplicationAfter OKI

Logical and Schematic Models

API

App

API

Impl

emen

tati

onof

AP

I 1

App

Same Application/Different API Implementations (Modularity)

API 1 API 2

Application A

API 1 API 2

Application A

Different Application/Same API Implementations (Portability)

API 1 API 2 API 1 API 2

Application BApplication A

Two Back End Systems Supporting Single API

Class Admin

EnrollmentApp.


Example



Authorization

…org.okip.service.shared.api.Type[] types = myFactory.getAuthenTypes();

if (null != types) { for (int i = 0; types.length != i; i++) { out.println(types[i]); System.err.println(types[i]); } } …

public class Factory implements org.okip.service.authentication.api.Factory { private static final blah blah bhal


Authentication



Assessment

QuizID = “Chem100Final”

Assessment.getQuizElements(QuizID)

Admit One

Authorization. getAuths(myPerson,QuizID)

myPerson = Authentication.getAgent()

OKI Service Framework

Specifications


AuthN

Etc…

GUIDFileDBMSAuthZ Rules UserMessagingLogging Etc…

Etc… Etc…

EducationalComponent

APIs

CommonService

APIs

CommonObjects


Specifications Implementations


AuthN

Etc…


Etc… Etc…


APIs

CommonService

APIs



CommonObjectsInstitutional Infrastructure




AuthN

Etc…


Etc… Etc…


APIs

CommonService

APIs



CommonObjectsInstitutional Infrastructure

Data Exchange

EnterpriseSystem

EnterpriseSystem

EnterpriseSystem

Data Exchange

SIS LMS DigitalLibrary

Data Exchange

MITSISStellar

1.xDSpace

Service Framework

SISEducational

SoftwareServices

DigitalLibrary

CommonServices

Tools

Infrastructure

Service Framework

MITSISMIT

EducationalSoftwareServices

DSpace

MITCommonServices

Tools

Infrastructure

Stellar

Service Framework

SISEducational

SoftwareServices

Common Services

Tools

DigitalLibraryServices

Infrastructure


WebService

X

SOAP

Imp.of X

API X

WS RegistryServer

UDDI

WSDL

App. A


Imp. of X

API X

WebService

X

SOAP SOAP

Imp of X

API X

JavaC++

WS RegistryServer

UDDIUDDI

OKI BasedWSDL Spec?WSDL

App. AApp. B

WebServiceClient

Application

SOAP

API X

WebService

X

WS RegistryServer

UDDI

WSDL

Perl? C?

Web Service Applications?

Same OKI BasedWSDL Spec?

WebServiceClient

ApplicationSOAP

WebService

WS RegistryServer

UDDIWSDL

Web Service Applications?

WS ClientApp

API X

WS X

Registry

Web Service?

WS XRegistry

WS ClientApp

API X

WS X

Registry

Web Service?

WS X

Stellar on OKI

Stellar2.0

HTML HTML

Web Server

Web and Client App Interoperability

Stellar2.0

HTML

API Implementations May Call APIs

API 1 API 2

Application X

AuthN AuthZ DBCLUID

“LMS”

Varying Granularity of Service Exposure

Assess

Application Y

AuthN AuthZ

C.M. Etc.

AuthZ

Assess

Application Z

C.M. Etc.

API 1 API 2

Generic Rule Model

Subject

Verb

Predicate

Authorization Model

Agent

Function

Qualifier

Digital Rights Model?

Party

Right

Content

Learning Asset

LA

AuthorizationWorkflow

RightsEtc…

Stay Tuned




ClientObjects

ClientApps

ClientObjects

ClientApps

ClientObjects

WebApps

Browser

Browser

ClientObjects

WebApps

Browser

Browser

ClientObjects

ClientApps

OKI ServicesOKI ClientsCampus

Infrastructure

OKI Service Model

Multiple OKI Servers Serving Different Content, But Sharing Some Enterprise Services

SIS Data


Digital Repository

SIS Data

Digital Repository

Multiple OKI ServersSharing Common Infrastructure Services

SIS Data


Digital Repository

Messaging

OKI Processes

Common Services

OKI/LMS Services

Pedagogical Tools

User Experience

Infrastructure

EALP

Architecture

Sustainability

Common Services

LMS Services

OKI Tools

User Experience

Infrastructure

SISEducational

SoftwareServices

DigitalLibrary

Infra-structure

Tools




AuthN

Etc…


Etc… Etc…

EducationalService

APIs

CommonService

APIs



SharedObjectsInstitutional Infrastructure



Localized Modular


AuthN

Etc…


Etc… Etc…


APIs

CommonService

APIs



SharedObjectsInstitutional Infrastructure

OKI Service Layers


AuthN

Etc…


Etc… Etc…

SharedObjects


APIs

CommonService

APIs





OKI Requirements for IMS

Educational“Application”

Services

CommonServices

Class AdminContent MgmtAssessment

(Quiz and Test)

AuthN

Communication(DiscussionChat, Etc.)

LUID“GUID”

FileDBMSAuthZ RulesUser

MessagingLogging Sched.

Etc…

Work-flow

Etc… Etc…

Etc… Etc…

The Importance of an Architectural Framework

IMS Quarterly Meeting

April 29, 2002

Scott Thorne

Senior Systems Architect, MIT

MIT Systems Which Keep Track of People

Library

Parking

Accounts

Sports

Registrar Alumni

Directory

LMS

HR/Payroll

Research

Lincoln

Data Feeds of Person Information

Library

Parking

Accounts

Sports

Registrar Alumni

Directory

LMS

HR/Payroll

Research

Lincoln

Employees Students

LibraryUsers

Parkers

MedicalSubscribers

Learners

People on Campus

Implications

Need for Integration Differing Degrees of Integration

By Function Authorization, but not Calendaring

Different SetsEx: Employees & Students

Degree of Coupling

Group Functional Specification

Add a new group Delete a group Add a member to a group Remove a member from a group List all members of a group

Group Integration


Group Service

System A System B

Different Group Integration

Systems each maintain copy Synchronization strategy

One system maintains groups, others only read Differing timeliness

Systems both maintain common groups Systems maintain different sets of groups

Read all sets Common service

Group Integration


Group Service

System A System B

Group Function

System C

Group Integration Issues

Who should be allowed to maintain groups? How does System A know how to use the

new group system B defined? The system of record deleted the group, what

should the subsystem do?

Benefits of Architectural & Functional Specification

Perspectives; User, Vendor, Higher Education Easier and better Integration with the Enterprise More Choices

Better interoperability >> Best of functionality

How to Proceed?

Data Specification Existing

Changes, Specific Profiles

New Areas

Functional Specification Universal Definition (UML) Multiple Bindings

Questions?

Possible Integration Goals

Allow enterprise systems to exchange & synchronize information

Allow different organizations to exchange & synchronize information

Allow systems to use enterprise services Allow for modular software which plugs

into a known framework Single System Responsible for Information

Systems Exchanging Data

System A System B

1 2

Data and Functional Specification

Data standards serve two goals Data exchange inter/intra enterprise

Both Data & Function needed for all Goals Data duplication and propagation

data specifications can’t address all issues Both Needed for Interoperability

And more!

Systems Integrated Functionally

System A System B

2

Deployment Possibilities

One system using another systems service Framework & Component

System using enterprise service Allow for system to use service to hide:

Functions performed different places Different system responsible for data sets

Demo

Local File Implementation of API

File SyncDemo

Open Knowledge Initiative. Data Specifications – IMS/SCORM Enterprise Application A Enterprise Application B Data.

Documents

nutshellan application

file directories

exchangedallow software

okian applicationafter

specialized tools

multiple users

changing functionalityminimize