Open Knowledge Initiative ITAG Luncheon 1/8/03 Scott Thorne

Agenda  Overview & Introduction  Architecture  Status  What’s Next  Questions

Core Institutional Partners  Cambridge University  Dartmouth College  Indiana University  MIT  North Carolina State University  Stanford University  University of Michigan  University of Pennsylvania  University of Wisconsin

OKI in a Nutshell An Application Before OKI

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

Tool and Implementation Portability

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

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

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”

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

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

Educational Service Spec Activity  Class Admin  Content Management/Digital Repository  Digital Library Community  DSpace Engagement  Assessment

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

Phase 2Phase 1 OKI Overall TimeLine Jan 01Jan 02Jan 03Jan 04Jan 05Jan 06 Initial Core Service DevelopmentFurther Spec. Development Ref. Implementation Applications Developer Community Core Service Maint/Evolution Adopter Community Vendor Engagement Client/Web Tool Coordination Further Implementations

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

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

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

Questions

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

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

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

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

Independent or Tightly Coupled Implementations AuthNAuthZAuthNAuthZ Application A