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

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

3. 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

4. OKI in a Nutshell An Application Before OKI

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

6. Tool and Implementation Portability

7. 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

8. 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

9. Assumptions  Things Change  New Services & Functions  Method of Accessing Services  More Central Software Services  Authorization, Calendaring, etc.  Evolving Systems  Definition  Boundaries

10. 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”

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

12. 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

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

14. 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

15. 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

16. 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

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

18. 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

19. Questions http://web.mit.edu/oki

20. APIs  Definitions Example API

21. 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

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

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

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

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

26. Independent or Tightly Coupled Implementations AuthNAuthZAuthNAuthZ Application A