Open Knowledge Initiative

Data Specifications – IMS/SCORM Enterprise Application A Enterprise Application B Data

An Application Before OKI OKI in a Nutshell An Application Before OKI An Application After 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 Effort Complexity

Common Service Spec Status  Authentication  Authorization  DBC  Logging  LocalID  Shared  Filing  Hierarchy  User Messaging  Scheduling  Workflow 0.9 – Public

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 See IMS/ADL/OKI Press Release

OKI Architecture

OKI Services Course MgmtContent MgmtAssessment AuthN Etc… LocalIdFileDBCAuthZHierarchy User Messaging LoggingEtc… Shared Objects Educational Service APIs Common Service APIs Educational Service Implementations Common Service Implementations Educational Software “LMS” Institutional Infrastructure

Client Objects Client Apps Client Objects Client Apps Client Objects Web Apps Browser Client Objects Web Apps Browser Client Objects Client Apps OKI ServicesOKI Clients Campus 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 Example API

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 private static final yada yada yada } … Example API … 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 ASystem 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 Servers Sharing Common Infrastructure Services SIS Data Authentication/ Authorization Digital Repository Messaging

Multiple OKI Servers Serving Different Content, But Sharing Some Enterprise Services SIS Data Authentication/ Authorization 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 Enrollment App. SIS System HR System

Group Integration Group Function Group Service System ASystem B

Implementation Supporting Multiple Protocols API X SRMISOAP Infrastructure Service Supporting both SRMI And SOAP

Independent or Tightly Coupled Implementations AuthNAuthZAuthNAuthZ Application A

API Implementations May Call APIs API 1API 2 Application X AuthNAuthZDBCLUID

“LMS” Varying Granularity of Service Exposure Assess Application Y AuthNAuthZ C.M.Etc. AuthZ Assess Application Z C.M.Etc.

Web Service Implementations? Web Service X SOAP Imp.of X API X WS Registry Server 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 Interoperability Service Data UI Tech Gov.CorpHESchool

Open Knowledge Initiative Service Data UI Tech Gov.Corp. H.E. School J

Data Agreement Among Profiles Service Data UI Tech Common

Interoperability Choice Service Data UI Tech Gov.CorpHESchool

Conformance Conclusions  Interoperability is not easy Therefore:  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?

OKI Strategic Efforts (cont)  Developer Communities Initial 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 Strategic Efforts (cont)  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 for more infohttp://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 Infrastructure Funding Internal External

End

Stellar OCW and Stellar: Fall 2002 OCW Int. 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 OCW Ext. Web Bb “Madagascar Institute of Technology” = OKI “Content Management” API

Design Dimensions for Educational Applications Technical Specs (W3C, IETF Java, 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 Example API

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 private static final yada yada yada } … Example API … 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 Course MgmtContent MgmtAssessment AuthN Etc… LUIDFileDBCAuthZRules User Messaging LoggingEtc… Shared Objects Educational Service APIs Common Service APIs Educational Service Implementations Common Service Implementations Educational Software “LMS” Institutional Infrastructure

Example public class Factory implements org.okip.service.authorization.api.Factory { private static final blah blah bhal private static final yada yada yada } … 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 private static final yada yada yada } … Authentication public class Factory implements org.okip.service.authorization.api.Factory { private static final blah blah bhal private static final yada yada yada } … Assessment Admit One

Same Application Using Different Implementations Service 1Service 2 Application A Service 1Service 2 Application A

Two Back End Systems – Single Access Method Class Admin Enrollment App. SIS System HR System

Implementation Supporting Multiple Protocols API X SRMISOAP Infrastructure Service Supporting both SRMI And SOAP

Kerb5 One Application Using Multiple Implementations of One API X509 AuthN App

Independent or Tightly Coupled Implementations AuthNAuthZAuthNAuthZ 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 An Application Before OKI

Thank You  Moving Ahead…

OKI in a Nutshell An Application Before OKI An Application After OKI

Logical and Schematic Models API App API Implementation of API 1 App

Same Application/Different API Implementations (Modularity) API 1API 2 Application A API 1API 2 Application A

Different Application/Same API Implementations (Portability) API 1API 2API 1API 2 Application B Application A

Two Back End Systems Supporting Single API Class Admin Enrollment App. SIS SystemHR System

Example public class Factory implements org.okip.service.authorization.api.Factory { private static final blah blah bhal private static final yada yada yada } … 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 private static final yada yada yada } … Authentication public class Factory implements org.okip.service.authorization.api.Factory { private static final blah blah bhal private static final yada yada yada } … Assessment QuizID = “Chem100Final” Assessment.getQuizElements(QuizID) Admit One Authorization. getAuths(myPerson,QuizID) myPerson = Authentication.getAgent()

OKI Service Framework  Specifications Course MgmtContent MgmtAssessment AuthN Etc… GUIDFileDBMSAuthZRules User Messaging LoggingEtc… Educational Component APIs Common Service APIs Common Objects

OKI Service Framework  Specifications  Implementations Course MgmtContent MgmtAssessment AuthN Etc… GUIDFileDBMSAuthZRules User Messaging LoggingEtc… Educational Component APIs Common Service APIs Educational Service Implementations Common Service Implementations Common Objects Institutional Infrastructure

OKI Service Framework  Specifications  Implementations Course MgmtContent MgmtAssessment AuthN Etc… GUIDFileDBMSAuthZRules User Messaging LoggingEtc… Educational Component APIs Common Service APIs Educational Service Implementations Common Service Implementations Common Objects Institutional Infrastructure

Data Exchange Enterprise System Enterprise System Enterprise System

Data Exchange SISLMS Digital Library

Data Exchange MITSIS Stellar 1.x DSpace

Service Framework SIS Educational Software Services Digital Library Common Services Tools Infrastructure

Service Framework MITSIS MIT Educational Software Services DSpace MIT Common Services Tools Infrastructure Stellar

Service Framework SIS Educational Software Services Common Services Tools Digital Library Services Infrastructure

Web Service Implementations? Web Service X SOAP Imp.of X API X WS Registry Server UDDI WSDL App. A

Web Service Implementations? Imp. of X API X Web Service X SOAP Imp of X API X JavaC++ WS Registry Server UDDI OKI Based WSDL Spec? WSDL App. AApp. B

Web Service Client Application SOAP API X Web Service X WS Registry Server UDDI WSDL Perl? C? Web Service Applications? Same OKI Based WSDL Spec?

Web Service Client Application SOAP Web Service WS Registry Server UDDI WSDL Web Service Applications?

WS Client App API X WS X Registry Web Service? WS X Registry

WS Client App API X WS X Registry Web Service? WS X

Stellar on OKI Stellar 2.0 HTML Web Server

Web and Client App Interoperability Stellar 2.0 HTML

API Implementations May Call APIs API 1API 2 Application X AuthNAuthZDBCLUID

“LMS” Varying Granularity of Service Exposure Assess Application Y AuthNAuthZ C.M.Etc. AuthZ Assess Application Z C.M.Etc.

API 1API 2

Generic Rule Model Subject Verb Predicate

Authorization Model Agent Function Qualifier

Digital Rights Model? Party Right Content

Learning Asset LA Authorization Workflow Rights Etc…

Stay Tuned

Client Objects Client Apps Client Objects Client Apps Client Objects Web Apps Browser Client Objects Web Apps Browser Client Objects Client Apps OKI ServicesOKI Clients Campus Infrastructure OKI Service Model

Multiple OKI Servers Serving Different Content, But Sharing Some Enterprise Services SIS Data Authentication/ Authorization Digital Repository SIS Data Digital Repository

Multiple OKI Servers Sharing Common Infrastructure Services SIS Data Authentication/ Authorization 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

SIS Educational Software Services Digital Library Infra- structure Tools

OKI Service Framework  Specifications  Implementations Course MgmtContent MgmtAssessment AuthN Etc… LUIDFileDBCAuthZRules User Messaging LoggingEtc… Educational Service APIs Common Service APIs Educational Service Implementations Common Service Implementations Shared Objects Institutional Infrastructure

OKI Service Framework  Specifications  Implementations  Localized  Modular Course MgmtContent MgmtAssessment AuthN Etc… LUIDFileDBCAuthZRules User Messaging LoggingEtc… Educational Component APIs Common Service APIs Educational Service Implementations Common Service Implementations Shared Objects Institutional Infrastructure

OKI Service Layers Course MgmtContent MgmtAssessment AuthN Etc… GUIDFileDBMSAuthZRules User Messaging LoggingEtc… Shared Objects Educational Component APIs Common Service APIs Educational Service Implementations Common Service Implementations Educational Software “LMS” Institutional Infrastructure

OKI Requirements for IMS Educational “Application” Services Common Services Class AdminContent Mgmt Assessment (Quiz and Test) AuthN Communication (Discussion Chat, Etc.) LUID “GUID” FileDBMSAuthZRules User Messaging LoggingSched. Etc… Work- flow 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 LibraryParkingAccountsSportsRegistrarAlumniDirectoryLMSHR/PayrollResearchLincoln

Data Feeds of Person Information LibraryParkingAccountsSportsRegistrarAlumniDirectoryLMSHR/PayrollResearchLincoln

EmployeesStudents Library Users Parkers Medical Subscribers Learners People on Campus

Implications  Need for Integration  Differing Degrees of Integration  By Function  Authorization, but not Calendaring  Different Sets Ex: 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 Function Group Service System ASystem 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 Function Group Service System ASystem 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 ASystem 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 Sync Demo